Taskotron (was: Re: Unannounced ABI change without soname bump in libevdev-0.6 in Rawhide (and F19 and F20...) breaks GNOME, probably other consumers)

[Tim Flink]

On Mon, 6 Jan 2014 11:53:14 -0500
Matthew Miller <mattdm at fedoraproject.org> wrote:

> On Mon, Jan 06, 2014 at 09:36:09AM -0700, Tim Flink wrote:
> > One of the primary reasons for replacing AutoQA with taskotron is to
> > make it easier for folks to contribute checks. AutoQA's
> > implementation just isn't capable of doing that in a reasonable
> > fashion. We haven't gotten into the specifics of how
> > package-specific checks would work yet, but one idea was to keep
> > them in the package's git repo.
> 
> 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.

Package specific tasks aside, the current plan is to have each task in
its own git repository. To change the task, someone with commit
privileges changes the correct branch in the repo.

I haven't given a whole lot of thought to how exactly we'll do package
specific checks. Keeping the checks in the package's git repo is the
first thing that comes to mind but I'm sure there other possible
solutions. Either way, it falls pretty squarely into the category of
"stuff to get feedback from devel@ about before implementing". We have
a lot of work to do before we can start talking about implementation
details for package specific tests and given the number of variables
that we're looking at, I don't see much utility in discussing those
specifics yet - who knows what will change by the time we started
implementing the code to actually run the checks.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140106/76ce3a59/attachment.sig>