New release process for 1.8 (READ THIS)

Jesse Barnes jbarnes at
Fri Oct 2 09:45:00 PDT 2009

On Fri, 02 Oct 2009 13:18:38 +0200
Michel Dänzer <michel at> wrote:
> > What're your concerns?
> First of all, surely the onus is on those who want to move the drivers
> into the xserver tree to present convincing arguments in support of
> it.

I think you've been present at some of the earlier conferences when we
discussed this.  The arguments haven't changed, we've just had more
experience with how well (or not) things are working.

My experience with xserver master has been poor lately.  And not just
due to proto changes; we've had some painful ABI breaks as well
(remember the DRI2 ABI stuff from 1.6.x?).  More than that, major
server releases have been inconsistently timed, mostly due to a lack of
developer time afaict.

Moving a core set (i.e. those actively maintained and required by most
X distributions) of drivers into the server would go a long way toward
making these issues less severe IMO.  ABI changes would include caller
updates in the same tree, making bisection much easier.  And driver
developers would suddenly have a large reason to make sure server
releases get out on time.

There are obvious downsides though; as you mention drivers with
incompatible licenses or that couldn't be in-tree for whatever reason
would still have to provide external releases (we'd still have to
preserve ABI across stable versions though), and it would likely mean
major driver changes would be released less frequently than they are
today (every 6 months instead of 3 or less).

> Anyway, this seems like a done deal, so I won't spend much more energy
> on it.

It's definitely not a done deal yet.  And it won't be until the drivers
move into the core repo.

Anyway, that's my thinking.  No conspiracy or anything.  I just want to
see regular, high quality server releases with well integrated and
tested drivers.  The Linux kernel uses this model, and while it
arguably makes life more difficult for people enabling new hardware, it
definitely has benefits for the project as a whole.

Jesse Barnes, Intel Open Source Technology Center

More information about the xorg-devel mailing list