A Glorious Vision of Our Shared Update Feedback Future (bodhi, karma, and proventesters, oh my)
awilliam at redhat.com
Wed Nov 23 01:28:29 UTC 2011
On Wed, 2011-11-23 at 02:19 +0100, Henrik Nordström wrote:
> tis 2011-11-22 klockan 13:03 -0800 skrev Adam Williamson:
> > * Any custom choices the package maintainer opts to provide, via some
> > kind of interface to Bodhi
> * Checkboxes per bug assigned to the update for indicating that the
> update have been verified to fix that specific bug.
Oop, yeah, I knew I was forgetting something - that was another major
> * When the update consists of multiple packages, ability to indicate
> which of those packages the given feedback is about.
> And "checkboxes" should all be tri-value with Werks / Not tested / Fails
Yeah, 'not tested' would be the default.
> If any is set to Fails then feedback comment is mandatory, otherwise
> > 1. Any update that is marked as 'critpath breaking' by a FAS-registered
> > tester would be blocked from going any further in the update process
> > without manual intervention (no autopushes at all)
> I would not limit that to critpath.
> Any update that have any negative feedback should be blocked from
> authpush. And maintainer should be alerted that there is negative
> feedback when trying to push the package.
We could tweak the rules here for sure, that's kind of the attraction. I
was focusing on the critpath case as an obvious one that benefits, but
indeed, we could look at interpreting certain negative results more
aggressively for non-critpath too. But right now we're riding our
wish-horses: I didn't want to get too far into the details, it was more
just an illustration of the kinds of capabilities non-numeric feedback
will give us, to make it really clear how much the simplistic current
feedback model is holding us back.
Thanks for the ideas though!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
More information about the test