Thank you for the reply.
On Wed, Apr 13, 2016 at 7:34 PM, Kamil Paral <kparal(a)redhat.com> wrote:
thanks for your work and sorry for late response. I'll review your
taskotron task and let you know if there's something that should be changed
or not. Afterwards, we will start mirroring your git repo on our taskotron
servers, and patch our taskotron-trigger to know about task-libabigail. We
can then execute it on every new Koji build (or Bodhi update, your choice).
Your task will probably be the first one that we will execute regularly
while not being written and maintained directly by us, so if there are any
rough edges in the process, I apologize in advance :-)
Okay, sounds good to me.
You'll need to have two branches in your git:
master - this will be used on our production server
develop - this will be used on our dev and staging server
Okay, works for me.
You need to decide whether it is better to run libabigain against every new
Koji build, or just against every new Bodhi update. From a quick
think it makes more sense to run libabigail on every new Koji build, so
that people can see the results even before creating the update (that
requires looking into ResultsDB manually at the moment). If we run it on
every Koji build, the results will still show up in Bodhi - Bodhi should
query ResultsDB and show the results for those particular builds present in
the update. (We might need to teach Bodhi about libabigail existence, I'm
not sure). Ultimately it's your choice, what makes more sense for your
I believe that when we say every new Koji build, we are talking about
non-scratch build which doesn't include scratch build done by anyone. If my
assumption is right, then yes running libabigail task on each koji build
will be good. It is possible to do that with current implementation since
libabigail task look for a koji build-id to download corresponding rpms.
Sure, I will create one.
We try to have at least some basic documentation and FAQ for our
there. Currently it's not very discoverable (we should link to it at least
from ResultsDB, which we currently don't) and the location can change, but
at least it's a link we can give to people when asking basic questions
about one of our tasks. Also, since you're going to maintain the task and
not us, please include some "Contact" section where to post feedback or
report bugs (e.g. github issues page). If people ask us about the task and
we don't know the answer, we will point them to that wiki page.
Will add contact section in wiki page.
I wonder if it is better to have this included with other fedora qa tasks?
Can we please continue this discussion in qa-devel  mailing list?
can discuss more implementation details in there, and I'll post my review
findings in there as well.