Jeff King <peff@xxxxxxxx> writes: > On Tue, Mar 03, 2009 at 01:01:45AM -0800, Junio C Hamano wrote: > >> 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. -- 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
