Re: Discussing issues

[Alan Hourihane <alanh@fairlite.demon.co.uk>]

On Mon, Apr 14, 2003 at 04:19:36PM -0400, Havoc Pennington wrote:
> On Mon, Apr 14, 2003 at 08:25:16PM +0100, Alan Hourihane wrote: 
> > I really don't think your going to get a clear answer to this question.
> > 
> > Open Source exists for the fact that people can't agree on how to do
> > things. KDE vs Gnome, Unix vs Windows, and so on. Technologies compete.
> > It's the way of life.
> 
> I have no doubt someone will always disagree with the answer.  That
> doesn't bother me. What I'm interested in is what most of the key
> developers from X, GTK+, Qt, major vendors, etc. can agree on.
> 
> In other words, sure there won't ever be a 100% answer, but I predict
> there will be a 90% de facto answer, and moreover my view is that
> there *should* be such a 90% answer. The reason there should be is one
> of platform vs.  applications, or choice vs. fragmentation.  (see
> http://lists.kde.org/?l=kde-core-devel&m=104725441423600&w=2)
> 
> GTK+ and Qt, GNOME and KDE are very concerned to use the same X and
> have a standard place to put X enhancements; that alone is enough to
> get the 90%, even if OS vendors, Mozilla, OpenOffice, and others
> weren't concerned about it.
> 
> There will also be some set of X APIs that lands in the LSB, and some
> set that is shipped across the major operating systems.
> 
> One of my primary concerns in fact is to drive many platform aspects
> of GNOME/KDE/Mozilla/OpenOffice/whatever down into X. That's why I
> want to see a single X project, so it can include things like 
> fontconfig/STSF, or freedesktop.org.
> 
> If Keith forks, you will get a "battle" scenario for a while, sure.
> But eventually, the "outside world" will pick one of the X
> implementation projects. The direction of X will effectively be
> whatever that X implementation project does. The other X projects will
> either have to copy the main one and sync to its APIs, or limit
> themselves to being a nice platform for twm or embedded or some other
> niche.
> 
> However, if we get agreement among what's really a pretty small group
> of people (most of them on this list), we could avoid the hassle and
> delay and just design a solution up front. In addition to avoiding the
> XFree86 fork, we could take the opportunity to merge with X.org.
> 
> I find it hard to believe that with all the smart people on this list,
> we can't solve what is essentially a simple problem - there are even
> many well-demonstrated case studies and proven approaches available
> for copying.

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. 

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.

It seems to me to solve a lot of the issues here, bar the die hards who
just want a single repository. 

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.

Alan.
_______________________________________________
Forum mailing list
Forum@XFree86.Org
http://XFree86.Org/mailman/listinfo/forum