Re: [PATCH v3 0/7] New remote-bzr remote helper

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 28, 2012, 07:01 UTC
Message-ID: <7vhaoai533.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAMP44s23FfxQG6v+dfRGWHzxpWZ5BSGpAm=8Q8Bmj04tDwmwKw@mail.gmail.com>

Felipe Contreras <felipe.contreras@gmail.com> writes:

Show 7 quoted lines

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