Re: [PATCH v3 0/9] remote-helpers: fixes and cleanups
Felipe Contreras wrote: > Updated the commit messages, so we say Bazaar instead of Mercurial, and stuff. > > Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. Looks reasonable. Thanks. -- 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 0/9] remote-helpers: fixes and cleanups
Junio C Hamano writes: > Junio C Hamano writes: > >> Felipe Contreras writes: >> >>> Updated the commit messages, so we say Bazaar instead of Mercurial, and >>> stuff. >>> >>> Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. >> >> Thanks. Will queue on 'pu' without looking. > > Actually, I was going to merge fc/remote-hg and fc/remote-bzr down > to master anyway, so I'll just apply them directly on 'master'. > > By the way, I personally do not think the quality of the changes to > remote-bzr matters all that much ... Just in case anybody get the wrong impression from the above quoted lines... The "without looking" was a plan to "keep them on 'pu' for later inspection so that I do not have to go back to list archive when I declare patch review bankruptcy after the final 1.8.3 release". I did read these patches I applied to 'master' and they all looked sensible. -- 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 0/9] remote-helpers: fixes and cleanups
On Fri, Apr 26, 2013 at 5:23 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Felipe Contreras writes: >> >>> Updated the commit messages, so we say Bazaar instead of Mercurial, and >>> stuff. >>> >>> Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. >> >> Thanks. Will queue on 'pu' without looking. > > Actually, I was going to merge fc/remote-hg and fc/remote-bzr down > to master anyway, so I'll just apply them directly on 'master'. > > By the way, I personally do not think the quality of the changes to > remote-bzr matters all that much at this point in its history. It's > not like millions of people use it heavily from the v1.8.2 release. > A huge patch series from its original author and nobody else, either > reviewed or unreviwed, would not hurt them more than the one in the > v1.8.2 version anyway. And it is also not like bzr-to-git population > will grow significantly in the future to require us to pile a lot of > features on remote-bzr that makes the maintenance burden of it > becomes an issue. > > Am I underestimating the pain of potentially breaking existing > remote-bzr userbase? No, I think it's reasonable. 1.8.2 was better because 1.8.1 didn't ave any support whatsoever, and 1.8.3 will be better, because 1.8.2 was barely usable for any real-world project. Will there be any regressions? I doubt it, and if there are, it's unlikely that they would be found in the review process, in 'pu', or in 'next', specially since very few people actually use remote-bzr, in part because it wasn't very useful, and in part because few people use bzr in the first place. Of course, I would prefer if people reviewed the patches for the massive changes, the _important_ patches, and I would gladly explain the reasoning and update the commit messages if needed. But nobody is volunteering to review that. The only exception was for a few irrelevant patches that could be easily dropped. remote-hg is a different story, and so I'm being more careful with the changes there, and I actually think the current patches are more than enough for 1.8.3, they should be tested in an actual release, and the rest would have to wait. For the rest, I'm still juggling in which order I should send them, and I want to send first the ones that should maximize the benefits for the users, with minimum possibility of breakage, but even then I wouldn't be confident with those landing in 1.8.3, so 1.8.4 it is. 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 0/9] remote-helpers: fixes and cleanups
Junio C Hamano writes: > Felipe Contreras writes: > >> Updated the commit messages, so we say Bazaar instead of Mercurial, and >> stuff. >> >> Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. > > Thanks. Will queue on 'pu' without looking. Actually, I was going to merge fc/remote-hg and fc/remote-bzr down to master anyway, so I'll just apply them directly on 'master'. By the way, I personally do not think the quality of the changes to remote-bzr matters all that much at this point in its history. It's not like millions of people use it heavily from the v1.8.2 release. A huge patch series from its original author and nobody else, either reviewed or unreviwed, would not hurt them more than the one in the v1.8.2 version anyway. And it is also not like bzr-to-git population will grow significantly in the future to require us to pile a lot of features on remote-bzr that makes the maintenance burden of it becomes an issue. Am I underestimating the pain of potentially breaking existing remote-bzr userbase? -- 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 0/9] remote-helpers: fixes and cleanups
Felipe Contreras writes: > Updated the commit messages, so we say Bazaar instead of Mercurial, and stuff. > > Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. Thanks. Will queue on 'pu' without looking. -- 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