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? > 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
pgpvcbtbfpQ3Y.pgp
Description: PGP signature
_______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel