A Glorious Vision of Our Shared Update Feedback Future (bodhi, karma, and proventesters, oh my)

[Adam Williamson]

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
one. Thanks.

> * When the update consists of multiple packages, ability to indicate
> which of those packages the given feedback is about.

Good idea.

> 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
> optional.
> 
> > 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!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net