[forum] XFree86's Future and thoughts and suggestions
Stuart Anderson
forum@XFree86.Org
Tue, 1 Apr 2003 12:11:31 -0500 (EST)
On Tue, 1 Apr 2003, Shawn wrote:
> Fair enough but, There are many projects out that are on a free time basis.
> There seems to be more negativity towards X because of the lack of giving
> more developers access to XFree86's tree. If this happens the negativity will
> vanish.
And I've stated that this is being worked on.
> The only thing I saw from this was Keith's work with KDE/GNOME people on
> bringing new extensions to X, *nobody* else.
So how many people does it take to listen to one group, and relay important
information to another group? We thought one was enough.
> >DRM is handled by the DRI development team, not XFree86.
>
> True but DRM and XFree86 are dependant on each other (for direct 3D hardware
> rendering). Why even bother putting in DRM support if the DRM/DRI/XFree86
> people aren't going to make sure it doesn't break things on their end? I know
> Linus threatened to rip out DRM from the kernel because of any lack of
> direction and synchronization.
I don't disagree that better coordination would be a good thing. I merely
stated that the DRM development is handled by another group.
> >There is a goal to further reduce the differences between GATOS and XFree86,
> >but progress has been slow given the resources available to work on it.
>
> Well, this could be sped up if the CVS tree is opened up. I for one use
> GATOS-HEAD and XFree86-HEAD and would test out things (as I don't know X
> programming or the API).
Just opening up the tree won't fix all problems. There are design differences
between XFree86 and GATOS, and these are what is taking a long time to work
out. If you take code with a different design, and just drop it in, you will
have a good changes of breaking things elsewhere. Some of the perceived
slowness is casued by trying to maintain the design integrity of a huge code
base.
For projects where the CVS is wide open, there is still someone that gets to
make design level decisions to avoid these kindof problems. Figuring out
who should be responsible for which parts of the tree is one of the things
that would need to occur before CVS is opened up to everybody.
> >Politics has nothing to do with any of this. I don't know where people come
> >up with the idea that the Core or BOD is scheming again the community. They
> >aren't.
>
> >It's very simple. Things get accomplished when people put forth the effort
> >and resources to get things done. Not a lot of people have been doing this.
>
> They *cant* because nobody is willing to listen to what the community as a
> whole wants. That's the problem, If you can't open up the CVS tree how do you
> expect people to want to contribute to XFree86?
Listening to what the community wants, and opening up CVS are two different
problems. XFree86 has always listened, but has lacked the resources to do
everything the communitys wants. If sufficient resources were available to
respond to everyone, then there would be no need to open up CVS at all.
Working out the details of how to grant CVS access to more people it the
most productive way increase the resources that are available to work on
everyones requests.
> If you follow the Kernel development structure, having small forks of the
> kernel help because those changes get merged back into the mainline tree.
This happens with DRI and GATOS already, though the rate of merging may not
meet everyones expectations. Working out of the same repository would
certainly make this easier, but I think it would not have as large of an
impact on how the various developers go about doing things as people seem
to think.
> >Suggestions for lessening this learning curve are welcome, but more important
> >is the effort required to implement these suggestions.
>
> I don't about this, I haven't looked at the X API Manpages/PS/PDFs.
To do so would permit more constructive suggestions.
Stuart
Stuart R. Anderson anderson@netsweng.com
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149