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
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