Replying to both, Gianluca nailed most of it already, anyway. On Tue, Jul 31, 2007 at 09:11:56PM +0200, Anders Breindahl wrote: > On 200707311150, Michael Heath wrote: > > I don't think so. Google's SoC is designed to help finance one student to > > work on a specific task within a project. With a Hurd-specific fund, you > > would be able to to choose specifically where to spend the money for it to > > be the most beneficial to the Hurd.
Uhm, who do you think proposed the project and picked the student? Actually, GSoC has a much higher chance of actually getting code into the Hurd, because *the Maintainers mentor the student and provide a CVS branch for him*. If you just throw some money at somebody, the best you can come up with is a patch to bug-hurd unless that money has been spent directly by the FSF and some FSF officer decrees that this code has to be applied, at which point I assume the maintainers would apply it before quitting. Otherwise, general evaluation by the maintainers will hold and whether or not that code was good enough and/or fitting will be seen. > > You'd also be able to finance work by developers who may not be > > elligible for SoC. It's a completely different system. That's a point, but that doesn't invalidate GSoC as a good sandbox for this. > I agree. If the Hurd wants a kick start towards the end of some of the > goals that are stated -- update glue code, migrate microkernel, make > software package $x compatible with the Hurd (or the reverse), implement > this and that netfs translator, and so on -- paid work would be > justified. Those projects you mention differ between each other by several orders of magnitude both in timescale and complexity. If somebody wants to buy out Marcus Brinkmann from his current day job (which is mostly Free Software related as well, AFAIK) to work on his pet projects, that /might/ result in basing the Hurd on a new microkernel at some point. But this is rocket-science, nobody knows whether it will work out in the end, so I guess Marcus wouldn't consider such an offer anyway, because he couldn't commit to deliver. Certainly just putting up a big bounty and waiting for some random developer to come along and port the Hurd to a new microkernel won't work. Then of course you have the issue that people apparently do not want to code on something which might be obsolete in a couple of years - nobody knows yet how much of the current codebase could be salvaged for Hurd/NG. The other projects (updated glue code, some translators) look quite ok to have a bounty on, especially if they take advantage of the Hurd's modular design - You can always release a shiny new translator which can easily be built against the Hurd, you don't necessarily need to have it in the Hurd tree - we also have the hurdextras repository at Savannah, except that it is kind of stalled due to maintainer deadlock currently, but that will be fixed eventually. > After all, there isn't so much work that needs to be done, in order for > the Hurd to be a satisfactory standin for Linux. I'm not sure how to comment on this. Michael
