[Xcb] Thinking towards 7.6 katamari, including xcb

[Jesse Barnes]

On Thu, 22 Oct 2009 22:53:52 +1100
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
> 
> On Thu, Oct 22, 2009 at 06:32:03PM +0900, Jesse Barnes wrote:
> > On Thu, 22 Oct 2009 14:09:24 +1100
> > Daniel Stone <daniel at fooishbar.org> wrote:
> > > If 7.6 in December 2010 seems like a good idea, then what's the
> > > point of doing 1.9 in September 2010? 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?
> > 
> > Well, Linux actually moved away from that model, and so far I think
> > it's been very beneficial.
> 
> And to the three-month (give or take) model, no?

Right.  That's also been a big help.

> > To summarize some off-list discussion:
> > 
> > Pros of a shorter release cycle (e.g. 3 months)
> >   - shorter lag time between new features & invasive bug fixes and
> >     those bits landing in distros
> 
> Not really.  Distros ship when they ship, which right now is six
> months. And the ones people care about tend to freeze within an
> acceptable distance of each other, so thinking about it and timing
> your server releases properly means you can get a very short
> time-to-distro.

Distros have to coordinate several packages of software though, and
there's always going to be conflicts between ones you care about.
Having frequent releases can mitigate that.

> >   - tighter development practices, i.e. narrow merge window,
> > necessary focus on stabilizing things (well stabilizing design at
> > least, and probably most bugs) before then
> 
> No doubt.  I think to some extent this depends on merging the drivers
> though, unless we stop offering the guarantee (of sorts) that drivers
> will build against every previously released server.

Yeah, having the drivers there would probably help...

> >   - less work to maintain stable branch than a long cycle
> 
> Sure.  It's less work to maintain _a_ stable branch.  However, the
> cost of maintaining four stable branches, the oldest of which dates
> back a year, is greater than the cost of maintaining two stable
> branches, the oldest of which dates back a year.  Unless our plan is
> to abandon certain releases, which is what I was getting at with the
> odd/even numbering.

Realistically though, upstream doesn't maintain older stable branches;
distros always have specific patches they've backported into their
released package, independent of what upstream does.  If you think we
need to maintain 4 stable branches going back a year though, then yeah
I see your point.

> If our support cycle is one year, then we need to maintain four
> branches; I strongly doubt that will happen to an acceptable standard.
> Someone will always be left out in the cold.  If that happens, then we
> need to be honest about that up front: we need to say 'sure, you can
> use this, but in nine months or less, you'll be on your own'.
> 
> Which puts a bit of a dampener on the whole lower-time-to-distro
> thing, no?

Not really; if you're relying totally on upstream to handle your bugs,
then as a distro you're in big trouble.  Distros are supposed to be
where projects get polished into a real product, as opposed to just
being rough cut building blocks (except perhaps in the case of actual
end-user applications).  I don't think that means we can ignore bugs,
but it should mean we don't have to handle all of the logistics of
tracking bug fixes back into N stable release branches.

-- 
Jesse Barnes, Intel Open Source Technology Center