Re: GSoC application deadline passed

[olafBuddenhagen]

Hi,

On Fri, Mar 14, 2008 at 10:02:56AM +0100, Arne Babenhauserheide wrote:

> I'm sorry I didn't contribute. 
> 
> First of all I didn't think I could really help, since my knowledge of
> HURD internals is limited to some surface stuff (that's what you learn
> in informatics courses). 

I'm sorry -- it seems I addressed this rant a bit too broadly... As you
say yourself, helping here does require some knowledge of Hurd stuff. I
didn't really expect help from lurkers or newcomers :-)

> But there is something I direly miss in the HURD, and that doesn't
> have anything to do with its actual code, but with how it can be
> accessed and seen. 
> 
> When we had the HURD in my informatics class, one task was to find out
> information about the HURD, and as I searched for information on the
> current state of the HURD, it looked quite dead. 

That's interesting. When was that class, and where?

> This wasn't because it was dead, but simply because it doesn't get as
> much attention as it would deserve - and that has a reason. 
> 
> So I added a project idea to fix this: 
> 
> 
> * A release creation framework
> 
> One of the points which keep people from using the HURD is that it
> never looks like it is in a working state. To get attention from
> people (and the press, etc.) the HURD needs releases, and doing a
> release should be as simple as submitting a changelog and release
> notes and tagging the code, ideally done with only one simple command. 
> 
> A framework for creating HURD releases could give the HURD far more
> visibility and thus make it more interesting to developers. 
[...]
> I feel that making a release is a vital process for any free project,
> since it focusses the attention on the users (that means: the target
> audience). 

I totally agree that releases are crucial, to raise awareness and show
progress.

> It should include automatic publishing of the press release to
> selected weblogs and newssites, as well as preparing and uploading the
> release to visible servers and creating images of the HURD to be used
> in free virtualization software and livecds ( an example livecd:
> http://people.debian.org/~neal/hurd-live-cd/ ), so people can test the
> features at once. 
> 
> Also it should update a status page with the current release (with
> date), state and features of the HURD. 
> 
> It could automatically update packages for different distributions,
> too. 
> 
> The press releases should also by default include pointers to all
> necessary information to dive into using the HURD, as well as to begin
> coding at once. 
> 
> And naturally the framework should be easily adaptable to changes
> inside the HURD project and, if possible, to other projects as well. 
> 
> -> http://www.bddebian.com/~wiki/community/gsoc/project_ideas/ 
> 
> 
> 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? 

Thanks for you efforts; they started some interesting thoughts. I have
doubts though about the automated release framework being an appropriate
task for GSoC -- at least for this year. The problem is that before you
start automating something, you first need to know what exactly you want
it to do; have some experience with how we actually want the releases to
work. In other words: We need to start making releases first.

As you seem to be quite new here, you are probably not aware of this;
but the reason we have no releases is not really because it's too much
effort. Rather, it's because most influential people here either do not
care, or actively dislike the idea of making a release. Their
justification is that not having had an official release in such a long
time, if we released something now still having many known problems, we
would make ourself ridiculous. That we should generally try to avoid any
publicity, until we have a nearly perfect system to present.

IMHO that's not a very convincing argument. For one, most people already
consider us ridiculous anyways. People who laugh because of an imperfect
release wouldn't contribute anyways, so we can give a shit about what
they think. And anyways, if they laugh, that means they at least noticed
that we still exist. That's much better than people thinking the project
is dead. To use a well-known phrase: Bad publicity is better than no
publicity.

More public awareness might have not only positive effects; but without
awareness, we simply *can't* find new developers, and thus *can't*
create a much improved system.

But well, who cares what I think about that anyways...

As for automatically building live CDs and/or qemu images, this would be
very useful -- maybe that part is indeed an appropriate task for GSoC.
But as others pointed out, there are often issues with building a
working system that require manual intervention; so it's questionable
how far this process can really be automated... I think this needs some
more consideration.

> PPS: I rust read your application, and I like it. For me it looks well
> written and gets to the point. 

Thanks for the encouragement :-)

To myself, it felt like a hastily created braindump; lacking a lot of
polishing...

> PPPS: About the application form: Please remember that there's a 7500
> char limit on the application, so students should maybe provide links
> to specifics at other places. 

Yeah, I thought about it at some point, but had too much other things on
my mind...

That's precisely the kind of input I hoped for before the deadline; now
it's too late to change it :-( Remains to hope that google itself will
place the information prominently...

-antrik-