Instituting feature and infrastructure enhancement proposal window?

As I mentioned, I'd like to keep each cycle manageably shorter than 1.5.4 (which took 5 months that is 2 months too many).

This is still "a weather balloon", but I'd like to establish for each development cycle a feature and infrastructure enhancement proposal window, just like the kernel folks have "merge window".

 * These are outside of the scope:

   - Well-contained minor bugfixes,
   - Documentation updates,
   - Additional tests.
   - Updates to contrib/ and (what I consider) non-core parts,
     like gitweb.

 * Fixes to serious issues can delay and prolong the cycle.

 * The mailing list discussions and patch reviews are expected
   to continue as before, however:

   - Isolated new features that come after the window closes may
     be merged to "next" but won't graduate until the new release.

   - Infrastructure changes that have wider impact that come
     after the window closes won't even hit "next" until the
     new release.

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).

 * 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).

The important dates in the above would be (in parentheses are my straw-mans):

 * The first maintenance release (+1 week from the last release)

 * The rebuilding of 'next' (immediately after the first maint)

 * The close of the window (+6 weeks from the last release)

 * The -rc1 (+8 weeks from the last release)

 * The new release (+12 weeks from the last release)

For 1.5.5, I'd like to make the above +6 weeks a bit short and make it by the end of this month, though, so upcoming dates would roughly be:

 - By the end of February, the 1.5.5 window closes;
 - By mid March, 1.5.5-rc1 is tagged;
 - By early April, 1.5.5 is released.

Which would make this week for the discussion to pick which topic should be in 1.5.5.

Here are the current candidates I personally have in mind for topics that should be in 1.5.5:

 * describe --exact (Shawn)
 * checkout in C (Daniel)
 * format-patch --cover-letter (Daniel)
 * autodetect ncpu in threaded pack (Andreas Ericsson)
 * stash delete / stash pop (Dscho, Brandon Casey)
 * run-command API clean-ups (Johannes Sixt)
 * local branch tracking (Jay Soffian)
 * url rewriting (Daniel)
 * low-level merge improvements (Dscho)
 * apply --whitespace=fix improvements (me)
 * diff --relative (me)
 * diff --dirstat (Linus)
 - mergetool updates (Charles Bailey)
 - bisect vs cg-seek (Carl Worth)
 - worktree setup (Nguyễn Thái Ngọc Duy)
 - tightened object parser and walker safety (Martin Koegler)

One topic that is missing from the above list, which is queued in 'pu', worth mentioning is "gitdir: $path in .git" by Lars Hjemli. The situation is like Dscho's "reflog delete" before we did v1.5.4 in that it is waiting for a real user to prove this is a good enhancement. I am sure that later rounds would build enhancements to "git submodule" on top of this, and I think it is better to wait until that effort starts cooking.

Thoughts?