Re: [PATCH v3 00/10] remote-hg: fixes and cleanups

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 14, 2013, 20:02 UTC
Message-ID: <CAMP44s2cOg5xs1ZSmyL+0GDmuWTyn6CRtgsV0q4w=-CCfoYAYQ@mail.gmail.com>
In-Reply-To: <7vhai5juc9.fsf@alter.siamese.dyndns.org>

On Tue, May 14, 2013 at 1:21 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano <gitster@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.

Show 10 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 6 quoted lines

> 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