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

Ævar Arnfjörð Bjarmason [off-list ref] writes:

On Sun, Jun 13 2021, Felipe Contreras wrote:

quoted

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.

Junio C Hamano wrote:

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

On Sun, Jun 13 2021, Felipe Contreras wrote:

quoted

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?

Everyone.

  1. People who download the source code and want to install git in a
     similar way to how distributions do it
  2. Developers who have no idea what's good in contrib/
  3. Distribution packagers who want to know what's good enough to be
     distributed, and don't want to manually copy files (i.e. all
     distribution packagers)

Distros would rather see what they use unmoved, and would not care
where those that they do not use move to, I would imagine.

That is not true.

Distributions do not want to decide where to place
`contrib/completion/git-prompt.sh`, they want the git project to decide.

Obviously it has to be under '/usr/share/', preferably
'/usr/share/$project' (i.e. not /usr/share/git-core), but other than
that they do not care.

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?

Sure, that would help, but they still would want an install-contrib target.


A distribution packager that is maintaining 20 packages (or more)
doesn't want to keep track where every single file of her every
single package goes. She just wants to do `make install` and be done
with it. Any package that requires to manually copy some files to the
destination is simply a hassle to maintain.

-- 
Felipe Contreras