Felipe Contreras <felipe.contre...@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
- 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
- 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
- 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.
That is not to say that I disagree with Michael and social issues do
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