Re: [Discussion] The architecture of Scalar (and others) within Git

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 5, 2021, 04:20 UTC
Message-ID: <xmqq7ddnz115.fsf@gitster.g>
In-Reply-To: <nycvar.QRO.7.76.6.2111031833580.56@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 10 quoted lines

> Even so, I targeted `contrib/` with my patch series because
> `contrib/README` says:
>
>     The intention is to keep interesting tools around git here, maybe
>     even experimental ones, to give users an easier access to them,
>     and to give tools wider exposure, so that they can be improved
>     faster.
>
> Does this README's intent still apply, or has the purpose of contrib/
> changed?

The intent may still be the same, but my suspicion is that the world has changed sufficiently to make contrib/ that is offered with such an intent no longer is useful. In other words, "contrib/" as a nursery may have been our dream, but the dream did not materialize and may have outlived its usefulness.

Show 16 quoted lines

> Would you like me to organize the code and patches such that they more
> clearly fall under your maintenance once the patches are merged? If that
> is your preference, I will gladly put in the work.
>
> When I submitted the Scalar patches, I did not want to burden you with
> maintaining it, I expected to maintain Scalar going forward, but maybe
> that is not your preference? I assumed it to be my maintenance burden, we
> aim to support backward compatibility for existing Scalar users, after
> all. Absolutely everything else, however, is up for discussion, subject to
> the full scrutiny of the community and to the same standards of a
> submission to the core of the project.
>
> And I see your point about backward compatibility: The Git project has
> plenty of experience with maintaining backward compatibility and _still_
> improving on initial designs. I therefore can easily give up my hard “this
> command-line interface must not be changed” stance.

It depends on how you define "maintenance".

Many parts of the system (e.g. difftool, commit-graph, pack bitmaps, multi-pack index, sparse-index, po, and gitweb) may "fall under my maintenance", but you can see that I am not heavily involved in any of these areas, other than serving mostly as a traffic cop. If a patch that touches some area comes, I may trust input from folks who are more deeply involved in the area (e.g. input from Taylor better than from other folks, including mine, for a patch that touches midx) when deciding if the patch needs revising or if it is ready.

I would expect that is more or less how things would work for anything that is in my tree. And I do not think it would be any different for Scalar. I would expect that any bugfixes or new features would be redirected to you folks. Ehh, not that you would need redirecting---I'd expect you'd jump on them even _before_ I would react ;-)