[Xcb] Thinking towards 7.6 katamari, including xcb

[Daniel Stone]

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?

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

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

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

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?

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

Yep.  MPX would be, er, challenging.

>   - less incentive to maintain a long lived and complete stable branch

As above.

>   - shocking to users who are accustomed to randomly timed major releases

Phoronix won't even have anything to write about!

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

It's mostly orthogonal, but I think that having integrated drivers is
one of the things that makes 3 month cycles possible.  Merge all the
drivers (at least all the ones we care about) and have a decent story
for updating the others to new APIs and making sure they build and run
with every released server version we have, and then I'll drop most of
my objections.

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/81eb7d97/attachment-0001.pgp