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?
-
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
