A way out of the update trap

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

Jóhann B. Guðmundsson wrote:
> 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.
>
Members of the QA group could provide that feedback

There is also an additional problem it's the lack of test cases.
( does not apply to bug fixes since you can inspect the bug report and 
check if it fixes what was discussed there )

For instance should a tester vote +1 in karma if the application starts?
Should he vote +1 if the application does x,y and z?

"Updated to upstream version" is a favor of mine and tells me nothing

Well I have to admit sometimes I bother to go upstream and read the 
changelog
sometimes..

Did that new upstream release bring several bug fixes?
( Dont those fixes need testing)

Did that new upstream release bring enhancements?
( Dont those enhancments need testing)

Hey I start the application it runs should I vote +1 in karma

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/4607c551/attachment.vcf>