Taskotron (was: Re: Unannounced ABI change without soname bump in libevdev-0.6 in Rawhide (and F19 and F20...) breaks GNOME, probably other consumers)
awilliam at redhat.com
Tue Jan 7 06:30:07 UTC 2014
On Mon, 2014-01-06 at 13:47 -0500, Matthew Miller wrote:
> On Mon, Jan 06, 2014 at 11:04:39AM -0700, Tim Flink wrote:
> > > What about including them in the RPMs themselves, in a new section
> > > similar to the existing %check -- or just in a standard file location
> > > (so no changes to RPM itself are needed immediately)?
> > I'm not sure that I see how including more stuff than %check during
> > build is an advantage.
> > In my mind, %check is for running upstream's unit test suite at build
> > time, which is an appropriate and useful thing to do. However, I don't
> > think that running any functional or integration tests at build time is
> > the best approach. It just doesn't fit into what koji does and seems
> > like a dirty hack at best, asking for a world of hurt without
> > significant tangible benefit at worst.
> Yeah, I wasn't suggesting that they'd be run at build time, just that it
> might be nice to bundle them with the RPMs that they're supposed to apply
> to. This has some nice advantages in making them easy to find for anyone
> rpm-savvy, and makes it clear which tests match up to which code, without
> having to track that separately somehow.
The RPM spec file is a clearly defined thing that achieves a clearly
defined set of functions. Overloading it with something that's really
entirely different - an integration testing framework - seems
inadvisable. Keeping the tasktron configuration in the same (or an
associated) git repository seems to achieve the goal without putting
stuff in spec files which isn't actually part of building a package.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
More information about the devel