Re: How best to contribute to the Hurd?

[Marcus Brinkmann]

Hi,

as a general answer, you are already deep in the mud of helping us :)

On Thu, Oct 10, 2002 at 05:55:23PM -0400, Clemmitt Sigler wrote:
> I've recently been doing more with the Hurd, and I'm wondering how
> I can best contribute to the effort.  I have very little kernel/driver
> hacking experience, I'm afraid.  However, I don't mind writing
> documentation, and (as you can tell :^) I've been building some
> packages recently that I'm interested in.
> 
> Is this a good way to help out?  If so, what docs need to be worked
> on most (out-of-date or incomplete)?

All docs.  The doc situation is nowhere to be satisfying.  Neal's
installation guide is excellent, so that answers most of the initial
questions, but there is so much missing.

> And what packages would it be productive to fix up so they build?

One job is to find out.  The autobuilder (buildd) is not running currently,
but hopefully soon will.  That should give us good reports on what packages
compile and which don't.  Apart from that, you could look at the existing
standard, important etc packages and look at what is missing.  Sometimes it
is just a matter of running around and making sure that nothing is forgotten
about.  Before we don't have the autobuilder running on a regular basis it
will be hard to work productively on this issue.

Do you have a Debian account?

> I'm probably not the best person
> do to a large porting effort or to fix really low-level problems, but
> I'm glad to help if I can.  I suppose I'm asking if there's a central
> docs coordinator or working list, and a list of most-requested packages.

There are a couple of quite obvious ones which never seem to make any
progress, no matter what we try :)  This includes liblockfile, util-linux
etc.

> I've been thinking to myself that an end-user HOWTO/FAQ would be
> helpful.  I just discovered this doc-in-progress today:

Well, we have an FAQ on the web site.  Help with digesting the email lists
and fishing out good FAQs is something that can always be done.  Simply
collecting all the small buglets that the experienced people just dance
around instead fixing them would also be something that could help us
prioritizing our work.  That's just ideas.

Another thing that would be helpful is to try out POSIX compliance test
suits and stress tests for filesystem etc to find new easily reproducible
bugs.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/