Re: [PATCH 0/2] extra: new concept of extra components

From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
	git@vger.kernel.org, Luke Shumaker <lukeshu@lukeshu.com>
Subject: Re: [PATCH 0/2] extra: new concept of extra components
Date: Wed, 16 Jun 2021 09:40:38 +0900	[thread overview]
Message-ID: <xmqqim2evdyx.fsf@gitster.g> (raw)
In-Reply-To: <87tum0zfub.fsf@evledraar.gmail.com> (=?utf-8?B?IsOGdmFyIEFy?= =?utf-8?B?bmZqw7Zyw7A=?= Bjarmason"'s message of "Mon, 14 Jun 2021 16:18:30 +0200")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Sun, Jun 13 2021, Felipe Contreras wrote:
>
>> This patch series introduces the concept of extra components. These are
>> components which are not yet part of the core but are good enough for
>> distributions to ship, and in fact, they already do.
>
> I like this direction.

I do not mind change, but it is fuzzy to me what direction you are
in favor of.  Is the gist of the idea to split what is in contrib/
into two bins, ones that are closer to "official" and others?  If
so, I see sort-of merit in such a distinction, but whom is this
trying to help?

Distros would rather see what they use unmoved, and would not care
where those that they do not use move to, I would imagine.  So I
suspect that it would help them more if we kept the ones that are
closer to "official" in contrib/ and moved the rest to a new
hierarchy?

> I have a CI failure in one series of mine that seems to be a lack of
> updating to CMake in contrib/buildsystems, perhaps we should be adding
> that to extra/ too, i.e. extending this to the "make test" run by CI?
>
> Not something that should hinder or necessarily be included in this
> series, just a note about a related component.

I think that is more or less independent.  contrib/buildsystems (or
anything else that currently do not have test coverage) can be
taught to CI before or after sifting what is contrib/ into two
classes.  If the usable and testable ones stay in contrib/ instead
of getting moved, such a task can go in parallel.  We declare the
split, interested parties work on adding the part they are interested
in to the test framework, and the parts that are not updated to be
tested will be dropped to a "less than contrib" status.

So, in short, I like the general idea of sifting the contrib/
material into two bins, but I may not agree with (1) the execution
of these patches, or (2) the higher level goal of what such a split
wants to achieve (i.e. "whom are we helping?" question).

Thanks.