Re: Instituting feature and infrastructure enhancement proposal window?

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*