[Xcb] Thinking towards 7.6 katamari, including xcb
Jesse Barnes
jbarnes at virtuousgeek.org
Thu Oct 22 02:32:03 PDT 2009
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
More information about the xorg-devel
mailing list