On Thu, 22 Oct 2009 22:53:52 +1100 Daniel Stone <dan...@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 <dan...@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 _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel