[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC application deadline passed

From: Michael Banck
Subject: Re: GSoC application deadline passed
Date: Fri, 14 Mar 2008 16:32:40 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

Forgot to reply to this part.

On Fri, Mar 14, 2008 at 03:58:33PM +0100, Arne Babenhauserheide wrote:
> El Friday, 14 de March de 2008 15:08:31 Carl Fredrik Hammar escribió:
> > Now to a real issue.  While there's nothing wrong with the project as
> > such (in fact it's quite a good idea), I think most of the project is
> > more in the domain of distributions, e.g. Debian, rather then the Hurd
> > itself.
> >
> > The Hurd is only the kernel, and as such it is quite uninteresting to
> > have a live cd containing only that, what you want is a complete
> > distribution of packages.  While of course interesting in the context
> > of the Hurd, it is not technically part of it so I don't think it's
> > appropriate for GSoC.
> >
> > It should probably be moved to a different suggestion/task page.  But
> > I'll let someone with more authority make the decision whether it
> > stays or not.
> That means, the Hurd would completely depend on the Debian people to make new 
> releases. 

New releases of what?  If Hurd development picks up speed, I assume the
Debian hurd package would get updated more often.

The Hurd is mostly targetted at developers right now who should be able
to build the Hurd from CVS rather than tarballs anyway, so having
regular releases is mostly a PR thing.

> That dependency might not be bad (and might save time), but for things like 
> updated qemu images and similar, it doesn't seem to work well enough. 
> Maybe it would really be a project for Debian, to package new things with the 
> Hurd. 
> But packaging a new Hurd with an existing Debian image doesn't need to be 
> done 
> by the Debian people. 

Sure, but why shouldn't Debian GNU/Hurd just update their system with
apt-get?  I don't see why updated images are a requirement.
> The kernel itself might not be interesting, but testing teh changes in a new 
> release of the kernel is - and that can be done without having to rebuild the 
> whole installation. 

Of course.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]