From: "Gábor Boskovits" <boskovits@gmail.com>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: shortening the git test suite
Date: Fri, 6 Jul 2018 11:46:53 +0200 [thread overview]
Message-ID: <CAE4v=pgOHjtGJEPBaCxyjG7tGrccmdX8Liyd8-zS4h+HQi4wSA@mail.gmail.com> (raw)
In-Reply-To: <87fu0y11ir.fsf@elephly.net>
[-- Attachment #1: Type: text/plain, Size: 3310 bytes --]
Ricardo Wurmus <rekado@elephly.net> ezt írta (időpont: 2018. júl. 5., Cs
11:22):
>
> Chris Marusich <cmmarusich@gmail.com> writes:
>
> > Ricardo Wurmus <rekado@elephly.net> 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:
> >>
> >> # Define NO_SVN_TESTS if you want to skip time-consuming SVN
> interoperability
> >> # tests. These tests take up a significant amount of the total test
> time
> >> # but are not needed unless you plan to talk to SVN repos.
> >>
> >> What do you think about disabling the SVN tests in the git package?
> >
> > This sounds similar to the discussion we had earlier about treating
> > tests as a special case:
> >
> > https://lists.gnu.org/archive/html/guix-devel/2018-04/msg00071.html
> >
> > I felt that the conclusion of that thread was basically that if someone
> > is concerned about the build time, then they ought to be able to use
> > substitutes to speed things up, and we should continue to run as many
> > tests as possible in order to discover problems sooner.
>
> What I’m worried about is availability of substitutes. When we keep
> changing packages on the “master” branch that have very expensive test
> suites then we accept that people won’t have substitutes for a while.
> The duration of that while depends on how quickly the build of this
> package is started by our continuous integration software, and how long
> it takes to complete the build.
>
> Granted, disabling parts of the test suite in an attempt to shorten it
> is really a technical fix to a social problem.
>
> Personally, I think that the SVN tests are non-essential (after all,
> we’re building Git here, we keep running the individual test suites of
> Git and Subversion, and git-svn interop seems like a thing that only
> upstream need to worry about), which is why I made this proposal. But
> as it seems that the people who responded to this message rather lean in
> the other direction, let’s try to address the social problem instead:
>
> How can we change our workflow to make sure that for packages with long
> build/test times we can provide substitutes more quickly? Currently,
> our policy for pushing changes to “staging” and “core-updates” is based
> on package counts. I’m not suggesting that changes to Git be pushed to
> “staging”.
>
> 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” (semi-)automatically when the build is
> successful?
>
>
>
> I think this is a very reasonable approach. If this will be the way to go,
then we also need a way to select packages to which this applies, and find
a way to communicate this.
> (Obviously, any kind of automation has to be thought out carefully, but
> I’m sure we would be able to find a solution.)
>
> What do you think?
>
> --
> Ricardo
>
>
>
[-- Attachment #2: Type: text/html, Size: 4304 bytes --]
next prev parent reply other threads:[~2018-07-06 9:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-30 19:34 shortening the git test suite Ricardo Wurmus
2018-06-30 23:52 ` Gábor Boskovits
2018-07-01 13:54 ` Marius Bakke
2018-07-05 9:28 ` Ricardo Wurmus
2018-07-02 4:56 ` Mark H Weaver
2018-07-02 8:39 ` Gábor Boskovits
2018-07-05 9:28 ` Ricardo Wurmus
2018-07-05 8:44 ` Chris Marusich
2018-07-05 9:21 ` Ricardo Wurmus
2018-07-06 9:46 ` Gábor Boskovits [this message]
2018-07-06 18:19 ` Mark H Weaver
2018-07-06 21:05 ` Ludovic Courtès
2018-07-07 8:07 ` Gábor Boskovits
2018-07-07 16:44 ` Mark H Weaver
2018-07-07 21:37 ` Ricardo Wurmus
2018-07-08 22:41 ` Mark H Weaver
2018-07-09 7:47 ` Ricardo Wurmus
2018-07-11 12:46 ` Ludovic Courtès
2018-07-12 9:27 ` Chris Marusich
2018-07-08 1:29 ` Mike Gerwitz
2018-07-06 21:09 ` Automatic branch merging upon build completion Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE4v=pgOHjtGJEPBaCxyjG7tGrccmdX8Liyd8-zS4h+HQi4wSA@mail.gmail.com' \
--to=boskovits@gmail.com \
--cc=guix-devel@gnu.org \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).