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

Felipe Contreras [off-list ref] writes:

Philippe Vaucher wrote:

quoted

quoted

quoted

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.