May I file 1000 bugs aka upstream test suite tracking

Adam Williamson awilliam at redhat.com
Fri Feb 21 18:27:39 UTC 2014


On Fri, 2014-02-21 at 16:48 +0200, Alexander Todorov wrote:
> > On Fri, Feb 21, 2014 at 9:30 AM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> >> Please make sure to follow
> >> https://fedoraproject.org/wiki/Mass_bug_filing to the letter. If you
> >> do not, it will make life very difficult.
> >>
> 
> Thanks, I'll take a look at it and follow it when it comes to mass filing of bugs.
> 
> 
> На 21.02.2014 16:38, Josh Boyer написа:
>  > On Fri, Feb 21, 2014 at 9:30 AM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> >> A better case here would be to find a way to identify those packages
> >> whose upstreams have tests that are not being run in %check. That
> >> probably *would* be considered a bug.
> >
> > Unless there's a decree from FESCo or FPC about requiring this, it's
> > going to be up to the maintainer as to whether using %check to run
> > testsuites is required.  A lot of testsuites require external network
> > access and won't work when run under koji.  Also, it increases build
> > time and can bloat BuildRequires.  It is *not* a clear-cut bug.
> >
> 
> I agree with Josh on this one, however many packages simply forget about %check. 
> I will find packages which have test suites but not execute them in %check and 
> file bugs as a separate action. However the difference between having tests and 
> not executing them in %check is very small (<5%).

Note the point that some packages intentionally do not run their test
suites for the reasons Josh gave.

It is probably a good idea for such packages to include a commented-out
%check section that simply explains this, though:

---

%check
# test suite not run as it requires network access

%files
...

---

for e.g. This is becoming a convention in some packaging areas at least
(e.g. PHP).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net



More information about the devel mailing list