1.7.0 release plans

[Junio C Hamano <gitster@pobox.com>]

As I've been repeating lately, I'd like to tag 1.7.0-rc0 this weekend.

We don't have any written, official-looking rules for patch acceptance
during the -rc period, and have been playing by ear.  The rule of thumb is
that if a patch is not in 'master' by the time 1.7.0-rc0 is tagged, it
won't be in 'master' until 1.7.0 final is released, unless it is:

 (1) a fix to a regression caused by changes since 1.6.6;
 (2) an obvious fix to a new feature we added since 1.6.6; or
 (3) an obvious fix to a problem we had even before 1.6.6.

When you have a patch that adds yet another new feature that you think
complements what we already added since 1.6.6, you could argue that the
patch falls into the second category, by saying something like: "the new
option to do X is not complete without configuration variable that tells
git to do X by default, and another option to override the configuration".
We need to discuss and judge if the the argument has merit, which would
largely depend on what that X is.  So the above list is not completely
black-and-white.

We'll cook 1.7.0-rc0 for a week or so, accumulating fixes and then tag rc1
by the end of this month.  After that, only fixes in category (1) and
perhaps really obvious ones in category (2) will be applied for rc2, which
should happen around Feb 10th.  I am hoping that we can cut the final
release around mid February.

I don't know if I have enough bandwidth to review and queue patches that
fall outside of the above "meant for 1.7.0" criteria to 'next/pu' branches
during the feature freeze, but that doesn't mean I'd discourage people
from working on their own topics meant for post-1.7.0 cycle. Hopefully we
have enough qualified people to help reviewing them.

In any case, I'll be moving my focus to the 'master' branch from now on,
and I ask contributors to help hunting and fixing problems in 'master', so
that we can have a solid 1.7.0 release (on top of which you can build your
favorite shiny new toys ;-).

Thanks.