Re: Suggestion for XFree86

On Thu, Mar 20, 2003 at 10:40:35PM -0500, Carl Worth wrote:

>Note that I'm talking about contributing chunks of new code, not bug
>fixes. I think something like [email protected] could work fine for
>bug fixes, (and bugzilla can only help).
>
>I think the problem in the current situation is the imbalance between
>the core team with easy access to modify the tree and the second-class
>citizenship developers who have to send email patches and wait for the
>core team to act on them. And then, in order to become a core team
>member one has to willingly accept second-class citizenship for "5
>years"? No thanks.
>
>Fortunately, in my case, most of the new code that I care about and
>continue to develop all exists as client-side libraries. These can all
>be developed and released quite independently from all of XFree86. So
>I can just setup my own CVS server and ignore xfree86.org without a
>problem. It would be more convenient to just do this within XFree86
>infrastructure, (after all I'm writing new libraries that live in their
>own directories and don't affect any existing code), but the
>difficulties in getting that access aren't worth it to me. The things
>I lose this way are xfree86 infrastructure, (CVS, bugzilla), and the
>distribution channel and name recognition that XFree86 would provide.
>
>It seems the same model would work just fine for driver development
>and distribution, (Again with some developer time lost to setting up
>infrastructure for CVS, bug-tracking, advertising, etc. -- not
>perfect, but quite workable).
>
>This hints at one of the big changes that XFree86 should make. The
>project should recognize that the large, complex code base of XFree86
>is actually quite modular, (and can become more so), and the developer
>community could be more efficient if its organization matched that
>modularity.
>
>For example, in my mind there should be almost no barrier of entry for
>someone who wants to contribute a new driver. As Linus said once, "If
>a new ... driver is broken, it can't be any worse than not having a
>driver at all, and even a broken driver is more likely to receive
>attention than somebody having to start from scratch."

This might be a good time to recount my recent experiences with submitting
code for inclusion in the Linux kernel.  I don't have any inside contacts
in Linux kernel development circles, and I am not "known" for working
in that domain.  So, I came to this as an outsider with code to contribute.

The first case was a patch adding new hardware support to a kernel
module.  The changes for this were relatively small.  I checked through
the documentation in the Linux source tree, and on some mailing lists
to figure out how to submit my changes.  I sent to them to the maintainer
of the relevant module in the 2.5.x kernel, and to the 2.4 maintainer.
No response.  A month later, I had some further updates, so I tried
again.  This time I got a response from the relevant 2.5.x maintainer,
requesting that I make some trivial changes because of version skew
between my first submission and my second one (effectively changing
several occurrences of var.field to var->field).  These are the sorts
of trival things that when encountered in a submission to XFree86 I'd
just take care of myself as part of the integration process.  But, this
is the Linux kernel, and they have their own procedures, so I make the
trivial changes and resubmit.  The patch is applied, and is now part of
the 2.5.x kernel tree.  I was a little disappointed that it was credited
to the maintainer of the module in the change list the Linus sent out,
but as I said, they have their procedures.

The second case was a new driver for the 2.4.x kernels.  I submitted it
the 2.4 maintainer, to Alan Cox, and to Linus (as a courtesy).  The
driver has not yet been ported to work with the latest 2.5.x kernels,
so I didn't expect it to be integrated there.  Alan Cox replied promptly
and included the driver in his next kernel release/snapshot (thanks
Alan).  I didn't get any reponse from the "mainstream" 2.4 maintainer,
and I have no idea if the driver will make it into that kernel.  I
clearly have no opportunity to commit it myself, and to be honest, I
have no idea who is able to commit code to the official kernel source
trees.  If I'd been aware of your quote from Linus above, I'd have also
expected this driver to be included in even the 2.5.x kernel tree on
the basis that "a broken driver is better than starting from scratch."

Now, I don't feel that I'm in any position to complain about any of the
above.  I haven't invested a large part of my life in the Linux kernel,
so I'm not qualified to tell them how they should do things.  I only
mention it here because it sounds similar to some of what you're saying
about XFree86.  This is just an example of my own recent personal
experience as an outsider submitting code to the Linux kernel.  All it
shows that some of the claims you make about XFree86 aren't unique to
XFree86.

David
-- 
David Dawes
Release Engineer/Architect                      The XFree86 Project
www.XFree86.org/~dawes