Subject: Re: [PATCH v2 01/17] contrib: remove outdated README

From: Junio C Hamano <[email-masked]>
Date: Thu, 15 May 2014 15:56:42 -0700

Felipe Contreras <[email-masked]> writes:

> Junio C Hamano wrote:
>> Felipe Contreras <[email-masked]> writes:
>> > Junio never explained his *TECHNICAL* reason, and Michael Haggerty
>> > simply said "there are good technical arguments for and against
>> > moving git-remote-hg out of contrib", that was all his explanation for
>> > the *TECHNICAL* reason.
>
>> I am not interested in distinction between technical and social that
>> much.  The points that were raised in the thread started by John
>> Keeping, and some of the points that came to my mind while on that
>> thread, even though I may not have mentioned in *that* thread, that
>> affected the way *I* thought about the issue are these (not
>> exhaustive):
>
> Let's be clear; the discussion in that thread was contrib vs. core. Most
> of the points you mention below are not related to that.
>
> == contrib vs. core ==
>
> This is the only point relevant to contrib vs. core:
> 
> >  - We may be painted in a hard place if remote-hg or remote-bzr take
> >    us to a position where the Git as a whole is blocked while it is
> >    incompatible with the other side.
>
> It will never happen. I already argued against it[1], multiple times.
> Essentially making the tests optional removes any possibility of
> blockage (pluse many more arguments).

I already said that your "It will never happen" is a handwaving, and
I already saw you "argued against it".  There is no point repeating
that exchange.  We both know, and bystanders with popcorns in their
hands also know, that we have different opinions.

You may have been interested in contrib/core in the thread, but that
does not prevent others from considering other aspects of the issue
and different and possibly better solutions, which was to unbundle.

I was very confident back in that thread that the remote Hg bridge
would not merely survive but would serve its users well as a
standalone project, and the level of confidence was actually a lot
higher than for a hypothetical case where other "already in-core"
bridges like git-svn/p4 are somehow forced to become standalone,
simply because of the difference in the depths of involvement of
respective area maintainers.  Without meaning any disrespect to Eric
or Pete, I think my prodding them (by forwarding issues and proposed
patches by others to them when I see them on the list) has been
helping the area maintainers who have other time and attention
obligations to help us, by drawing their attention and making their
workload smaller (they can only Ack and have me apply, instead of
maintaining a separate tree).  There is a greater risk for these
bridges to become unmaintained if we do not have them in my tree,
and that would only hurt our users.  In the ideal world, it may be
better if it weren't that way, but at the same time, new issues that
changing time brings to them seem to be handled more or less OK, so
we have to be content with the status quo.

But I did not see that particular risk at all for the remote Hg
bridge.  You have been very interested in maintaining it, and I
don't think I ever had to prod you to respond to an issue raised on
the list.  It is an apples-and-oranges comparison to bring up
git-svn/p4.

Besides, I want to see the "git-core has the best thing among
competing implementations for a specific niche subtask" perception
changed in the longer term so that it becomes natural for users to
say something like "For this particular task, there is no support in
what comes with core (or there is a tool that comes with core to
address similar issues but in a way different from what you want),
and the go-to tool these days for that kind of task is to use this
third-party plugin", because it is simply unrealistic to expect my
tree to forever be the be-all destination for everything.

Things like "git imerge" are helping us to go in that direction.  I
was hoping that the remote Hg bridge to be capable of becoming the
first demonstration to graduate out of contrib/ that shows the users
that is the case, not with just talk but with a specific example.

Anyway, the above is only within the discussion theme of John
Keeping's thread [*1*].  You seem to be adamant that you do not
consider other people's opinions that came in later threads you
started [*2*], and I do not think that is a sensible way to discuss
things.

After seeing these discussions, it tells me that the code is not fit
for the core (also [*3*]), and I think there no longer is any reason
for us to still talk only about contrib vs core.  As you already
said, you do not want to see them in contrib/, and as you already
saw, everybody other than you do not want to see them in core and
some of them do not want to even see them in contrib/ for that
matter.

I do not see that there is any direction other than out.

[Reference]

*1* http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167
*2* http://thread.gmane.org/gmane.comp.version-control.git/248705
*3* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248727