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

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:

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

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

> 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