Re: Re: [Dri-devel] Re: Invitation for public discussion about the future of X

On Fri, Mar 21, 2003 at 10:17:20PM -0500, G O Economou wrote:
> > [Original Message]
> > From: José Fonseca <[email protected]>
> > To: <[email protected]>
> > Cc: dri-devel <[email protected]>
> > Date: 3/21/2003 9:49:24 PM
> > Subject: Re: [forum] Re: [Dri-devel] Re: Invitation for public discussion
> about the future of X
> >
> > A cleaner seperation I guess. According to
> > http://www.mail-archive.com/devel%40xfree86.org/msg00846.html , using
> > access control in CVS is not an option. The model described by
> > http://www.mail-archive.com/devel%40xfree86.org/msg00853.html is that
> > every developer should have his own repository and submit a patch to
> > [email protected]. 
> >
> > My proposal is, instead of every developer/sub-project maintaining it
> > own repository outside xfree86.org, host these repositories as branches
> > on single (but seperate) repository under the Xfree86.org umbrella.
> 
> But the problem comes in if your work isn't taken because of conflicts. 
> That 
> will lead you back to where you are now.  More yelling and more shouting
> and no code.

The CVS write access to this seperate repository would not mean, just by
itself, free-pass to do whatever changes somebody wants. I guess it
wouldn't be different of anyother project - nothing will ever substitute
good dialog on [email protected] to make sure everybody is on the
sametrack, so that there aren't any nasty surprises when a release is
made - everybody knows what's going in and what stays out.

To give a little more detail, we could have branches on this repository
where more experimental/controversial work could be held. As matter of
principle, nobody would merge with the trunk until there is an consensus
with the core and other developers. In the worst case scenario, if such
consensus isn't reach it's still OK: people can still keep working on
it, perhaps addressing the concerns the core has about that work, or
just maintain that branch as fork, and release patches to full XFree86
source if vendors wanted to include some of that functionality (ala
Linux kernel). But even if there is a fork, people can still share ideas
on [email protected], and be close to the development. What I mean, is
that 

Anyway, these kind of conflicts should be infrequent. According to what
David Dawes said himself, most of the patches commited to
[email protected] are accepted, except those which have severe faults.
Note that even this current conflict isn't about code - as far as I read
here, all Keith Packard changes were accepted, even after when he loose
CVS access. This conflict is mostly about people. My suggestion is not
the holy grail, but perhaps it could help a little in avoiding people
starting to want to make a full fork of XFree86, by giving a more 
collaborative environment for all people who work on XFree86.

José Fonseca