Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)

Jeff King [off-list ref] writes:

On Tue, Mar 03, 2009 at 01:01:45AM -0800, Junio C Hamano wrote:

quoted

As an experiment, 'next' and 'pu' stayed open during this release freeze;
new topics have been accepted.  I have to say that the experiment was a
moderate success, and many topics in 'next' seem to be of fairly high
quality already, which would mean that we will have a shorter cycle before
1.6.3.

I was going to stay quiet on this issue until after 1.6.3 released, but
now you have opened the topic. :)

I think seeing the quality of topics in 'next' is only half of
"success". You have to also consider how much attention was given to the
about-to-be-released version (and its impact on quality). And I think we
won't know about that until we see how quickly we need 1.6.3.1. :)

Personally, I know that I have spent much less time focusing on
'master'. Like everyone else, I have limited git bandwidth, and topics
in 'next' are simply more interesting. I think it's easier to put them
aside for a few weeks if everybody agrees to do so (rather than having
interesting discussion proceeding without you if you choose to focus on
'master').

With the first maintenance release after 1.6.2 behind us, I think we can
start to judge how successful the 1.6.2 cycle was fairly objectively.

During the pre-release freeze, we would want to encorage people to spend
as much time as possible on finding and fixing bugs and regressions in the
frozen 'master', and that was the reason why traditionally we closed
'next' during the pre-release freeze.

But in reality, contributors who had leftover topics on 'next' simply
stopped working on their topics on 'next' without spending the freed up
time on concentrating on 'master'.  In an ideal world, the choice would be
between "git time on 'next'" vs "git time on 'master'", and closing 'next'
was meant to force the choice, but instead the outcome became "less git
time until 'next' reopens".

My suspicion, when deciding to keep the 'next' branch open during the
freeze, was that as long as people look at _any_ git code, even if it is
because they are working on their own topic that will never be in the
upcoming release, it would increase the chance of bugs getting discovered.

I do not know the exact count of bugfixes after 1.6.2-rc0 are attributable
to people who happened to notice glitches by accident while working on an
unrelated enhancements, but for me personally, I tend to notice more bugs
when I am not hunting for one but working on something else.

Also as a side effect, we had many topics on 'next' that are already
reasonably mature after 1.6.2, and I think we can have a short cycle for
the next one.