Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> And others, please spend time on testing the 1.8.3-rc2 to make sure >> what we are going to ship is free of embarrassing regressions. > > The whole purpose of this series is to avoid regressions, that's why I > sent them for 1.8.3. We agreed to make an exception to let remote-bzr updates go in even after v1.8.3-rc1, because it is too young and you can afford to check that the updated code will give only gains to its userbase that matters without hurting them by checking with Emacs and other projects. I do not recall us doing a similar exception for remote-hg. Did we? If we didn't, then a 10-patch series at this point in the cycle is way too late for me to be comfortable taking. We merged the 21-patch remote-hg series from you on Apr 21st, a week before -rc0, and it has been 3 weeks. Back then you thought it made things better without regression, and I expected that loose ends could be fixed by -rc1 with enough time to cook them in 'next' (meaning tying such loose ends would be just the matter of a couple of trivial patches at most). But now you are saying they regress things and need 6 (in 'next') + 10 + 47 patches to fix on top, in order not to hurt existing users? What is going on? People make mistakes and the initial submission being buggy is *not* a problem per-se, but what quality assurance do the 10-patch and/or the follow up 47-patch series have over these 21 patches to assure us that they do not introduce more problems, when we are this close to the final, way less than the 3 weeks we had? The best we could do to avoid regressions (if there are reported ones) is to revert specific changes that cause the regression that are already in v1.8.3-rc2. Which one(s) should we be reverting, and do you have a regression report that says the commit(s) in question breaks things for a specific project, and reverting it(them) makes things work again? -- 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