unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: Treating tests as special case
Date: Fri, 6 Apr 2018 08:06:01 +0200	[thread overview]
Message-ID: <20180406060601.GA4343@thebird.nl> (raw)
In-Reply-To: <87tvsp4cxh.fsf@netris.org>

On Thu, Apr 05, 2018 at 04:26:50PM -0400, Mark H Weaver wrote:
> Tests on different hardware/kernel/kernel-config/file-system
> combinations are quite useful for those who care about reliability of
> their systems.  I, for one, would like to keep running test suites on my
> own systems.

Sure. And it is a great example why to test scenarios. But why force
it down everyone's throat? I don't want to test Scipy or ldc over and
over again. Note that I can work around it, but we are forcing our
methods here on others. If I do not like it, others won't. I am just
looking at running test billion times uselessly around the planet.
Does that not matter? We need to be green.

Ludo is correct that provisioning binary substitutes is one solution.
But not cheap.  Can we guarantee keeping all substitutes? At least the
ones with long running tests ;). I don't know how we remove
substitutes now, but it would make sense to me to base that on
download metrics and size. How about ranking downloads in the last 3
months times the time to build? And trim from the end. That may be
interesting.

Even so, with my idea of test substitutes you don't have to opt out of
testing.  And you would still have found that bug. Those who care can
test all they please. 

Anyway, that is enough. I made my point and I am certain that we will
change our ways at some point. The laborious solution is to remove all
meaningless tests. And I am sure over 90% are pretty damn meaningless
for our purposes. Like the glut in binaries, we will trim it down over
time.

One suggestion: let's also look at tests that are *not* about
integration or hardware/kernel configuration and allow for running them
optionally. Stupidly running all tests that people come up with is not
a great idea. We just run what authors decide that should be run.

Pj.

  reply	other threads:[~2018-04-06  6:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05  5:24 Treating tests as special case Pjotr Prins
2018-04-05  6:05 ` Gábor Boskovits
2018-04-05  8:39   ` Pjotr Prins
2018-04-05  8:58     ` Hartmut Goebel
2018-04-05  6:21 ` Björn Höfling
2018-04-05  8:43   ` Pjotr Prins
2018-04-06  8:58     ` Chris Marusich
2018-04-06 18:36       ` David Pirotte
2018-04-05 10:14   ` Ricardo Wurmus
2018-04-05 12:19     ` Björn Höfling
2018-04-05 14:10       ` Ricardo Wurmus
2018-04-05 10:26 ` Ricardo Wurmus
2018-04-05 14:14   ` Ludovic Courtès
2018-04-05 14:59     ` Pjotr Prins
2018-04-05 15:17       ` Ricardo Wurmus
2018-04-05 15:24       ` Ludovic Courtès
2018-04-05 16:41         ` Pjotr Prins
2018-04-05 18:35           ` Pjotr Prins
2018-04-06  7:57           ` Retaining substitutes Ludovic Courtès
2018-04-05 20:26 ` Treating tests as special case Mark H Weaver
2018-04-06  6:06   ` Pjotr Prins [this message]
2018-04-06  8:27     ` Ricardo Wurmus

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=20180406060601.GA4343@thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=guix-devel@gnu.org \
    --cc=mhw@netris.org \
    /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).