Excerpts from Peter Hutterer's message of Sat Sep 26 08:08:42 -0700 2009: > 1. Feature branches: > 2. Three stages: feature merge - bugfix - release freeze > I think 3 + 2 + 1 months should be approporiate for the various stages. > 3. Predictable time-based releases
I like this proposal, one question I have is whether 3 + 2 + 1 is the right ratio. The kernel does it backwards, with feature merging happening in a fairly short time followed by the first RC, then a lengthy amount of testing/fixing before the final release. But, the kernel also runs a much faster clock and so missing a feature merge window doesn't cause as much delay before release. One potential change I might suggest is the wiki-based bug-application method that we've been using for the 1.6 releases. I've really found that a great way to avoid losing patches. And, frankly, cherry-pick is a whole lot easier to work with than applying patches from email. The only question is where such patches should be stashed while waiting to be applied, as we wouldn't nominally have a valid 'master' to pull from. So, I think we should give this a try for 1.8 and see how it goes; it seems mostly like a formalization of the current process. -- [email protected] _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
