A way out of the update trap

Jon Ciesla limb at jcomserv.net
Fri Dec 12 18:49:12 UTC 2008


> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie




More information about the fedora-devel-list mailing list