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

2013-05-14 Thread Junio C Hamano
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?

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


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

2013-05-14 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes:

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

Ahh, OK, I miscounted.  The 10 were supposed to replace 6 and then 47
in turn are supposed to replace the whole thing, while these are
still *not* in 'next'.

OK, will replace fc/remote-hg that is currently on 'pu' with the
latest (v4 */47).
--
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


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

2013-05-14 Thread Junio C Hamano
Felipe Contreras felipe.contre...@gmail.com writes:

 On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:

 Folks interested in working remote-hg, please try it out, so that we
 can have a polished one soon after 1.8.3 ships (I am not saying this
 round is not polished---I haven't even looked at the patches).

 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.

 If we want folks to test something, it should be the patches I
 prepared for 'next' which I just sent.

Yeah, but that is for the release _after_ 1.8.3; I'd rather see
folks help to make sure we have a solid 1.8.3 relaese.
--
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


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

2013-05-14 Thread Felipe Contreras
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


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

2013-05-14 Thread Felipe Contreras
On Tue, May 14, 2013 at 1:59 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:

 Folks interested in working remote-hg, please try it out, so that we
 can have a polished one soon after 1.8.3 ships (I am not saying this
 round is not polished---I haven't even looked at the patches).

 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.

 If we want folks to test something, it should be the patches I
 prepared for 'next' which I just sent.

 Yeah, but that is for the release _after_ 1.8.3; I'd rather see
 folks help to make sure we have a solid 1.8.3 relaese.

That's the intention of the ten patches I sent for 1.8.3. But you said
you are not going to put them in 'master', but in 'next', so I sent
the ones I think should go into next.

So now you have the patches that I think should go into 'master' (10),
and the ones for 'next' (47, including the previous unmerged 10).

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


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

2013-05-13 Thread Felipe Contreras
On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 Since the last series is not merged to master yet, I decided to add more 
 cleanups.

 Because nothing new will go to 'master' past -rc1 by default, unless
 you are working on fixing or finding 1.8.3 regressions, this is a
 good time to polish things that are meant for the next cycle.

I know, I've been polishing a bunch of patches for the next cycle for
a long time.

 Folks interested in working remote-hg, please try it out, so that we
 can have a polished one soon after 1.8.3 ships (I am not saying this
 round is not polished---I haven't even looked at the patches).

 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. I thought I made it clear[1] that we would want
these patches in, to avoid regressions, unless it's desirable that we
end up pushing garbage to a remote repository.

Cheers.

[1] http://article.gmane.org/gmane.comp.version-control.git/224224

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


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

2013-05-13 Thread Felipe Contreras
On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano gits...@pobox.com wrote:

 Folks interested in working remote-hg, please try it out, so that we
 can have a polished one soon after 1.8.3 ships (I am not saying this
 round is not polished---I haven't even looked at the patches).

 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.

If we want folks to test something, it should be the patches I
prepared for 'next' which I just sent.

Cheers.

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