[Xcb] Thinking towards 7.6 katamari, including xcb

[Jesse Barnes]

On Thu, 22 Oct 2009 14:09:24 +1100
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
> 
> On Thu, Oct 22, 2009 at 10:44:35AM +0900, Keith Packard wrote:
> > Excerpts from Alan Coopersmith's message of Thu Oct 22 05:36:30
> > +0900 2009:
> > > The current Xserver 1.8 schedule calls for it to release on
> > > 2010-3-31. If we stick to the 6 month cadence well, then 1.9
> > > should be released on 2010-9-31.  (Though I still think it should
> > > be called 2.0 if the drivers do merge back into the xserver
> > > tarball.)
> > 
> > I'm hoping we can pull the 1.9 release in by three months and
> > having a very short merge window that just adds the drivers back
> > without other significant changes. To make this work, we'd need to
> > see trees with drivers merged back well before the 1.8 release
> > date. Driver maintainers with an interest in having their driver
> > integrated in 1.9 should consider posting merged trees for review
> > in the next few months.
> 
> What? Why?
> 
> 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?
> 
> 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.)

Well, Linux actually moved away from that model, and so far I think
it's been very beneficial.

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
  - tighter development practices, i.e. narrow merge window, necessary
    focus on stabilizing things (well stabilizing design at least,
    and probably most bugs) before then
  - less work to maintain stable branch than a long cycle

Cons:
  - shorter development cycle might make landing big, invasive changes
    harder (e.g. perpetually unready for the merge window can make for
    a vicious cycle)
  - less incentive to maintain a long lived and complete stable branch
  - shocking to users who are accustomed to randomly timed major releases

I think we already went over the pros & cons of integrated drivers, but
I think that discussion is largely orthogonal to this one.

Jesse