Re: GSoC application deadline passed

[Michael Banck]

On Fri, Mar 14, 2008 at 03:58:33PM +0100, Arne Babenhauserheide wrote:
> * Setup a blog and write your commit messages in there. If there is a git (or 
> mercurial) repository, also add a link to its web frontend on the website. 
> People must see, that the Hurd is active. 

A developer blog (i.e. something which is shared by all the active
developers, and only has entries regarding current developments) might
be interesting (just commit messages aren't so much, because in a GNU
tradition, they usually only describe the changes themselves, and not
why they were done, what they fix or what else this can lead to).

> > 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. 
> 
> 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. 
> 
> 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. 


> 
> > > I like the ideas about the HURD, and I want to be able to switch to a
> > > HURD system soon (at most a few years), so the progress and state of the
> > > HURD must be visible.
> > >
> > > One example: I see many changes in the commit list.
> > > Why don't I see livecds integrating the new changes appearing at once?
> > > Why are there no automatically updated images, I can just testdrive?
> >
> > Most of the recent changes has been on the L4 branch, which was
> > originally an attempt to port Hurd to the L4 micro kernel.  That
> > didn't work out for various reasons, so currently they are
> > experimenting with their own kernel until something better comes
> > along.  (Disclaimer: I'm not a 100% sure on any of this.)
> 
> Does that already run? 

No, at least not in any way interesting to users, I think.

> > Development on the Hurd proper has been slower.  Most of the progress
> > seems to be temporary fixes that is managed through patches and needs
> > real solutions in-order to actually get into the Hurd.
> >
> > There are some important bugs that needs to be properly fixed before a
> > new release can be made (although I can't seem to locate a list of
> > them).
> 
> If you find a list, that list should go into the wiki, along with a roadmap 
> on 
> which things can be marked "done". 

The bug and task trackers are at http://sv.gnu.org/p/hurd

> That means, the Hurd needs something like the Shedules in KDE: 
> -> http://techbase.kde.org/index.php?title=Schedules
> 
> Each new release just needs a todo list with bugs and features. 

It's not as easy as that.  Bugs either get fixed relatively fast, or are
so complex (e.g. require large parts of glibc be rewritten) or at the
design level (see the discussion about threading) that you cannot just
say "We'll fix the missing SA_SIGINFO by Monday".
 
That said, we are doing much better with tracking bugs, but we could do
even better I guess.  This is maybe something people do not necessarily
need a deep understanding of the codebase to help.


Michael