On Mon, Apr 14, 2003 at 05:13:37PM -0400, Havoc Pennington wrote: > On Mon, Apr 14, 2003 at 09:46:03PM +0100, Alan Hourihane wrote: > > And the separate CVS tree for development of certain features is still > > a viable option for this work and become a friendly fork such as the > > DRI. > > > > I agree a separate CVS tree could be viable, at least when there are > well-defined modules. > > > Keith already has his own CVS and can manage that as he sees fit and > > submit work back for inclusion in the mainline tree. That way Keith > > and the various people interested in them extensions get to focus on those > > type of features. > > The issue though is that simply separating CVS doesn't address the > issue of how decisions are made; Keith submits his work back for > inclusion, or other people do, but who then makes the call on whether > to include it. What is the process for deciding these matters. Who > determines the release schedule? Who decides what code is in a > release? In 99% of situations code is accepted. The 1% is usually regarding highlighting the bigger picture on integration issues or alternatives ways to achieve the same desired outcome. > I'm not saying the wrong person will, or the wrong call will be made, > or anything like that. I'm not even sure what you would propose for an > answer to that question so I'm not criticizing your answer. I don't think anyone would reject obvious code that gives significant improvement in how X works. > It just seems to me that where the code lives is not what people are > (primarily) arguing about. That's not been made clear at all. > > It should work exactly as Alan Cox mentioned regarding the 'sparc port' > > for linux. Why can't it work in this case too ?. I don't see any reason > > why it couldn't. > > I think it could, provided people are comfortable with how decisions > are made on the stuff they submit. Like I say, it's highly unlikely code is going to be refused for any reason bar what I've mentioned. If it is, then I'm sure it'd be brought up on a case by case basis for the wider audience to participate on it's pro's and con's etc. > When it comes right down to it, there are decisions to make that must > be shared decisions. Schedules, module organization, general project > goals. "Agree to disagree" works up to a point (and is in fact *good* > when it works, because it's more modular/scalable), but it breaks when > you need to make a shared decision. The point I'm trying to make is that an initial idea tends to go argued a lot more without code to back it up. If this code is developed in a seperate CVS and shown how implementation works, this gives a much better picture on how things are wrapped up, and therefore much less likely for the agree/disagree scenario. I'm really trying to get to a conclusion on all of this for all parties so we can get back to work, and this setup seems to me the best overall solution. Alan. _______________________________________________ Forum mailing list Forum@XFree86.Org http://XFree86.Org/mailman/listinfo/forum