xlibs: Moving forward
Jim Gettys
Jim.Gettys at hp.com
Fri Nov 5 10:59:13 PST 2004
Seems like a plan.
The biggest question I have is understanding how to get Xlib itself from
its current state to production, as in fact, it has serious work in it
that isn't reflected in the monolithic tree.
This work seems to be of two kinds:
o the integration of XCB
o a lot of other XKB related and I18N stuff.
The first of these (the XCB integration), per my discussions with
Jamey Sharp, seems to be a simple integration of the XCB work with
conditionals affecting 8 files that allow XCB to replace the old Xlib
XlibInt.c transport (and use generated stubs). One can build Xlib
either to use XCB, or build Xlib the conventional way to use the
horrifying (and broken) XlibInt.c of yore. I took a quick look the
integration, and didn't see anything that frightened me. I need to do a
careful review of this integration as a sanity check that it doesn't
affect anything when built without XCB enabled, which I haven't yet
done. (other eyeballs very welcom).
As it is a fundamental reimplementation of a key piece of the
technology, to ship the XCB transport in production (as opposed to
building Xlib in the old way, using the tried and true horrifying code)
we're going to need to have some extensive soak time in pretty
widespread use; I know Debian unstable has been a possibility for that
sort of testing.
The other stuff I have less insight into is Sergey Oudaltsov's extensive
work. Do we have insight into it? And again, how do we get it tested?
- Jim
On Fri, 2004-11-05 at 09:46 -0800, Daniel Stone wrote:
> Hi all,
> Unfortunately, since some time before X11R6.8, the modular tree has been
> getting very little love. By 'very little', I do, of course, mean
> 'none'.
>
> I was working on a set of modular packages for my distribution, but the
> choice was made to run with a monolithic tree instead, thus my work on
> it (which you may have noticed on xlibs-commit) halted for a while,
> while I worked flat out on monolithic packages.
>
> Now I have some small amounts of time again (in between more packaging,
> trying to get our patch system into order, and trying to see some of
> Køenhavn while I'm here), I'm revisiting xlibs.
>
> My goal is to release versions of every single module as soon as
> possible -- yes, pre-merge. Right now, most of them are in quite good
> shape, and it should be one hundred per cent fully bootstrappable from
> scratch. I'm getting back on this, as I said, and hope to commit my
> local changes to all the modules within the next few days. As I make
> new versions, I'm uploading to
> http://freedesktop.org/~xlibs/xlibs-1.0.1/proposed-tarballs/ -- on the
> understanding that these are PROPOSED tarballs and bear no claim to
> reflections on reality.
>
> After 1.0.1 is out the door in its pre-merge state, I propose a full
> merger between the monolithic and modular trees, code-wise (more on that
> soon -- watch this space!), and we then get modular 1.1.0 out the door.
> After that, we can start using the modular system to its full extent,
> and start working separately on individual libraries, with their own
> release schedules.
>
> The only modules I'm aware of that aren't imported at all thus far are
> Xevie and Xdmx.
>
> Comments/suggestions/beer?
> -d
>
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg
More information about the xorg
mailing list