warnings

[Adam Jackson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 03 September 2004 13:50, Ray Lehtiniemi wrote:
> On Fri, Sep 03, 2004 at 01:15:50PM -0400, Adam Jackson wrote:
> > I would probably prefer that debrix only be used for developing the
> > autotoolery, and that debrix pull from the monolithic tree until such
> > time as the autotooled build process is felt to be sufficiently stable -
> > at which point we'd stop calling it debrix and start calling it Xorg.
>
> just grabbed a copy of debrix, and it seems to be only the
> xc/programs/Xserver subtree, correct?  what happens to the rest of the tree
> when debrix becomes xorg?

Multiple meanings for the same word, unfortunately.  Debrix means both the 
modularisation project, and the core server component within that project.  
The pieces are broken out individually where possible, eg in 
debrix-input-mouse or debrix-extension-dbe or debrix-driver-ati.

The current major blocker is GL support, where we have lots of interdependent 
code with no real clear way to split some of it apart.  From memory, both 
libGL on the client side and glx on the server side need common code, and 
both GLcore and the client libGL require a Mesa tree to build, and anything 
DRI-aware requires the libdrm headers, and... it's still a bit of a mess.

In principle you should be able to build the extensions from the inside out 
(drm before dri, GLcore before glx), and you should be able to build a 
GLX-aware libGL straight from Mesa.  In practice we're not there yet.  Also 
GLcore needs to be replaced with a software renderer that looks like a DRI 
driver, as phase one for teaching the X server to be a DRI client, which 
would allow us to do accelerated indirect rendering (read: quake3 across 
multiple cards using DMX).

The order in which these should be resolved is still an open question, and 
perhaps not one that should be decided in advance.

> > I suppose that's Daniel's call to make though.  I know Jakub Stachowski
> > has been doing some cool stuff in the debrix tree, but as far as the
> > source itself goes I'd rather not deal with cross-syncs.
>
> amen.  with cvs it's pretty horrible.  bitkeeper seems to be quite a bit
> better.  not sure how tla handles things, i've not used it yet...
>
> are there plans to move all of x.org onto tla or bitkeeper at some point?

Definitely not bitkeeper, for the usual freedom reasons.  Insert plug for "tla 
star-merge" here; the problem being that no matter what SCM you use you're 
still not going to be able to cross-merge between it (in debrix) and CVS (in 
the monolithic tree), which you'll need to be able to do until the autotooled 
build process is shaken down.

The problem as I see it is that switching from CVS is only worthwhile if you 
switch away from CVS - note that subversion doesn't count as away from CVS - 
but that doing so requires a serious mental shift on the part of the 
developers.  If we can't provide a decent cheat sheet for CVS users then we 
may as well not switch, because we absolutely don't want to lose developers 
over it.

- - ajax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBOOkYW4otUKDs0NMRAs5jAJ9tG8PHDf8bsvhHn54X7969pOuCVwCffCrA
C2Bjiew1HR4D6YgOxkcocP8=
=dscG
-----END PGP SIGNATURE-----