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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
