[forum] XFree86's Future and thoughts and suggestions
Keith Whitwell
forum@XFree86.Org
Wed, 02 Apr 2003 12:49:36 +0100
David Dawes wrote:
> On Tue, Apr 01, 2003 at 07:12:17PM -0500, Alan Cox wrote:
>
>>>>If you follow the Kernel development structure, having small forks of the
>>>>kernel help because those changes get merged back into the mainline tree.
>>>>They do not affect development of mainline.
>>>
>>>How can I go about getting commit access to the mainline Kernel tree?
>>
>>You send a patch to the relevant maintainer and it goes in. Its about
>
>
> A lot of people are asking for direct commit access, and aren't
> making the distinction between the goal of getting changes out vs
> the method for getting changes out that you are. Some of these
> people already have direct commit access in a separate repository
> where they are free to do their work without impediment, and where
> their changes are immediately available to the public.
As I've said, I can cope just fine with the current situation, because of the
DRI tree. I don't think it's an ideal world to have the seperate tree, it's
certainly less efficient, and it makes code releases less timely than they
would have been -- but I can't do much to change the situation, either.
Some have
> invoked the Linux kernel model as justification for direct commit
> access. I take it from your answer that it isn't possible for me
> (or most others) to get this same direct commit access in the case
> of the Linux kernel.
Linux seemed to have a crisis over this issue at the end of the 2.3 series,
prior to the adoption of BitKeeper. By adopting BitKeeper (and perhaps some
social changes as well), they made Linus more efficient, expanded the
capabilities of the ring of maintainers around him, and made it pretty easy
for anyone to create & maintain a local branch of linux (like a DRI tree
equivalent).
BitKeeper makes it very easy for people to create & maintain DRI-type parallel
trees. Reportedly, the tool is so good at merging to & from such trees, it
becomes a near-trivial task, so groups of interested people can maintain &
develop change sets against essentially the current version of Linux, and
Linus (when he decides to) can bring their changes in with minimal effort of
his own.
These process changes (largely of a technical nature) averted a crisis with
some similar dimensions to what's happening in XFree86, and the whole thing
seems to be running pretty smoothly now.
Anyway, I'm not a Linux/BK expert, but that's what it looks like from the
outside. And yes, there are flames about the BK license that persist despite
the improvements.
Keith