[Xcb] Thinking towards 7.6 katamari, including xcb

[Keith Packard]

Excerpts from Daniel Stone's message of Thu Oct 22 12:09:24 +0900 2009:

> What? Why?

Doing more frequent releases will obviously reduce the lag between
implementation and deployment; this should do lots of good for
everyone involved. I get constant requests for shorter X server
release intervals, enough so that I'm willing to do the work to make
it happen if that's OK with the X.org community.

The Intel driver is on a quarterly release schedule at this point, and
we've been getting good feedback on this process from Linux OSVs and
other users of the driver. Obviously sticking to schedules is a key
part of any benefit to the OSVs here, and in my experience, shorter
schedules are easier to hit than longer ones. Yes, it's a lot of
release management, but as I said, I'm willing to make that happen.

In any case, I've already committed to quarterly Intel driver
releases, so either the X server as a whole gets released on this
schedule or I'll end up doing a separate 'old X server + new intel
driver' release every other quarter. That would suck.

Independent of the release schedule, getting people thinking about how
drivers will get integrated should improve the chances of a successful
1.9 release.

> If 7.6 in December 2010 seems like a good idea, then what's the point of
> doing 1.9 in September 2010?

Few OSVs track just the katamari anyway; with drivers integrated into
the server, we've got a complete and consistent X server that is
deliverable at all times.

Getting 1.9 done with the drivers integrated lets me get started
merging API/ABI changes in the server, something which I find long
overdue. I'll be posting patches for review in this area shortly.

> Is the thinking to ram all the features we
> need for the next year in to 1.8, do a short 1.9, seriously[0] maintain
> it as a stable branch and keep it going and ship 7.6 with a more
> plausible 1.9.5 or thereabouts, and then do the feature dance again for
> 1.10?

Nope; my plan is strictly time-based releases that contain whatever
features are ready at that time. I'll push my requirements to match
the merge window, and I'd hope that other people would be willing to
do the same. Doing these frequently reduces the cost of missing a
particular release, letting us push things off that aren't quite
ready. Of course, OSVs will be able to pull such features into their
packages as necessary to hit their customer requirements where said
features are not yet released upstream.

The key here is to get features ready for the merge before the merge
window opens. We can merge huge changes in a short time if they've
seen review and general agreement on the design. The release schedule
shouldn't in any way drive broad feature development schedules, other
than the final alignment with a suitable merge window.

Frankly, I see the katamari process as less urgent once we merge the
server and drivers back together -- we've always had an extremely
strong API/ABI guarantee across the wire/kernel interface, and that
isn't changing anytime soon. That means that the promised testing and
integration offered by the katamari will be less important as the less
stable driver API/ABI is removed as an external interface.

> If so, is this something we want to think about doing long-term? (If so,
> we might want to invert our cycles to stick with the x.y : y ->
> odd/unstable, even/stable convention used by pretty much every other
> open source project ever.)

I'd like to say that all of our releases are stable releases --
unstable work should occur in feature branches or separate repositories.

> (And +1 to the Dec 2010 schedule as well.  Not only does it sound
>  plausible and give us more time to get our user[1]-facing APIs as good
>  as possible while letting us rip the server to shreds, I don't see
>  anyone else stepping up to do the thankless katamari work.)

Agreed -- building the client-side pieces is still too much work to
even contemplate on a more frequent basis. Thanks again to Alan for
stepping up this time around!

-- 
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/20091022/258275bc/attachment.pgp