Re: Discussing issues

Alan Hourihane <[email protected]>
Newsgroups gmane.comp.xfree86.forum
Message-ID <[email protected]>
On Mon, Apr 14, 2003 at 06:14:17PM -0400, Havoc Pennington wrote:
> On Mon, Apr 14, 2003 at 10:59:46PM +0100, Alan Hourihane wrote: 
> > I don't think anyone would reject obvious code that gives significant
> > improvement in how X works.
> 
> The hard part is something like STSF/fontconfig, or release schedules,
> where either the issue is not technology, or there is real technical
> disagreement on the definition of "improvement." 
> 
> As Owen said a while back, doing things by consensus works great,
> until you don't have consensus. Then you need a mechanism.
> 
> Projects that have mechanisms *also* work 99% by consensus. It's just
> that in the 1% case, something sane happens. vs. what we now see on
> this list, which I would describe as "not sane"
> 
> > > 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.
> 
> Absolutely! That's why in this post:
> 
> http://www.xfree86.org/pipermail/forum/2003-April/001106.html
> 
> I said "request did not really get clearly conveyed"
> 
> And why I felt that getting people on the phone would help everyone
> understand what each side considered to be the important issues.
>  
> > > 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. 
> 
> You can't say "show me the code" though when two parties have code,
> when some parties think the code that's had is bloat/wrong/whatever,
> or for topics such as release schedules, how to organize
> lists/bugzilla, etc. - that's why these issues are the ones that are
> causing the flames. They are issues where consensus isn't clear and
> where saying "you can do that yourself if you want" doesn't make
> sense.

Why can't you have both ?

In your example, what's stopping people developing for STSF or fontconfig ?

In my eyes, nothing. I don't understand why your asking for some stake
in the ground to say this is the one we're backing. The backing of a
piece of code comes from it's developers of that code. Sun is obviously
heading down the STSF route whereas others are using fontconfig. One will
win on it's merits of the people using the code. Heck, STSF doesn't even
exist in XFree86's tree, yet people are still using it. Just because it
doesn't exist in XFree86's CVS doesn't mean that it's right or the
best implementation.

Alan.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.