DRI CVS tree futures, was Re: [Xorg] DRI merging
Keith Whitwell
keith at tungstengraphics.com
Mon Jun 14 03:01:59 PDT 2004
Eric Anholt wrote:
> I am definitely in favor of the DRI X tree stuff being a branch on the
> X.Org tree.
I'd prefer to look at it slightly differently:
1) I'd like to get the current work in the DRI tree to a stable state, meaning:
a) finish (or part finish) Ian's NEW_INTERFACE work
b) import a stable version of mesa and the drivers into xc/extras, breaking
the need to track current mesa.
2) I'd like to see that stabilized Mesa and updated libGL work exported to
X.org and XFree86.
3) At this point, the DRI tree will contain nothing not in either X.org or
XFree86. Now, people can choose what they would like to do:
a) Continue using the DRI tree and all the merge hassles it has involved,
potentially with the extra bonus of 2 divergent trees to try and merge with.
b) Delete/disable the DRI tree. People who want to work on libGL.so, the 2D
DDX or indirect rendering can switch over to X.org where presumably everyone
who has demonstrated interest & aptitude will be able to secure CVS access.
or c) Delete/disable the DRI tree and try and do development by submitting
patches to XFree86.
After splitting off the drivers to Mesa and DRM to it's own project, I don't
see why the remaining X development work (DDX changes, libGL.so evolution,
indirect rendering changes, etc) can't just take place in the normal
development stream of X.org (or XFree86 for that matter) -- IE. I don't see
why there even needs to be a branch for DRI work as opposed to other X, DDX or
library work -- the distinction seems artificial.
Of course, it's not for me to say how X.org (or XFree86) should be developed,
but it does seem like the X development to be done by developers formerly
known as DRI doesn't differ in any huge respect from the X development done by
others.
If some particular project were particularly ambitious in its scope, then yes,
a branch might be in order, but I don't think that saying "oh, this is DRI
stuff, it should go on a different branch to regular X development" makes a
lot of sense.
Keith
More information about the xorg
mailing list