A way out of the update trap

["Jóhann B. Guðmundsson"]

Jon Ciesla wrote:
>> 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. . .;)
>
>   
>
I suggested an time based approach on this matter on #fedora-qa.

Have packages stay in updates-testing for an x amount of time before 
pushed to update
with the ability to be rushed through.

Packages that would cause system breakage would stay for example 5 days.
Non system-breakage packages for example 3 days
Security and urgent updates for a day them being flagged as urgent and mail
sent to the test-list asking testing asap.

That at least guarantee an x time for testing and to provide feedback 
but of course
does not guarantee feedback from testers any more than it is today.

JBG


-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081212/6c777d53/attachment.vcf>