Re: encouraging developer participation

From: Andreas Dilger (adilger@turbolabs.com)
Date: Mon Jun 05 2000 - 10:48:57 EST


S. Baker writes:
> Here is the problem: I only got two replies, both of which
> ignored the problem and instead berated me for something
> completely irrelevant, without addressing the issue.

I don't think this is a deliberate attempt to be rude or elitist
on the kernel mailing list. I have found that this is the case
for most open source/free software development for many years,
long before I started doing kernel development. If people don't
have a problem with something, they don't complain. Even if
people DO have a problem with something, they rarely complain.

How many times have you written to the XFree86 people to say
"I'm using your X server/xterm/etc, and it works great"? Granted,
when you post a specific kernel patch and solicit feedback, you
would hope that someone tells you at least something. However,
many people just don't have the right devices to do testing, or
(often) are already working on other parts of the kernel and don't
want to introduce new bugs into their kernel while testing, or
the patch simply isn't interesting enough for them.

> I think there needs to be an easy way to find a person responsible
> for any particular part of the kernel, that one can rely on for
> information about that part. When someone posts patches, or a
> bug report, the person should be responded to on the merits of
> the information given.

There is the MAINTAINERS list, which is a pretty good place to start.
I also usually post to the subsystem-specific list (fsdevel in my case)
instead of/in addition to l-k, on the off chance that some people only
follow the lower-volume list. Also, it is good to follow l-k (or
subsystem-specific list) to see who is posting on topics related to
your patch. After your initial post (and discussion, if any), you can
consider CCing them with your subsequent postings.

However, it is nice not to CC everyone with initial code/questions,
as it may be a FAQ, a bad way of implementing the fix, or whatever. If
we inundate the primary maintainers with email, they are more likely
to miss other important issues, and they will have less time to test
or evaluate the patches sent to them...

> My frustration has come from not having any idea who should be
> looking at the patches I provided. I got a couple of replies,
> but are they authoritative or not? I have spent far more time
> so far trying to get a fix implemented than in finding that fix,
> and it has been an extremely frustrating experience. I don't
> think that it has been one that encourages participation.

This has a grain of truth, as I have sometimes had the same problem.
Fixes that are (IMHO) "obviously correct" and should go into the
kernel are ignored for a long time. You need to consider re-posting
the fix (and CCing the relevant maintainers) after some time has
passed without reply. There was a thread about this on l-k with input
from Alan and Linus that basically said "we are drowning in email,
you can't possibly expect us to read it all (except for Alan and his
mutant dwarf Alan clones who parcel up his email between them and
multi-task)".

Often, with the passing time and increased testing, I have found new
small bugs and/or different ways of fixing the problem that may be
more appealing. If the patch is very small and "obviously correct"
it will get picked up eventually. Larger patches usually need to
get "blessed" by a well-known personality before they are accepted.

Cheers, Andreas (still waiting for several of my fixes to be "blessed")

-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:21 EST