On Tue, 2018-03-06 at 08:48 -0500, Randy Barlow wrote: > Greetings! > > Does anybody here know the history and/or purpose behind Bodhi's > critical path karma? A brief grepping of Bodhi's codebase makes me think > it isn't really used by Bodhi for any purpose other than recording and > displaying people's entries. I.e., it doesn't seem to be used in Bodhi's > state machine. It also seems to be confusing for testers. > > Does it serve a purpose? If not, should we remove it? None of the replies so far was quite correct. It exists more or less entirely because of this old post of mine: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/5ADUVYLOHQVOEKPPOYQYVLCBGPNMOVI7/ which wound up being quite a significant input into Bodhi 2.0's design. Quite a few things in Bodhi 2 are there more or less "because that post suggested them". The reason you're confused is we never really finished hooking up all the ideas from that post. We put some of the necessary bits into Bodhi, but didn't get any further than that. So this separate feedback item exists, I think, basically because of this idea: "For me, one the principal benefits of such a system would be that we could make the 'This update breaks critical path functionality' checkbox an absolutely red flashing light, wailing siren emergency button. I mean, you hit that thing and trucks roll from Fedora HQ, metaphorically speaking. It would have a confirmation page which clearly described the impact of asserting that an update broke critpath, so we could be confident that it didn't get falsely triggered very often. I'd suggest that: 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) 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) 3. Any update marked as 'critpath breaking' should probably get announced on at least test-announce and/or devel-announce 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" But in the end...we put the separate feedback item into Bodhi 2's design, then stopped. We never actually implemented all of (or any of) the things I suggested there. So it's a bit of an odd duck at present. Removing it is one choice, sure. Looking at those ideas again and deciding if we want to actually go ahead and implement any of them is another choice. -- 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
