On Thu, Oct 22, 2009 at 04:48:36PM +0900, Keith Packard wrote: > Excerpts from Daniel Stone's message of Thu Oct 22 12:09:24 +0900 2009: > > > What? Why? > > Doing more frequent releases will obviously reduce the lag between > implementation and deployment; this should do lots of good for > everyone involved. I get constant requests for shorter X server > release intervals, enough so that I'm willing to do the work to make > it happen if that's OK with the X.org community.
A few questions: How many of these requests were driven by our permanently late release cycle? i.e. would an actual 6 month release cycle classify as "shorter release interval"? Is there enough churn in the server to warrant more frequent releases? The larger changes are mostly complete now and looking at my schedule I doubt XI2.1 will land for 1.8. If there aren't enough features, having extra releases and the associated branches increases the time spent release-managering. looking at how close 1.7 is to master I wonder if we'd end up with multiple branches that are the same except for a few patch sets. since we need to cherry-pick, you get the chance to reproduce bugs in interesting ways - cherry-picked to 1.7 but not to 1.8, but it is on 1.9, etc. How long do you want to maintain stable branches? Or do we just keep maintaining _some_ stable branches and let the others rot? If so, which ones? Deployment is -largely- distro driven. with our past track record regarding QA I'm not sure how many distros are willing to deploy a new server update during their stable cycle. At which point you end with server releases being skipped by distros altogether. IMO we don't have the testers yet to make all that happen. As it is, I'm permanently switching from master to 1.7 to my devel branches to make sure I get half-decent coverage. I'm not sure how much exposure the various personal trees get right now. tbh, I'm not convinced yet of the benefits of shorter release cycles (shorter than 6 months, that is). Cheers, Peter _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
