From: R Hill <dirtyepic@metawire.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: The usefulness of test in FEATURES
Date: Sat, 30 Apr 2005 13:43:42 -0600 [thread overview]
Message-ID: <d50mqb$f67$1@sea.gmane.org> (raw)
In-Reply-To: <20050430134818.GO8632@kfk4ever.com>
Maurice van der Pot wrote:
> It's understandable that fixing this is a low priority thing, but what
> I would like to propose is to either fix the tests or disable them.
> The latter would be the thing to do for devs who are currently closing
> bugs about tests with WONTFIX or similar.
>
> If fixing the tests is not WONTFIX but rather something way down on your
> todo list, I would also recommend disabling the tests in the ebuild.
> A bug report could be used to track these bugs, but at least it would
> not bother so many people while it is still unsolved.
Well, in my experience as a user that has made it a priority to report
broken test suites when I come across them (w/ patches attached whenever
I can), I would argue that if you take the maintainers that close test
failures as WONTFIX, and add to them the maintainers who don't care one
way or another, and have them all disable test in their packages, you
might as well not even have the test feature at all. :P
> By keeping tests that fail enabled in one ebuild, perfectly good tests
> of any other ebuild are rendered useless because it becomes almost
> impossible to upgrade a system with "test" in FEATURES.
It's not so bad. I keep a running list of which packages fail their
tests on me and it's usually under half a dozen at any given time. I
have about another half dozen open in bugzilla but most of them have
patches included.
I can definitely understand why test failures are a low-priority thing.
They're a pain in the ass and it's not like you need yet another thing
to maintain. But IMHO it's better to leave them enabled for some sap
like me to fix one day down the line than to disable them now and lose
that opportunity.
Maybe a way of lessening the annoyance of test failures would be having
a way to resume the build at the install phase. I'm thinking of
something similar the touch ${BUILDDIR}/.compiled trick. as it is, if
you remove test from FEATURES, touch .tested, and then 'ebuild
foo.ebuild install' the tests still run. This is especially frustrating
when you've just spent 6 hours compiling a package to have it fail
because of sandboxing.
--de.
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2005-04-30 20:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-30 13:48 [gentoo-dev] The usefulness of test in FEATURES Maurice van der Pot
2005-04-30 15:30 ` Rumen Yotov
2005-04-30 15:48 ` Jason Stubbs
2005-04-30 16:32 ` Rumen Yotov
2005-04-30 17:32 ` Maurice van der Pot
2005-04-30 17:45 ` Jason Stubbs
2005-04-30 17:54 ` Jason Stubbs
2005-04-30 19:43 ` R Hill [this message]
2005-05-01 1:27 ` [gentoo-dev] " Georgi Georgiev
2005-05-01 7:27 ` R Hill
2005-05-01 8:59 ` Jason Stubbs
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='d50mqb$f67$1@sea.gmane.org' \
--to=dirtyepic@metawire.org \
--cc=gentoo-dev@lists.gentoo.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