[Xcb] Thinking towards 7.6 katamari, including xcb

[Keith Packard]

Excerpts from Peter Hutterer's message of Thu Oct 22 23:15:36 -0700 2009:

> How many of these requests were driven by our permanently late release
> cycle? i.e. would an actual 6 month release cycle classify as "shorter
> release interval"?

Well, 1.6 was released 6 months after 1.5, and 1.8 will be released 6
months after 1.7, so we're actually not doing too badly on average
here.

> Is there enough churn in the server to warrant more frequent releases?
> The larger changes are mostly complete now and looking at my schedule I
> doubt XI2.1 will land for 1.8.

Once we merge the drivers back into the server, the level of change in
the overall package will go up dramatically. Yes, I'm hoping that the
feature set in the core server will stabilize, but we've got a pile of
API/ABI changes to work through that we can only realistically do with
integrated drivers.

> If there aren't enough features, having extra releases and the associated
> branches increases the time spent release-managering. looking at how close
> 1.7 is to master I wonder if we'd end up with multiple branches that are the
> same except for a few patch sets.

My hope is that our need for backporting changes will be reduced by
shrinking the release window. We had several 1.6.x releases mostly
because 1.7 was a delayed -- there were features pending on master
that OSVs needed to ship before 1.7 did. I back-ported more than just
bug-fixes here, which I wasn't entirely happy about.

> How long do you want to maintain stable branches? Or do we just keep
> maintaining _some_ stable branches and let the others rot? If so, which
> ones?

I'd be willing to ship two versions and back-port patches from master
to both of those (so, 1.7.x and 1.8.x while 1.9 is in
development). That's more than we've done in the past, and provides a
6-9 month window given 3 month release cycles.

> 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.

> tbh, I'm not convinced yet of the benefits of shorter release cycles
> (shorter than 6 months, that is).

I can't support a 6 month cycle in my video driver, and I doubt other
video drivers could either; hardware changes too fast. If the video
drivers are to be re-integrated into the server, we'll need some
compromise in how often the X server is released.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091026/81ad0e37/attachment.pgp