Re: Discussing issues

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.