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.
* 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
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.
As a maintaner it's quite easy to occationally miss that here have been
negative feedback, and it happens that things gets done in a hurry.
2. Any update marked as 'critpath breaking' by a proven
tester would be
blocked from being pushed stable at all - automatically or manually -
until the PT modified the feedback or it was overridden by someone with
appropriately godlike powers (TBD, but probably not just the maintainer)
I would propose that it's blocked unil any proven tester flags that it's
now ok, at which point the maintainer or a proven packager can push the
package.
3. Any update marked as 'critpath breaking' should probably
get
announced on at least test-announce and/or devel-announce
Yes.
4. Any update marked as 'critpath breaking' *after it has
already been
pushed* would similarly trigger a major response: notify maintainer very
hard, notify lists, generally do stuff to make sure it gets immediate
attention
Absolutely.
Regards
Henrik