On Tue, 10 Jun 2008 23:16:04 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> if people are just going to RESTRICT tests when they fail (and they
> will, because it's a hell of a lot easier than actually fixing them),
> what's the point of having a testsuite at all? and once a testsuite is
> restricted, it'll stay restricted even if upstream fixes the problem
> because no one will bother checking.

You're assuming that developers are lazy, incompetent and don't care
about QA. If this isn't the case, developers will instead fix or remove
individual test failures where reasonably possible, and will unrestrict
tests when doing version bumps.

--
Ciaran McCreesh

On Wed, 11 Jun 2008 06:24:18 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> People will (and should) have -test in FEATURES anyway, good
> self-test suites usually take more than twice the time to build and
> run, may have additional dependencies that could take lots of time.

So how are we supposed to handle packages where upstream *require* that
anyone building from source runs 'make check'?

--
Ciaran McCreesh

On Wed, 11 Jun 2008 06:19:16 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 10 Jun 2008 23:16:04 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> > if people are just going to RESTRICT tests when they fail (and they
> > will, because it's a hell of a lot easier than actually fixing
> > them), what's the point of having a testsuite at all? and once a
> > testsuite is restricted, it'll stay restricted even if upstream
> > fixes the problem because no one will bother checking.
>
> You're assuming that developers are lazy, incompetent and don't care
> about QA.

Historically speaking, yes. Well, one and three at least.

> If this isn't the case, developers will instead fix or
> remove individual test failures where reasonably possible, and will
> unrestrict tests when doing version bumps.

That would be awesome, and i'd love to be proven wrong.


--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Ciaran McCreesh a écrit :

So how are we supposed to handle packages where upstream *require* that
anyone building from source runs 'make check'?


If it's required to get the final binaries, then it should be in
src_compile.


I don't know any package that does require such a thing, but IMHO it
should be a QA warning if a build system writes anything to ${D} during
src_test. (could sandbox be tweaked to do that?)


Rémi
--
gentoo-dev@lists.gentoo.org mailing list

On Wed, 11 Jun 2008 07:39:53 +0200
Rémi Cardona <remi@gentoo.org> wrote:
> Ciaran McCreesh a écrit :
> > So how are we supposed to handle packages where upstream *require*
> > that anyone building from source runs 'make check'?
>
> If it's required to get the final binaries, then it should be in
> src_compile.
>
> I don't know any package that does require such a thing, but IMHO it
> should be a QA warning if a build system writes anything to ${D}
> during src_test. (could sandbox be tweaked to do that?)

A whole bunch of science packages have upstreams that say "If you're
building from source, run 'make check' and if it fails don't carry on".

For that matter, I'm strongly inclined to say that for Paludis too...

--
Ciaran McCreesh

Ciaran McCreesh wrote:

On Wed, 11 Jun 2008 06:24:18 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

People will (and should) have -test in FEATURES anyway, good
self-test suites usually take more than twice the time to build and
run, may have additional dependencies that could take lots of time.


So how are we supposed to handle packages where upstream *require* that
anyone building from source runs 'make check'?


Spank them as we already do for people building their test as part of
the default target.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list

On Wed, 11 Jun 2008 01:42:34 +0200
Bo Ørsted Andresen <zlin@gentoo.org> wrote:

> > > - Enable FEATURES=test by default (bug #184812)
> >
> > Only if >99% of the stable and ~arch tree and all potential "system"
> > packages build with it (IOW: no)
>
> Err.. Maybe this could have been phrased better but then I did expect
> you would look at the bug before commenting. The idea is to enable
> tests by default in EAPI 2 and beyond and let them stay off by
> default in EAPI 0 and 1. This way devs who want to use EAPI 2 will
> either have to fix their tests or RESTRICT them. Doing it this way
> avoids the issue of having to fix the whole tree all at once. Users
> can still choose not to go with the default.

I thought tests were already supposed to pass whatever the EAPI is and
devs were supposed to run them...


Alexis.

Patrick Lauer wrote:

On Tuesday 10 June 2008 16:54:49 Richard Brown wrote:

On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <cardoe@gentoo.org> wrote:

At this point, we should really only discuss features that all 3 package
managers have implemented.

I'm not sure that's a good idea, only two have implemented EAPI 1 so far.


Yes, but noone cares about Paludis.

Now could you please do the rest of us a favour and keep the discussion
focussed on improving technical details instead of random insults at others?


Isn't that, in itself, an insult and you don't seem to have advanced the
discussion at all.

--
gentoo-dev@lists.gentoo.org mailing list

On Wed, 11 Jun 2008 07:48:06 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 06:24:18 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> People will (and should) have -test in FEATURES anyway, good
> >> self-test suites usually take more than twice the time to build and
> >> run, may have additional dependencies that could take lots of time.
> >
> > So how are we supposed to handle packages where upstream *require*
> > that anyone building from source runs 'make check'?
>
> Spank them as we already do for people building their test as part of
> the default target.

Oh, so Gentoo has decided that basic QA is another 'poor programming
practice' now?

--
Ciaran McCreesh

Ciaran McCreesh wrote:

On Wed, 11 Jun 2008 07:39:53 +0200
Rémi Cardona <remi@gentoo.org> wrote:

Ciaran McCreesh a écrit :

So how are we supposed to handle packages where upstream *require*
that anyone building from source runs 'make check'?
If it's required to get the final binaries, then it should be in
src_compile.


I don't know any package that does require such a thing, but IMHO it
should be a QA warning if a build system writes anything to ${D}

during src_test. (could sandbox be tweaked to do that?)


A whole bunch of science packages have upstreams that say "If you're
building from source, run 'make check' and if it fails don't carry on".


Their rationale behind that is that their code is severely broken, using
experimental features from their language of choice or, simply, that
they are paranoid and couldn't think better ways to annoy people?



For that matter, I'm strongly inclined to say that for Paludis too...


Getting the build time from 30minutes to an hour or more?

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list