On Wed, Nov 28, 2012 at 8:01 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html