[Xcb] Thinking towards 7.6 katamari, including xcb

[Daniel Stone]

On Thu, Oct 22, 2009 at 04:48:36PM +0900, Keith Packard wrote:
> 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.

That would quite obviously be good, but we can still be smart about
how we time our six-month cycles.  I believe that timing it right
would result in a very short lag for Fedora, Ubuntu, and SUSE; given
that they're on six-month release cycles, a well-timed six-month
release cycle would have the same lag (or less than) than a three-month
cycle.

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

Only if it doesn't stifle the server development.

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

Sure, but OSVs and device enables are a reasonably special case.  Having
six-month cycles means that maintaining a stable branch is relatively
easy, since within a one-year timeframe, we only really have two
releases we care about, which surely shouldn't make most backporting
that difficult.

Given that everyone's on six-month cycles, having three-month cycles
means that we'd need to support four branches instead of two.  After
all, we can't really leave all the distros out in the cold (and
OSVs/OEMs certainly can't), so that's two branches we need to support.
And people would quite fairly be pissed if a stable tree was abandoned
after only three months' support, so we really need to support the other
two.

This is assuming that people aren't going to push new major releases
into their stable trees which, well, they aren't.  Probably not even if
our QA was up to the standard we hope it'll be at in two years, which it
isn't.

So, er, which part of this is easier?

(Also, assuming that not every driver will get merged in -- who's going
to be the one to make sure that every released driver builds with every
released server? Seriously, pciaccess was bad enough, and that was once,
not once every three months.)

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

I'm sorry that you made that commitment. ;) Maemo is shipping with a
server that's a git snapshot from February, but everyone involved
understands that we've just got to suck it up.

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

Well, you're arguably slightly biased on this front because you maintain
a driver, and I'm arguably slightly biased on this front because I don't
touch any drivers.  But I'd say that there's probably a lot more to a
useful 1.9 than drivers, but merging them in in order to fix our API
would definitely be a huge step forward.

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

And then they're left out in the cold, because in the eight months since
they picked up that stable version, we've shipped three new major
versions? That doesn't really seem like the definition of
OSV-friendliness to me.

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

Cool; no argument here.

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

That's fine if we've already decided on a three-month window; assuming
that our testing base for features which have not yet been merged is
small enough that we can go from first proposed for merge to shippable
in a .0 release in three or four months, I think having the compressed
schedule will actually cripple us.

Put it this way: it took, what, a year and a half to get MPX into shape?
Even when it was into master, so everyone was forced to deal with it.  I
don't disagree that it'd be a great position to be in, but I don't think
we're there yet.  If we get there and we feel like maintaining four
trees rather than two, then sure, let's sit down and look at three
months.  Right now though, it feels like either insanity (in putting out
four stable server releases per year -- which means supporting them, as
you well know from having to backport the world to server 1.2), or sheer
dishonesty (in that we're not going to be able to support what we've
only just shipped).

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

I'm not even thinking about the katamari: everything I've said in this
and previous mails applies to the server only (and the drivers to some
extent).

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

Think of it as stable/LTS if that helps.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091022/1054ee2c/attachment.pgp