[Top][All Lists]

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

The current hurd development system - or: optimizing for fun

From: Tom Bachmann
Subject: The current hurd development system - or: optimizing for fun
Date: Sun, 29 Jan 2006 18:59:40 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051031)

Recently, I read an article [1] in antrik's blog. Again [3] I was surprised by him not doing anything to put through his ideas. Main stements in this article are his agreement to [2] and his opinion that the Hurd's slow down is also due to doing the exact opposite of -Ofun.

Short summary of [2]:
Autrijus Tang had one explicit goal when starting pugs: optimization for fun. This seems to have tremendous benefits: extreme productivity and creativity [4]. The reason given is that enjoying your work will make you do it better. The main part of the essay is a list of ways how to achieve -Ofun [4].

I do not say our way of doing stuff is the reason for not having the Hurd yet. I understand there are good technical reasons. I also do not say taking another way will magically make everything better. I just want to encourage rethinking of the development process. Possibly we could even split development into multiple trees, experiment a bit and then reject the idea or not, though I'm not convinced of this way.

Anyway, here's how I think the development process can be improved (of course this partly resembles the points given in [2] and can be taken as provoking inspiration by those that don't like it)

o Use a better revision control system.
  Cvs is outdated in several aspects. Most notably truly atomic commits
  and file moving are missed, thus not allowing -Ofun to be relized.
  Easy merging and branching are also required.

o Make commits easy and straight forward.
  Revising all code by a handful of core developers is a serious
  bottleneck and source of frustation.
  For the beginning it might be OK to give all frequent users of the
  list that ask for direct access to the repo (possibly in different
  branches), but commit rights must be casted far and wide.

o Work on code.
  Design is necessary, but prototyping too.
  A really nice idea I saw in
  another project was having a sandbox directory for every user so they
  can express their ideas in a stalwart way.

o Highly integrate the community.
  We have to look for developpers everywhere (not while bootstrapping
  and not having something to work on, though) and also make the
  non-developper community contribute to the project.
  In short, we have to enthuse the base community.

I agree with antrik that -Ofun is the logical next step after bazar development system and I'd like to add that I think the Hurd, the heart of the gnu system, has to become a next generation community project.

Hoping for intensive discussions.


[1] http://tri-ceps.blogspot.com/2005/10/importance-of-having-fun.html
[2] http://www.oreillynet.com/pub/wlg/7996?wlg=yes
[3] I refer to his lecture on linux-infotag last year, where he expressed his hope to make kgi part of the linux kernel but also admitted he had not asked anyone or told his ideas the linux kernel dev list.
[4] See the [2] for details.

Antrik: this is no personal attack on you, I just abused you to make up an introduction ;)

reply via email to

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