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.
begin:vcard
fn:Johann B. Gudmundsson
n:Gudmundsson;Johann B.
org:Reiknistofnun - University of Iceland;IT Management
adr:Taeknigardi;;Dunhagi 5;Reykjavik;;107;Iceland
email;internet:johannbg@xxxxx
title:Unix System Engineer RHCE,CCSA
tel;work:+3545254267
tel;fax:+3545528801
tel;pager:N/A
tel;home:N/A
tel;cell:N/A
url:www.rhi.hi.is
version:2.1
end:vcard
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
