Re: [PATCH v3 0/7] New remote-bzr remote helper
Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. Yes, that's what I have planned for the next patches, as I already did for remote-hg, but the changes in remote-bzr were a bit bigger. OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master' soonish, but I take the above to mean that fc/remote-hg is ready while it is better to wait for updates to fc/remote-bzr before merging it. 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/7] New remote-bzr remote helper
On Wed, Nov 28, 2012 at 12:32 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. Yes, that's what I have planned for the next patches, as I already did for remote-hg, but the changes in remote-bzr were a bit bigger. OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master' soonish, but I take the above to mean that fc/remote-hg is ready while it is better to wait for updates to fc/remote-bzr before merging it. I was waiting on both to be merged, let me see what I have pending and would be nice to have before the merge. -- 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/7] New remote-bzr remote helper
On Wed, Nov 28, 2012 at 12:32 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. Yes, that's what I have planned for the next patches, as I already did for remote-hg, but the changes in remote-bzr were a bit bigger. OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master' soonish, but I take the above to mean that fc/remote-hg is ready while it is better to wait for updates to fc/remote-bzr before merging it. Please update remote-bzr to series version 3. The rest of the patches will be on top of that version. -- 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/7] New remote-bzr remote helper
Felipe Contreras felipe.contre...@gmail.com writes: OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master' soonish, but I take the above to mean that fc/remote-hg is ready while it is better to wait for updates to fc/remote-bzr before merging it. I was waiting on both to be merged, let me see what I have pending and would be nice to have before the merge. OK. At this point, both have been cooking for a week or more in 'next', there is no existing users, they are on the fringe so breakages in them won't negatively affect anybody anyway. So it doesn't matter much if they are merged to 'master' and then fixed up with follow up patches after that, or fixed up with follow up patches while they are in 'next', as they won't be rewound and restarted from scratch. -- 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/7] New remote-bzr remote helper
On Wed, Nov 28, 2012 at 2:56 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master' soonish, but I take the above to mean that fc/remote-hg is ready while it is better to wait for updates to fc/remote-bzr before merging it. I was waiting on both to be merged, let me see what I have pending and would be nice to have before the merge. OK. At this point, both have been cooking for a week or more in 'next', there is no existing users, they are on the fringe so breakages in them won't negatively affect anybody anyway. So it doesn't matter much if they are merged to 'master' and then fixed up with follow up patches after that, or fixed up with follow up patches while they are in 'next', as they won't be rewound and restarted from scratch. The fixes are affecting some people, that's why I did them. Some were reported here in the mailing list, and some in my github's clone: https://github.com/felipec/git/issues?page=1state=closed I tried to minimize the changes in the last patch series I sent, I have more, but those truly can wait. 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/7] New remote-bzr remote helper
Felipe Contreras felipe.contre...@gmail.com writes: At this point, both have been cooking for a week or more in 'next', there is no existing users, they are on the fringe so breakages in them won't negatively affect anybody anyway. So it doesn't matter much if they are merged to 'master' and then fixed up with follow up patches after that, or fixed up with follow up patches while they are in 'next', as they won't be rewound and restarted from scratch. The fixes are affecting some people, that's why I did them. Some were reported here in the mailing list, and some in my github's clone: https://github.com/felipec/git/issues?page=1state=closed Are you talking about -hg or -bzr or both? In any case, I am mostly concerned about *my* next release, whose rc0 will be tagged sometime this week or the next week. People who have been bitten by bugs from *your* tree or versions in 'next' do not count. When I said no existing users, I was talking about the end users who need rock solid stable releases because tagged versions are the only ones they use. If the code of these topics is still in flux and needs constant fixes, probably it is a better idea to cook them longer in 'next', skipping the upcoming 1.8.1 release. If we are going to go that route, we can drop the v2 fc/remote-bzr and queue v3 when we rewind the tip of 'next' after 1.8.1 release (by that time you may have v4 of the series, but then we can skip v3). Is that more preferrable than rushing these topics forward before they are ready for general audience? -- 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/7] New remote-bzr remote helper
On Wed, Nov 28, 2012 at 3:37 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: At this point, both have been cooking for a week or more in 'next', there is no existing users, they are on the fringe so breakages in them won't negatively affect anybody anyway. So it doesn't matter much if they are merged to 'master' and then fixed up with follow up patches after that, or fixed up with follow up patches while they are in 'next', as they won't be rewound and restarted from scratch. The fixes are affecting some people, that's why I did them. Some were reported here in the mailing list, and some in my github's clone: https://github.com/felipec/git/issues?page=1state=closed Are you talking about -hg or -bzr or both? In any case, I am mostly concerned about *my* next release, whose rc0 will be tagged sometime this week or the next week. People who have been bitten by bugs from *your* tree or versions in 'next' do not count. When I said no existing users, I was talking about the end users who need rock solid stable releases because tagged versions are the only ones they use. If users you call fringe have noticed these compatibility issues, chances are your existing users are going to catch them as well. Those issues were fixed right away, but I didn't sent them because I wanted things to settle. I didn't see that v2 landed in next until now. If the code of these topics is still in flux and needs constant fixes, probably it is a better idea to cook them longer in 'next', skipping the upcoming 1.8.1 release. If we are going to go that route, we can drop the v2 fc/remote-bzr and queue v3 when we rewind the tip of 'next' after 1.8.1 release (by that time you may have v4 of the series, but then we can skip v3). Is that more preferrable than rushing these topics forward before they are ready for general audience? They are not in constant flux, that's why I haven't send any new re-rolls since v3, which was on November 11. I've been using v3 for baseline since them, and the rest of the patches I've sent on top of that. In fact, these particular fixes were already sent on November 13 (on top of v3): http://article.gmane.org/gmane.comp.version-control.git/209558 On November 10 Jeff threatened to to merge v2 to next on the What's cooking, and I told him I was about to sent a re-roll, he acknowledged the same day, and I sent the next one. Since v3 remote-bzr hasn't been on flux. Now, what you do is up to you, but I think v3 plus the two patches I sent on nov 13, and just resent today should be safe. That being said, I don't use remote-bzr really, and I don't know how many people have been using it, so I have no idea how ready it really is. If I were you I would just merge v3 to next, or revert v2 and merge v3, and then apply the two patches on top. Or if you want, revert v2, wait for 1.8.1, and then merge v3. Either way it's doubtful there will be a v4 (if there are next patches they will be on top of v3, as they have been for quite some time now), so it's not clear what existing users will gain by that. I'm confident about remote-hg though. 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/7] New remote-bzr remote helper
Felipe Contreras felipe.contre...@gmail.com writes: People who have been bitten by bugs from *your* tree or versions in 'next' do not count. When I said no existing users, I was talking about the end users who need rock solid stable releases because tagged versions are the only ones they use. If users you call fringe have noticed these compatibility issues, chances are your existing users are going to catch them as well. There seems to be some misunderstanding. I have never called them fringe; they are early adopters who are expected to be capable of git pull to pick up fixes from between-releases trees (or git am patches from the list) and rebuild their Git. We cannot expect that from the real end users (who do not exist yet, luckily) who only follow tagged releases. Hitting them with bugs we need to fix after the release is not letting them notice and report, but just irresponsibly hurting the end users. Letting them notice and report is what early adopter population who run 'next' are for. Quality expectations between these two populations are quite different. ... That being said, I don't use remote-bzr really, and I don't know how many people have been using it, so I have no idea how ready it really is. ... ... Either way it's doubtful there will be a v4 OK; thanks for clarification. If you are not using it actively, it probably is a better idea to proceed with more caution, as low rate of update necessity does not directly relate to maturity of the tool. I'd feel better to cook it longer in 'next' to recruit early adopters so that we can hear positive feedbacks (or negative ones that can result in fixes to whatever is still uncovered, if any). I hate reverting anything from 'next', but for the above to work smoothly, it seems to me that reverting the merge of v2 and queuing v3 plus remainder sounds like the best course. I'm confident about remote-hg though. Meaning unlike remote-bzr, at least you are using it more actively (or you know people who are), right? I've queued the two patches (out of four) from you today, so we can merge it to 'master' before 1.8.1-rc0. 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/7] New remote-bzr remote helper
On Wed, Nov 28, 2012 at 8:01 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: People who have been bitten by bugs from *your* tree or versions in 'next' do not count. When I said no existing users, I was talking about the end users who need rock solid stable releases because tagged versions are the only ones they use. If users you call fringe have noticed these compatibility issues, chances are your existing users are going to catch them as well. There seems to be some misunderstanding. I have never called them fringe; they are early adopters who are expected to be capable of git pull to pick up fixes from between-releases trees (or git am patches from the list) and rebuild their Git. We cannot expect that from the real end users (who do not exist yet, luckily) who only follow tagged releases. Hitting them with bugs we need to fix after the release is not letting them notice and report, but just irresponsibly hurting the end users. Letting them notice and report is what early adopter population who run 'next' are for. Quality expectations between these two populations are quite different. Perhaps, but I still don't agree with the statement that the people bitten by those bugs don't count. If those bugs are not fixed, they will bite the normal population. ... That being said, I don't use remote-bzr really, and I don't know how many people have been using it, so I have no idea how ready it really is. ... ... Either way it's doubtful there will be a v4 OK; thanks for clarification. If you are not using it actively, it probably is a better idea to proceed with more caution, as low rate of update necessity does not directly relate to maturity of the tool. I'd feel better to cook it longer in 'next' to recruit early adopters so that we can hear positive feedbacks (or negative ones that can result in fixes to whatever is still uncovered, if any). Perhaps, on the other hand it's not like any of their existing functionality will break. Chances are they will be happy to have anything that somehow works, even if it has bugs. In fact, the current remote-bzr, even if it hasn't received so much testing, is probably already more stable than other tools: As an example there is this bug: http://bugs.launchpad.net/bzr/+bug/541626 Which has been affecting users of 'bzr fast-export' for years (most of bzr-git bridges use this tool), and nobody does anything about it, even though the developers thought the problem was in bzr itself (and that it was actually fixed, despite the reports to the contrary). I fixed the problem and added a reliable test case to reproduce the issue in bzr's test suite itself, only to receive no feedback. I think there are very few users of bazaar, and if you read the source code you would be happy that's the case, so I'm not sure letting it cook in 'next' is going to achieve much, most of them are going to see it only when it hits master. Most likely the few bazaar users are accustomed to different quality standards, and this tool doesn't even have known bugs. I'm confident about remote-hg though. Meaning unlike remote-bzr, at least you are using it more actively (or you know people who are), right? I've queued the two patches (out of four) from you today, so we can merge it to 'master' before 1.8.1-rc0. I'm not using it actively, it seems some people are, but that's not why I'm confident; it's because of the extensive automatic testing that compares the output with hg-git (which is widely used). 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/7] New remote-bzr remote helper
On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. Yes, that's what I have planned for the next patches, as I already did for remote-hg, but the changes in remote-bzr were a bit bigger. -- 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/7] New remote-bzr remote helper
Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. 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
