[Xcb] Thinking towards 7.6 katamari, including xcb

Bryce Harrington bryce at canonical.com
Mon Oct 26 22:44:00 PDT 2009


On Mon, Oct 26, 2009 at 01:28:40PM -0700, Keith Packard wrote:
> > Deployment is -largely- distro driven. with our past track record regarding
> > QA I'm not sure how many distros are willing to deploy a new server update
> > during their stable cycle. At which point you end with server releases being
> > skipped by distros altogether.
> 
> I doubt we'd manage to skip all of the distros, and in any case,
> re-integrating the drivers into the server should help bring back
> people willing to try a new X server/driver combo.

If it helps at all to hear from one of the distros, I can outline some
of the process and problems in the decision making we've gone through
for X versions in Ubuntu.

The main constraints I have for selection of X components in Ubuntu are
these freeze dates:

                      .04 release           .10 release
                      
  FeatureFreeze:      End of February       End of August

  BetaFreeze:         End of March          End of September

If the X release happens before FeatureFreeze, it's a no-brainer, we
ship everything from the X release (we can pull from Debian).  Upstream
can be happy since bug reports and patches are against their latest
release.

If the X release happens after BetaFreeze, it's also easy since it's
just too late to update stuff.  Upstream would be less happy in this
scenario since Ubuntu bug reports and patches will be against the
previous version.

But most commonly, the release comes between FF and Beta, and things are
tricky.  We have to pick on a package-by-package basis between staying
with the old version and risk not having the newest features, or
shipping a new version and risking having a buggy X.


In a perfect world, the stable X.org release would hit just prior to
FeatureFreeze - one in mid-Feb, the other mid-Aug.  In this world,
Ubuntu would be shipping the latest X.org release all the time, and bug
reports and patches would always be against the version of things that
upstream wants to support.

Bryce


More information about the xorg-devel mailing list