X.org release engineering?

Adam Jackson ajax at nwnk.net
Mon Jun 8 13:20:00 PDT 2009


On Mon, 2009-06-08 at 12:24 -0500, Jeremy C. Reed wrote:

> - what has the elected board discussed for improving or changing the 
>   release engineering processes and scheduling?

Just to address this one point, recall that the Board is explicitly not
a technical body.  It exists to govern the organization, not the code.

Now, with my board hat off.  De facto technical governance has been
somewhere between meritocracy, junta and hazing ritual since
approximately the 4.4/6.7 split.  The release engineering goals have
been fairly loose guidelines rather than strict policy.  We could
certainly use more rigor, but I suspect that's more about people
actually getting off their butts and doing the work than about writing
it down.  I mean, we say we do katamari releases every six months, but
we clearly don't; writing it down and underlining it strenuously isn't
going to make it suddenly better.

So instead we have a moderately demand-driven release model that happens
to trigger the guilt reflex after about nine months.  Individual
components sync up with whatever server they think is convenient, but
practically speaking there's only like five of those, and they're pretty
much always buildable against at least the most recent server release
and git master.  The server goes to ridiculous effort to avoid breaking
ABI and bumps a major number internally when it does.  The library
interfaces never break, ever, with minor exceptions for non-app-facing
libraries like libXfont that really deserve to die painfully.

Testing is... informal is the polite word.  Nobody's stepped up to do it
rigorously, so no one does it.

Security is handled out of band like any other project.  We'll release
patches for at least the most recent release, probably do a point
release for same, and anyone shipping anything older gets to backport.

The actual server release is typically a two or three month cycle of the
release engineer branching, cherry-picking fixes from master while
skipping nonsense, and either cajoling other people into fixing
showstoppers or (more realistically, although unfortunately)
superheroing it themselves.  Eventually they get sick of it and call it
1.7.0.  Then people actually test and you do a 1.7.1 a month later.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20090608/a9d7f85d/attachment.pgp>


More information about the xorg mailing list