Felipe Contreras [off-list ref] writes:
quoted
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.
On Wed, Nov 28, 2012 at 8:01 AM, Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
quoted
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.
quoted
... 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.
quoted
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