On Thu, 2018-02-15 at 13:11 +0100, Petr Šplíchal wrote: > > > The question 'who decides which tests block which packages' is > > left a bit up in the air, but in fact no more so than it already > > was for package-specific tests... > > Right. Do we want to change this? Specify this more strictly? > Like exactly defining requirements which an Always Ready Operating > System has to meet? And then mapping these requirements to the > test coverage? (Here again FMF mentioned above might come handy.) Maybe we should just *formalize* it a bit, so folks know where they stand. So far we've basically done three things that implicitly describe the policy on this: 1) Bodhi has a mechanism by which the person submitting an update can specify some tests that block the update 2) FESCo accepted, voted on and approved a ticket which involved a decision that certain tests blocked some/all updates 3) We built and deployed WaiverDB and Greenwave such that Greenwave currently accepts waivers submitted to WaiverDB by...(anybody??? this point I'm not sure on) So, effectively, we have communicated that FESCo can set mandatory policies here, and packagers can also make voluntary choices. Point 3) is rather a crucial one, and I don't know that it's been formally discussed anywhere; I think we have been rather heavily focused on building the tools as opposed to setting the policy so far. But we've at least clearly implied so far that FESCo claims to some extent the power to set automated test gating requirements for updates, and that packagers have some ability to extend those requirements voluntarily, and also submit waivers. I guess the natural thing to do from here, if we want to be a bit more explicit about it, would be to extend the Updates Policy: https://fedoraproject.org/wiki/Updates_Policy either in-line or with a subsidiary document, to define this stuff a bit more clearly/formally. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
