How about this. Instead of trying to craft a policy right now which applies equally to all parts of the distribution. Let's narrowly define a prioritized list of functionality which we think is critical and deserves to be a priority when doing update QA. Here's my short list 1) Packaging Updating at the console (rpm and yum) 2) Package Updating in the desktop (PK and friends) 3) python-matplotlib 4) xeyes Your list with most likely be different than mine. But can we get project wide consensus as to the top 2 are really really important to keep working for 'most' people? Everything else aside.. all the good and bad ideas about how to do a top to bottom restructuring of updates generation project wide off the table for a few seconds. Can we agree that 1 and 2 are critical functionality which deserves extra precautionary effort to reduce the risk of falling over and dying for users compared to other functionality? Maybe more important than security? If an update goes out which could impact rpm,yum,PK and friends can we make it a policy that those updates require a specific level of testing, even if it means holding up a security tagged update until basic functionality of rpm,yum,PK is confirmed? This is a risk management argument I am making. -jef"is really thinking about adapting all the Integrated Safety Management training that was beaten into him while at PPPL and re-applying it to Fedora packaging"spaleta -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
