Fedora 12 QA retrospective - feedback needed

"Jóhann B. Guðmundsson" johannbg at hi.is
Wed Nov 25 23:12:44 UTC 2009


On 11/25/2009 09:54 PM, Matthias Clasen wrote:
> On Wed, 2009-11-25 at 13:35 -0800, Adam Williamson wrote:
>    
>> On Wed, 2009-11-25 at 16:20 -0500, Matthias Clasen wrote:
>>
>>      
>>> > From my perspective, the two main avenues to a new Fedora release are
>>> the live installer and preupgrade, and those two should get all the
>>> attention they can get.
>>>        
>> I'd say the main problem with preupgrade testing is that, given the
>> fairly limited resources QA has, it's rather hard for us to recreate the
>> infinite configurations people in the real world will try to run
>> preupgrade on. It's inherently a nightmare of complexity. We can
>> certainly try and do _better_ testing than we currently do, though.
>>      
> Sure you can't hope to test a full matrix, but that is just as much the
> case for anaconda... yet the anaconda test matrix looks a lot more
> complete than the upgrade one. Anyway, I don't want to make it sound
> like the upgrade situation is mainly a QA problem - it is
> first-and-foremost a maintainership problem; we must get out of the
> situation that one of the two main avenues to the next release is wwoods
> weekend project - of course, the other one being the unloved stepchild
> of the installer team is not exactly perfect either...
>
>    

FEI we are already improving preupgrade's QA process ( 
https://fedorahosted.org/fedora-qa/ticket/30  )

Afaik we dont official support upgrading between releases hence i'm not 
sure how high on the priority list upgrading is with Will and Team 
Anaconda and now "to shock you all" even with us...

If we have started to official support upgrading between release then we 
have to make dam sure user customization/configuration do not get 
overwritten and or lost in the process which means for example for the 
Gnome desktop spin no more "gconftool-2 --type int --set" workarounds 
for users to get their "old" behavior back.

How many backwards compatibility test cases have we receive from 
maintainers? ( afaik 0 )

How well have they informed us or the support team if a changes they 
have made breaks current behavior and or is backward incompatible heck 
hell do they even bother to inform us or the support team at all?

200 MiB boot partition used to be enough during preupgrades and I 
suspect the new initramfs might be the reason why it needs to be 
increased and I'm pretty sure Will and Team Anaconda gladly take any 
help they can get on improving preupgrading between releases.

JBG




More information about the fedora-test-list mailing list