On Tue, May 17, 2016 at 4:27 PM, Rich Freeman <ri...@gentoo.org> wrote:
> On Tue, May 17, 2016 at 5:15 AM, Kent Fredric <kentfred...@gmail.com> > wrote: > > On 17 May 2016 at 20:46, Tobias Klausmann <klaus...@gentoo.org> wrote: > >> And as for my pet peeve, tests that are known to fail, can we > >> also annotate that somehow so I don't waste hours running a test > >> suite that gives zero signal on whether I should add the stable > >> keyword? Even a one-line hin in the stabilization request would > >> be nice. As it is, I keep a list of known-to-fail packages and my > >> testing machinery tells me to not bother with FEATURES=test in > >> those case. > > > > IMO: Tests that are "expected to fail" should be killed. > > > > That makes sense, though ironically the only specific hypothetical use > case to come up so far was an example of just this situation. A > package is broken in stable, and a test was proposed to detect if > future stable candidates fix the flaw. There would be no point in > delaying stabilization of a package that contains the same error as > the current stable version. > > I don't see any harm in adding support for automated Gentoo-specific > tests, but I am skeptical of how much use they'll actually get. After > all, we started off with the statement that this is for situations > where upstream doesn't provide test suites, and if upstream can't be > bothered, why would we expect a distro maintainer to care more? > > -- > Rich > > Because we are already expecting an arch tester to conduct tests for the package. And knowing what to test is something I expect to come more easily from the maintainer.
