| Message ID | 20210614043450.1047571-1-felipe.contreras@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | extra: new concept of extra components | expand |
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. > The measuring stick I'm using to gauge if a component in contrib belongs > in extra is simple: are we already running tests for them with > 'make test'? 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. > And we might move some components from the core which aren't realy part > of the core to extra, like gitk, git-gui, git-p4, and git-svn. I'd also like to see us run the tests for the likes of mw-to-git, diff-highlight and subtree by default, at least under CI or some "extended tests" mode, even though we may not install them by default.
Æ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.
Ævar Arnfjörð Bjarmason wrote: > > 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. > > > The measuring stick I'm using to gauge if a component in contrib belongs > > in extra is simple: are we already running tests for them with > > 'make test'? > > 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. Yeah, but then it would be less clear which components belong in extra. I suppose if `make test` also runs the test-extra target, then the my initial definition of extra is still maintained. > > And we might move some components from the core which aren't realy part > > of the core to extra, like gitk, git-gui, git-p4, and git-svn. > > I'd also like to see us run the tests for the likes of mw-to-git, > diff-highlight and subtree by default, at least under CI or some > "extended tests" mode, even though we may not install them by default. extra components are not installed by default, you would have to do install-extra. Do you think mw-to-git and similar should be installed with install-extra?
Junio C Hamano wrote: > Æ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? 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.
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. The measuring stick I'm using to gauge if a component in contrib belongs in extra is simple: are we already running tests for them with 'make test'? We might want to move more components from contrib to extra once their tests are being run reliably. And we might move some components from the core which aren't realy part of the core to extra, like gitk, git-gui, git-p4, and git-svn. For now only contrib/completion and contrib/workdir are graduated to the new area. Felipe Contreras (2): completion: graduate out of contrib git-new-workdir: graduate out of contrib Makefile | 3 +++ extra/Makefile | 20 +++++++++++++++++++ .../completion/git-completion.bash | 0 .../completion/git-completion.zsh | 0 {contrib => extra}/completion/git-prompt.sh | 0 {contrib => extra}/workdir/.gitattributes | 0 {contrib => extra}/workdir/git-new-workdir | 0 t/t1021-rerere-in-workdir.sh | 6 +++--- t/t3000-ls-files-others.sh | 2 +- t/t9902-completion.sh | 8 ++++---- t/t9903-bash-prompt.sh | 2 +- 11 files changed, 32 insertions(+), 9 deletions(-) create mode 100644 extra/Makefile rename {contrib => extra}/completion/git-completion.bash (100%) rename {contrib => extra}/completion/git-completion.zsh (100%) rename {contrib => extra}/completion/git-prompt.sh (100%) rename {contrib => extra}/workdir/.gitattributes (100%) rename {contrib => extra}/workdir/git-new-workdir (100%)