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

[F. <jrf...@tu...>]

On Fri, Mar 21, 2003 at 12:07:04AM +0100, Michel Dänzer wrote:
> On Don, 2003-03-20 at 22:53, José Fonseca wrote:
> > On Thu, Mar 20, 2003 at 02:48:21PM +0000, Alan Hourihane wrote:
> > > On Thu, Mar 20, 2003 at 11:37:34 +0000, Keith Whitwell wrote:
> > > > 	- Extend CVS access to regular contributors.  Use
> > > > 	scripts or whatever to control access to subtrees if you
> > > > 	want.
> > > 
> > > This comes up from time to time, and I'm sure will get discussed
> > > even more.  I know there have been offers to others for CVS commit
> > > access, and some have refused and some have accepted. The
> > > consensus of who gets commit access has always been - if they show
> > > competance at sending patches in, then after a period of time, no
> > > doubt they'll get it. It's the same as the DRI, but with more of a
> > > prolonged period of evaluating that persons patches. I guess this
> > > 'prolonged' period, is the stickling point for most.
> >  
> > Why not simply have a second CVS repository, where most development
> > would take place under, while the current repository would be the
> > one used for (pre-/post-) releases with coarse-grain commits. Like
> > stable and development branches, but with the branches being on
> > different repositories.
> 
> Why a second repository then, instead of just branches, and maybe
> restricting most developers to commit to branches and only allow some
> to commit to the trunk, for example? I don't see much advantage in a
> separate repository (but I may simply be missing it, clues appreciated
> :), but it makes merges more difficult.

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
fi...@xf.... 

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.

It would be less likely to forks and spin-offs originate, where as in
the current situation they seem to proliferate. And I don't see in what
way would things more difficult as they already are.

José Fonseca