On Sun, 24 Feb 2008, Junio C Hamano wrote: > > The important dates in the above would be (in parentheses are my > straw-mans): On the merge window issue: I can heartily recommend it, but for the kernel we have noticed: - people get really antsy it the releases are more than two months apart. Quite frankly, six weeks would be better, but it's just not realistic. - the kernel has to have a long stabilization phase, and I largely blame the fact that we have so much different hardware (and driver and arch changes are generally much more than 50% of all changes anyway). So we arguably need wider testing than projects that are more "repeatable" on a smaller set of machines. So I think the merge window has worked out beautifully, but in a perfect world, I'd make the window be roughly half the time of the release (rather than about 20% as it is for the kernel), and aiming for a six-week release timing. And I think both of those should be reasonably easy to hit within the git development model. So I would basically cut you target timeframes into half (except for the first -rc release - there's no point in making that less than a week). Three months is just going to make people who miss the release window antsy. It's what the kernel has in practice, and I would *not* advocate it as ideal - I actually aim for 2 months and we then invariably slip a bit.. So I'd suggest: - first -rc in 1 week - window closes in 3 weeks - next release in 6 weeks - rinse and repeat and if you worry that there won't be enough changes to merit a release, trust me, that's the *good* schenario. Nobody will ever mind releases that aren't disruptive, and you'll have an easy case with making them too. There really are no downsides to having an easy release cycle with not a lot of big changes. I _wish_ I had more of those. And on exactly that note: > * diff --dirstat (Linus) I actually actively use this (not just for -rc releases, but I find it nice to do occasionally in other cases too), so it would be really nice if at least the initial version got merged soon. Even if it gets the binary case wrong, and even if the statistics would arguably be better based on "damage" instead of just number of lines. Of course, I have it in my tree regardless, but especially with me then publicising the feature in my -rc releases (another one coming up today), I'd hope that you'd merge it so that others can use it too.. If this was at the end of a merge window, I'd hate to have to wait 1.5 months for the next one to open. Linus - 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
