> 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. Well made. +1. But can we really afford to be so slipshod with xeyes? Next thing you know, someone with break KSpaceDuel, and then it's all over. . .;) > -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 > -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
