Release process for Xorg 7.1

[Adam Jackson]

Hey, so.  7.1.  (Code name: Energon.)

I posted a schedule a while ago, no one disagreed, so it sticks.  For 
reference that was:

Branch nomination for 7.1: March 17, 2006
Branch selection for 7.1: March 31, 2006
7.1RC1: April 7, 2006
7.1RC2: April 28, 2006
7.1RC3: May 12, 2006
7.1 Release: May 19, 2006

Okay, so I'm jumping the gun a bit on nomination, but there's no harm in 
starting discussion early.  What we're doing in this phase is evaluating the 
list of modules that have changed since 7.0 to decide how to treat each of 
them.  There are several options:

- Stabilise the module in place, release from its HEAD
- Branch the module at HEAD on the 31st for stabilization, development 
continues on HEAD
- Select an existing stable branch of that module for inclusion in the 7.1 
rollup (or "katamari" if you will)
- Ignore the changes and don't update or include that module for 7.1

I expect a mix of each to be employed, and that's a good thing.  So let's 
break it down.  If I'm off base on any of these, kindly correct me.

Apps: compiz, glxcompmgr, mkfontdir, rendercheck, setxkbmap, smproxy, x11perf, 
xdm, xdriinfo, xfs, xinit, xkbevd, xman, xrefresh, xshowdamage, xwininfo.

Four of these are new, compiz glxcompmgr rendercheck and xshowdamage.  None of 
them are required for normal server operation, so my preference would be to 
not consider them part of the 7.1 bundle.  The expectation here is that app/ 
takes the place of the historical 'contrib' section or the more 
recent /cvs/xapps, in that it is hosting but not necessarily endorsement.  
7.0's app set was driven by parity with 6.9; we should be moving away from 
providing all but essential applications as part of the base Xorg 
distribution. 

The others I think are all minor bugfixes worthy of releasing.  For 7.2 we 
should look at formally trimming the set of apps we consider part of the 
distribution.

Data: xkbdata

The only change here is adding support for the evdev driver on linux.  My 
understanding is that xkbdata is to eventually be supplanted by the data 
files from xkeyboard-config; if so this change should be 
replicated/translated there and xkbdata left to rot.

Doc: xorg-docs

We got a maintainers file, and updates to the specs for Composite, Damage, 
Fixes, and Shape.  This one's easy.

Drivers, input: citron, evdev, magictouch, mouse, vmmouse

All of these are either bugfixes or important new functionality, should get 
bumped where appropriate and incorporated.

Drivers, video, clear and active maintainers: i128, i810, mga, nv, sis, sunffb 
(by proxy), trident, tseng, via, vmware

i128 changes are trivially correct, just bumping to new EXA.  mga has some 
cleanups and features I'd like to get merged, but they're quite low impact so 
can probably be done straight from head.  sunffb's changes are almost 
entirely nuking support for xf8_32wid, which I did with davem's blessing, so 
that can be released straight from head.  I can't speak for any of the 
others, so I need maintainer input here.

Drivers, video, communal maintainership: apm, ark, ast, ati, fbdev, glint, 
imstt, newport, nsc, rendition, s3virge, savage, siliconmotion, vga.

ast is a contributed driver from aspeedtech, should go in.  fbdev, nsc, and 
newport appear to be man page updates only.  Most of the rest look like minor 
bugfixes, the exception being ati which OH MY GOD SO MUCH HATE.  I would 
strongly appreciate someone closer to the code telling me what's going on 
there.  As a longer term project, we really need the ati driver to be 
properly split in three for each of mach64/rage128/radeon, because one the 
ati prober is crap, and two it's bad modularity.

Libs: X11, Xres, XScrnSaver, Xcomposite, Xcursor, Xdmcp, Xevie, Xfixes, Xfont, 
Xfontcache, Xrandr, Xt, Xxf86dga, Xxf86misc, Xxf86vm, xkbfile.

XRes, XScrnSaver, Xevie, Xext, Xfontcache, Xi, Xrandr, Xt, and Xxf86* look to 
all just be build fixes.  Xdmcp, Xfont, and xkbfile are minor bugfixes by all 
appearances.   Xcomposite and Xfixes are slightly in flux due to the recent 
kerfuffle about where exactly they live; I'm operating on the assumption that 
they live in CVS until 7.1.

Xlib is an unknown.  I'd really like to see the XCB stuff released, but it 
hasn't had even an "0.9" release seeing testing.  I hear it's approaching 
stability though, and if the --enable-xcb feature from the old /cvs/xlibs 
version is still in place then my fear diminishes significantly.  Feedback 
plz.

Proto: Composite, Fixes, GL.

BORING.  All stable, ship yesterday.

Util: cf, gccmakedep

Small fixes, should be incorporated.

And then, of course, the server.  It's pretty clear that we'll need to create 
a stabilization branch by the 31st.  What's not clear is what big remaining 
work wants to land before then; aiglx was my big wishlist item and that's 
landed now.  If you have projects that want to land in the next two weeks, 
and that you think can stabilize enough for release in the six following, 
speak up quickly.

Peripherally, the server will want a Mesa release to build against (one last 
time, hopefully), so we probably need to do a 6.5 on about the same 
timeframe.  I'll punt timing of that to Brian.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060315/6b7bf3b8/attachment.pgp>