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

[Junio C Hamano <gitster@pobox.com>]

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

> Philippe Vaucher wrote:
>> >> I have had patches and contributions rejected in the past, sometimes
>> >> rudely. Same has happened to many others, if you contribute long
>> >> enough, it is pretty much guaranteed that it will happen to you.
>> >> Maintainer is wrong, or you are wrong, or someone is just having a bad
>> >> day.
>> >
>> > This is not about a couple of patches I worked in a weekend being
>> > rejected. This is about the work I've been doing since the past two
>> > years almost like a full-time job dropped to the floor with no
>> > explanation at all. I started with the expectation that they were going
>> > to move to the core, because Junio said so, then he changed his mind and
>> > didn't want to explain his reasoning.
>> >
>> > It's not just a bad day.
>> 
>> Here are two posts where Junio and Michael Haggerty explain the
>> reasoning to you:
>> 
>> - http://article.gmane.org/gmane.comp.version-control.git/248727
>> - http://article.gmane.org/gmane.comp.version-control.git/248693
>> 
>> Basically, in your case it boils down to your social manners.
>
> You are not paying attention at all.
>
> Junio did *not* use my social manners as a reason to block the
> graduation, nor the quality of the code, he used a *TECHNICAL* reason.
>
> Prior to his decision there were no complaints about my "manners" since
> I returned. It was his *TECHNICAL* decision that triggered this.
>
> 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.
>
> You, and other people, are using the behavior I displayed *AFTER* Junio
> made his *TECHNICAL* decision as the cause for his decision not to
> graduate. That's a wrong direction fallacy.

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

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

   Maintaining it as an independent project (aka Unbundling) would
   eliminate that risk, instead of having to handwave and say "that
   risk does not exist".

 - A remote-helper has to depend on both sides.  Keeping it in
   either contrib/ or in core, as opposed to unbundling, may make
   things easier for the remote-helper maintainer, because at least
   it would allow the helper to advance with Git in lock-step (but I
   never heard that you do not prefer unbundling for this reason).

 - In a longer term, a properly maintained remote-helpers should
   work with wide varieties of Git and the remote system versions
   anyway, so unbundling would be logically the more "correct" thing
   to do.

 - Unbundling would make it less easier to use the remote-helpers
   for people who are used to keep up with my tree and pick them up
   from contrib/, but that is a tiny minority these days.  Most
   people use what distros package, and the distros that already
   package contrib/ remote-helpers will switch their upstream to
   unbundled repositories in order not to regress their packages for
   their users.

 - On the other hand, unbundling will make it easier for the the
   end-users (both the ones who are fed distro packaged versions and
   the ones who build from the source _and_ who overcome the "less
   easier because now they have to pull from not just me but from
   the unbundled places" inconvenience) to keep up with the
   leading/bleeding edge, because the remote-helpers do not have to
   freeze at the same time other parts of Git are frozen before the
   release, and users and distros can pick improved remote-helpers
   up and even "mix and match", when they have some other reason
   that prevents them from updating Git itself.

 - Unbundling would also involve the risk of making them obscure,
   and the original reason why we added contrib/ area to host
   "having something is often better than having nothing" tools,
   even if some of them were of lessor quality, was exactly that.
   While building the momentum and the Git community, it was
   necessary to have a nursery.  That reasoning no longer applies
   these days, and we have seen examples of third-party independent
   products that can improve the users' Git life flourishing.

   "We have less need for a nursery" is not a reason to kick bundled
   things out that want to be bundled, but it tells us that we no
   longer have to be afraid of unbundled things dying in obscurity,
   if there are other reasons that tell us unbundling is better.

I may be missing some others, and I would be lying if I did not at
all think of the "net liability" issue Michael brought up, but the
above that does not include anything you labelled as "social
manners" was more or less enough to convince me to say

    ... and I am inclined to be persuaded that the users of
    remote-hg/bzr may better off if they are unbundled from my tree.

in

    http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242

That is not to say that I disagree with Michael and social issues do
not matter.