On Sun, 24 Feb 2008, Junio C Hamano wrote: > If this proposal is accepted favorably by the list and is > implemented, a release cycle will look like this: > > * A release from 'master' is made (e.g. v1.5.4 gets released on > Feb 1st). > > * The release is merged to 'maint'. > > * Fix-ups to v1.5.4 start flowing and get applied to 'maint', > and merged to 'master'. At some point, the first maintenance > release is made (e.g. v1.5.4.1 was released on Feb 10th). > > * The topics that have been cooking in 'next' may be rebased to > v1.5.4, and 'next' is rebuilt on top of 'master' with them > (e.g. this happened on Feb 17th for this cycle). I'd actually like to have topics that don't make a release reverted in 'next' and reapplied in 'pu'. That way, from the release to the rebuild of 'next', 'next' and 'master' have identical trees, and it's therefore trivial to rebase off of 'next'. Topics that were moved out to 'pu' in this period would presumably be merged back into the rebased 'next' early. Or maybe, when 'next' closes, anything not in 'master' moves out to 'pu' until the rebuild. > * New topics start appearing in 'next', cook and graduate to > 'master' as before. > > * The window closes. We pick what topics we should have in the > new release. > > * We continue as before, but with the understanding that some > topics in 'next' won't graduate before the new release. > > * Tag -rc1. 'next' really closes and we go into feature > freeze. > > * RC cycle continues. Perhaps one or two RCs every week, as before. > > * The new release is made (hopefully within 3 months since the > beginning of the cycle). So what would be the 'pu' policy through this? I think one of the reasons that the kernel manages to do well with a short cycle is that stuff sits in -mm for some time, in general, before hitting mainline. This both means that people can get their code exposure without hurrying it into the merge window and that code can cook as long as necessary before starting to impact end users. In any case, I like the short cycle idea. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
