From: Carlos O'Donell <carlos@redhat.com>
To: DJ Delorie <dj@redhat.com>
Cc: fweimer@redhat.com, libc-alpha@sourceware.org
Subject: Re: [PATCH] test-in-container: Install locales into the test container
Date: Fri, 12 Jul 2019 04:02:00 -0000 [thread overview]
Message-ID: <104acd37-66be-621b-6eb9-e014fac2e81d@redhat.com> (raw)
In-Reply-To: <xn5zoarcfh.fsf@greed.delorie.com>
On 7/9/19 7:54 PM, DJ Delorie wrote:
> "Carlos O'Donell" <carlos@redhat.com> writes:
>> Where do you draw the line?
>
> Originally I wanted the "make install" to trigger just before the first
> test that actually needed it, but I found it very difficult to do that.
> Eventually more and more tests will run inside the container, and that
> optimization would be useless anyway.
>
> Perhaps we could at least add $(PARALLELMFLAGS) to the "make install" ?
> If it's not already propogated by some other means? Or otherwise
> optimize the install process, to limit the overhead during testing?
My point is that no matter how good you optimize, eventually there will
be enough tests that the time will creep up again.
I want Florian to be productive, and I want a build system that supports
a straight forward edit/build/test workflow.
My question is: How long is too long to wait for the results of testing
when you are doing a edit/build/test/debug cycle?
Should 'make check' be running enough tests to fill X seconds?
--
Cheers,
Carlos.
next prev parent reply other threads:[~2019-07-12 4:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-09 17:32 Florian Weimer
2019-07-09 18:07 ` DJ Delorie
2019-07-09 20:52 ` Florian Weimer
2019-07-09 20:59 ` DJ Delorie
2019-07-09 21:02 ` Florian Weimer
2019-07-09 21:11 ` Partial test suite run builds corrupt test-in-container testroot Carlos O'Donell
2019-07-10 0:36 ` DJ Delorie
2019-07-10 5:50 ` Florian Weimer
2019-07-10 16:34 ` DJ Delorie
2019-07-10 16:35 ` Florian Weimer
2019-07-10 16:38 ` DJ Delorie
2019-07-19 11:52 ` Florian Weimer
2019-07-22 20:45 ` [PATCH] test-container: Install with $(all-subdirs) [BZ #24794] Tulio Magno Quites Machado Filho
2019-07-22 20:56 ` DJ Delorie
2019-07-23 16:29 ` Tulio Magno Quites Machado Filho
2019-07-24 14:48 ` Stefan Liebler
2019-07-24 15:32 ` Tulio Magno Quites Machado Filho
2019-07-24 20:40 ` Carlos O'Donell
2019-07-24 23:50 ` DJ Delorie
2019-07-25 0:03 ` [PATCH] test-container: Install with $(sorted-subdirs) " Tulio Magno Quites Machado Filho
2019-07-25 1:32 ` DJ Delorie
2019-07-25 12:46 ` Szabolcs Nagy
2019-07-25 12:56 ` Carlos O'Donell
2019-07-29 13:36 ` Tulio Magno Quites Machado Filho
2022-01-27 15:25 ` H.J. Lu
2019-07-25 13:24 ` Stefan Liebler
2019-07-09 21:08 ` [PATCH] test-in-container: Install locales into the test container Carlos O'Donell
2019-07-09 23:55 ` DJ Delorie
2019-07-12 4:02 ` Carlos O'Donell [this message]
2019-07-12 5:49 ` Florian Weimer
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=104acd37-66be-621b-6eb9-e014fac2e81d@redhat.com \
--to=carlos@redhat.com \
--cc=dj@redhat.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.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.
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).