Re: GSoC application deadline passed

[olafBuddenhagen]

Hi,

On Fri, Mar 14, 2008 at 03:08:31PM +0100, Carl Fredrik Hammar wrote:

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

Well, the fact that it's not strictly part of the Hurd doesn't
disqualify it per se, as long as it's Hurd-related. (In fact, there is
already the "GNU package manager" task in there.)

The question is really whether the work requires more Hurd interaction,
or more Debian interaction. In the latter case, it would obviously be
more useful to have it proposed for Debian, with a mentor from the
Debian project.

Same problem exists with the long-standing "port Debian-installer"
task...

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

That's not quite true. The non-upstream hacks are rather an exception
than the rule.

It's true though that some rather important issues have only hackish
fixes...

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

That raises an interesting question indeed: Is it allowable to have a
release branch with hackish fixes that won't go into the trunk?...

Personally, I tend for "yes".

> You can access the git back-end directly.
[...]
> I'm not sure it's actually faster though,

It's not faster. Seems to be updating the HTML pages that takes so long.

> but at least you'd be able to update multiple changes in one batch (I
> think).

Indeed. You can commit many changes before you push. That's one of the
many advantages of using git :-)

-antrik-