[forum] XFree86's Future and thoughts and suggestions

[Keith Whitwell]

Mark Vojkovich wrote:
> On Tue, 1 Apr 2003, David Dawes wrote:
> 
> 
>>On Tue, Apr 01, 2003 at 12:56:40PM -0500, Shawn Starr wrote:
>>
>>>I feel the whole core membership idea is a blockage to XFree86 development. 
> 
> 
>   I did my most significant work on XFree86 before becoming a core
> member.  I was "promoted" to core *because* of my work.  I did not
> have CVS access before that.  I once maintained the XF86_S3 server,
> wrote the S3 driver in the XF86_SVGA server, maintained the mga
> driver in the XF86_SVGA server, was principle author and maintainer
> of the mga driver in XFree86 4, principle author and maintainer
> of XAA and principle implementor and maintainer of Xv, all without
> having CVS access.  Not that this was a good thing to have to
> do all of this without CVS access, but it was done.  Granted,
> patches were reviewed and committed in a more timely matter back
> then.  It's not core membership that's a blockade, but the ability
> to get things into the tree.  This didn't used to be a problem 
> when the people with commit access (then it was only the core)
> had more time.  Core is merely a status position.  They used to
> be the only people with commit access, but more recently this has
> ceased to be true.  The answer is not getting rid of core, or
> promoting more people to core, but adding more committers.  In
> my opinion we don't need core, since it is only symbolic, but
> that's a different matter.
> 
> 
> 
>>Core != commit access.  I'm not sure where that myth came from,
>>but it has never been true.  There are 14 people with commit access,
>>not all of them are core members, and not all core members have
>>commit access.  I don't have an answer as to why only 2 committers
>>regularly deal with general submissions, with a few others dealing
>>with specific submissions.  Maybe we don't have the right 14.
> 
> 
>    We don't have the right 14.  We have alot of holes in our coverage.
> The thing is that people have certain areas of expertise.  If you
> have a patch for XAA or the nv driver or Xinerama, I'm your man.
> If it's something about input drivers, for instance, I wouldn't
> dare commit it because I don't know enough about it or how it fits
> into the big picture.  You need to have points of contact for
> various parts of the tree.  This is roughly the Linux kernel's
> model at least as far as knowing who to send patches to and who
> reviews them.
> 
>    So a point I'm trying to make is that you can have 100 people
> with commit access and if nobody there knows anything about
> input drivers, an input patch may still sit in the patch queue without
> getting committed.  That's why I think the maintainer model is a
> good one.
> 
>    I don't think all of the patches funnel through Linus.  If
> they do, then that's not much different than the way things are
> with XFree86 now, with most patches funneling through David.

I don't think Linus looks at each patch individually, but pulls in great wads 
of them from the ring of maintainers around him.  BK makes this process easy - 
think of each maintainer as running a DRI type parallel tree, and Linus 
merging in from each of them.

It's not that he doesn't maintain control, but it's pretty clear he doesn't 
sit there reading each line of each patch - by the time stuff gets to him, it 
should at least be reasonable.  He can decide for himself what changes need 
closer scrutiny or pushback.

And of course, it never works just like I've described, but that's a broad 
picture of how I think it's supposed to be.

Keith