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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 16, 2014, 08:08 UTC
Message-ID: <5375c7934ccc6_7e7b772f8d5@nysa.notmuch>
In-Reply-To: <xmqq38gad51x.fsf@gitster.dls.corp.google.com>

Junio C Hamano wrote:

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

Show 14 quoted lines

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

This is a red herring. Ignore the fact that it will never happen (which it won't), the next point remains a FACT, and you conveniently ignore it.

ANSWER THIS:

> > Essentially making the tests optional removes any possibility of
> > blockage (pluse many more arguments).

If the tests are optional, it doesn't matter if such change you are worried about happens or not (it won't).

That's all there is to it. You made a wrong call. The tools *can* move into the core, and you said they couldn't.

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

That is IRRELEVANT to the fact that the tools *could* move into the core. You are using arguments (refuted) to demonstrate that the tools *might be better served* by being unbundled, in order to explain why they *could not* move into the core.

That's a red herring.

> 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 you were wrong.

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

Show 5 quoted lines

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

In other words; if I had done a poorer job of maintaining these tools, they would have had a higher chance of moving into the core?

If that's the case I would gladly stop any maintenance on them. Just say the word.

I worked extremely hard so they could become part of the core, if being part of the core means I have to maintain them less, so be it.

Show 8 quoted lines

> 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",

Where are you saying that? Nowhere, that's where. Therefore every tool you unbundle, you are throwing to the wolves.

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

You told me you wanted them to move to the core, you even moved them to the core.

Then after years of work you change your mind, AGAINST my explicit will and with clear strong arguments AGAINST your apparently newly conceived idea. And idea you didn't explain clearly, and which you didn't give any chance of being refuted.

In other words; an idea which very well COULD BE WRONG, and which very well could impact negatively many Git users.

But you cannot even ponder the notion that you could possibly be wrong.

> 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/,

No, I want to see them in the core, and you said you did too. More importantly the vast majority of our users would want to see them in the core, therefore the discussion of contrib vs. core is pretty much relevant, but you don't care about them, do you?

As I said, I will complain about this publicly _to our users_, which you are disregarding completely with this poorly thought decision and the subsequent ones.

-- 
Felipe Contreras