Re: [PATCH 0/4] remote-hg: more improvements

>>> It is *way* beyond the quality of any other tool in 'contrib/' and even
>>> some tools in the core, like 'git-request-pull' (which has known bugs),
>>> and probably even 'git-pt'.
>>
>> Junio, can you comment on this? I understand this probably doesn't
>> really affect the issue at hand, but it'd help clarify if it's ever
>> possible to move out of contrib/ nowadays.
>
> I was originally led to believe that its code quality was good
> enough, and that was why I merged the bottom three patches of the
> series even down to 'next' in the first place.  But after seeing the
> "Of course" response that led to [*1*], which made me recall many
> patch-review interactions with him, I have started to have doubts.
>
> The code quality of Git that many projects have come to trust their
> code with is much more than just "the code at each moment keeps
> working for the users as long as the original author is around".
> The maintainer of a port to the platform X may lose access to the
> platform after switching jobs, the maintainer of a bridge to the
> foreign system Y may stop needing to talk to the foreign system
> after completing the switch to Git.  Anybody can be hit by a bus,
> get sick, or simply lose interest in his past creations.
>
> By reading "git log contrib/remote-helpers" and comparing it with
> the logs for the rest of the system, you would realize that the
> former would not lead to a quality discussion similar to the one
> that led to [*2*], which was only possible because the change was
> adequately described to allow anybody to understand the original
> issue the change was meant to solve.  The commit that made the
> original change made it easy to ask a critical question: "You are
> improving B but at the same time breaking A.  Can we do better to
> help both A and B?"  And it allowed us to move forward without
> having to rob Peter to pay Paul.
>
> Granted, these contrib/ patches were applied with the understanding
> that contrib/ stuff can be substandard, because having anything is
> often better than having nothing, and you cannot go back in time to
> update the history to make these commits more useful to others who
> will come later.  But I would be lying if I said that I would expect
> that things will suddenly improve and that the codebase will be
> maintained for the long haul in a healthy way the minute we move it
> out of contrib/ to the core.  Especially after seeing [*1*], which
> is just one of the examples that illustrate that there clearly is no
> will to explain the changes to help others who come later to help
> maintaining the code.  "I'll take good care of the codebase", "I've
> spend the time to make it better", "Me, me, me", is not what the
> open source process is about.