Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
