Release process for Xorg 7.1

[Johnson, Charles F]

I'd definitely like to see Mesa 6.5 in tandem with X11R7.1.  Rotation
support that went into the i810 driver also needs the updated Mesa.  

The other i810 video features would be:

Intel 945GM Integrated Graphics support.
ACPI Video Hotkey.
Rotation (as mentioned above.)

Other changes I'm not familiar with, Alan Hourihane will have to
enumerate.

Charles Johnson
Channel Platform Solutions Group
Intel Corporation
charles.f.johnson at intel.com
503-712-5181
>-----Original Message-----
>From: xorg-bounces at lists.freedesktop.org [mailto:xorg-
>bounces at lists.freedesktop.org] On Behalf Of Adam Jackson
>Sent: Wednesday, March 15, 2006 7:12 PM
>To: xorg at lists.freedesktop.org
>Subject: Release process for Xorg 7.1
>
>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