On Tue, May 14, 2013 at 1:21 PM, Junio C Hamano <gits...@pobox.com> wrote: > Felipe Contreras <felipe.contre...@gmail.com> writes: > >> On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano <gits...@pobox.com> 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?
The exception was for massive changes, theses are not massive changes, they are no-brainer fixes that would possibly fix regressions. > 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. Well, don't blame me if users hit regressions then. > 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? No, I sent *four* patches for 'master', which I eventually increased to ten, because the increased ones are all simple cleanups. And the fixes are obvious and can't possibly introduce regressions, specially since the important change re-introduces the same behavior we had in v1.8.2. The 47 patches I sent are for 'next', and are clearly marked as so. I included the same 10 fixes I sent for 'master', because they never landed on master. > 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? Read the patches and you would see. > 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? I am going to go one by one to show you the patches make sense for 'master'. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
