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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html