Re: shortening the git test suite

Hi Ricardo, Mark, and Ludo, Ricardo Wurmus writes: > What do you think of pushing some package updates only to feature > branches that follow a certain naming convention (e.g. “_update-foo” for > updating the “foo” package), which causes Cuirass to build them and > merge the branch into “master”

Re: shortening the git test suite

Hello, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: [...] >> Currently if test fails, the whole derivation fails, and you can’t >> install your package. If tests were run separately, this would no >> longer hold: you could get your package regardless of whether tests >> fai

Re: shortening the git test suite

Hi Mark, >>> I'm not sure what you mean by "build model", whether you are talking >>> about the daemon interface or something else, but I think the changes >>> could be confined to the Guix user interface. A field could be added to >>> , somewhat similar to 'replacement', but pointing to a pack

Re: shortening the git test suite

Hi Ricardo, Ricardo Wurmus writes: > Mark H Weaver writes: > Also, looking ahead, I think it would be great if we could eventually move to a model where the tests of some packages are split off into separate derivations. Similarly, we could work toward splitting off documen

Re: shortening the git test suite

On Fri, Jul 06, 2018 at 23:05:04 +0200, Ludovic Courtès wrote: > Instead of ‘git-minimal’, we could have ‘git’ without SVN support, and > have a separate ‘git-svn’ package. We can probably arrange for that > ‘git-svn’ package to only provide the relevant libexec/git-core bits > (git-svn is just a

Re: shortening the git test suite

Mark H Weaver writes: >>> Also, looking ahead, I think it would be great if we could eventually >>> move to a model where the tests of some packages are split off into >>> separate derivations. Similarly, we could work toward splitting off >>> documentation generation to separate derivation fo

Re: shortening the git test suite

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> If we feel that very few of our users care about git-svn interop, >> another option would be to add a lighter variant of 'git' that does not >> include SVN support. It would probably be a good idea to have a >> 'gi

Re: shortening the git test suite

Ludovic Courtès ezt írta (időpont: 2018. júl. 6., P, 23:05): > Hello, > > Mark H Weaver skribis: > > > Why do you say that only upstream needs to worry about it? I would > > think that you could say the same thing about almost any test suite, but > > there's always the possibility that our part

Re: shortening the git test suite

Hello, Mark H Weaver skribis: > Why do you say that only upstream needs to worry about it? I would > think that you could say the same thing about almost any test suite, but > there's always the possibility that our particular combination of input > versions, or the unusual aspects of Guix, mig

Re: shortening the git test suite

Hi Ricardo, Ricardo Wurmus writes: > Chris Marusich writes: > >> Ricardo Wurmus writes: >> >>> Hi Guix, >>> >>> git takes a very long time to build, because it has an extensive test >>> suite. Most of the time is spent in running the SVN interoperability >>> tests, though, which are not reall

Re: shortening the git test suite

Ricardo Wurmus ezt írta (időpont: 2018. júl. 5., Cs 11:22): > > Chris Marusich writes: > > > Ricardo Wurmus writes: > > > >> Hi Guix, > >> > >> git takes a very long time to build, because it has an extensive test > >> suite. Most of the time is spent in running the SVN interoperability > >> t

Re: shortening the git test suite

Gábor Boskovits writes: > Mark H Weaver ezt írta (időpont: 2018. júl. 2., H, 6:58): > >> Ricardo Wurmus writes: >> >> > git takes a very long time to build, because it has an extensive test >> > suite. Most of the time is spent in running the SVN interoperability >> > tests, though, which ar

Re: shortening the git test suite

Marius Bakke writes: > When debugging the git build, I usually set #:parallel-tests? #t. So > far I haven't come across a failure related to that. I wonder if > is still relevant. That’s a good question. I don’t know. -- Ricardo

Re: shortening the git test suite

Chris Marusich writes: > Ricardo Wurmus writes: > >> Hi Guix, >> >> git takes a very long time to build, because it has an extensive test >> suite. Most of the time is spent in running the SVN interoperability >> tests, though, which are not really all that interesting for most uses >> of git

Re: shortening the git test suite

Ricardo Wurmus writes: > Hi Guix, > > git takes a very long time to build, because it has an extensive test > suite. Most of the time is spent in running the SVN interoperability > tests, though, which are not really all that interesting for most uses > of git. > > The Makefile says this: > >

Re: shortening the git test suite

Mark H Weaver ezt írta (időpont: 2018. júl. 2., H, 6:58): > Ricardo Wurmus writes: > > > git takes a very long time to build, because it has an extensive test > > suite. Most of the time is spent in running the SVN interoperability > > tests, though, which are not really all that interesting fo

Re: shortening the git test suite

Ricardo Wurmus writes: > git takes a very long time to build, because it has an extensive test > suite. Most of the time is spent in running the SVN interoperability > tests, though, which are not really all that interesting for most uses > of git. > > The Makefile says this: > > # Define NO_S

Re: shortening the git test suite

Ricardo Wurmus writes: > Hi Guix, > > git takes a very long time to build, because it has an extensive test > suite. Most of the time is spent in running the SVN interoperability > tests, though, which are not really all that interesting for most uses > of git. > > The Makefile says this: > >

Re: shortening the git test suite

Ricardo Wurmus ezt írta (időpont: 2018. júl. 1., V, 1:20): > Hi Guix, > > git takes a very long time to build, because it has an extensive test > suite. Most of the time is spent in running the SVN interoperability > tests, though, which are not really all that interesting for most uses > of git

shortening the git test suite

Hi Guix, git takes a very long time to build, because it has an extensive test suite. Most of the time is spent in running the SVN interoperability tests, though, which are not really all that interesting for most uses of git. The Makefile says this: # Define NO_SVN_TESTS if you want to skip