Re: [PATCH v3 00/10] remote-hg: fixes and cleanups
On Tue, May 14, 2013 at 1:59 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano 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
On Tue, May 14, 2013 at 1:21 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano 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
Felipe Contreras writes: > On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano 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
Junio C Hamano 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
Felipe Contreras writes: > On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano 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
On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano 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
Re: [PATCH v3 00/10] remote-hg: fixes and cleanups
On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano wrote: > Felipe Contreras 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
Felipe Contreras 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. 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. Thanks. > > Felipe Contreras (10): > remote-hg: trivial cleanups > remote-hg: get rid of unused exception checks > remote-hg: enable track-branches in hg-git mode > remote-hg: add new get_config_bool() helper > remote-hg: fix new branch creation > remote-hg: disable forced push by default > remote-hg: don't push fake 'master' bookmark > remote-hg: update bookmarks when pulling > remote-hg: test: be a little more quiet > remote-hg: trivial reorganization > > contrib/remote-helpers/git-remote-hg | 47 > > contrib/remote-helpers/test-hg-hg-git.sh | 3 +- > contrib/remote-helpers/test-hg.sh| 4 +-- > 3 files changed, 26 insertions(+), 28 deletions(-) -- 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
