Fedora 12 QA retrospective - feedback needed

[James Laska]

On Wed, 2009-11-25 at 23:12 +0000, "Jóhann B. Guðmundsson" wrote:
> 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...

I thought that it wasn't official also, but this method has been added
to the installation guide for F-12 (see
http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch17s02.html).  

> 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.

Should I add a general "could have been better" item for improved
communication between maintainers and QA?  Does that accurately capture
your thoughts here?

Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20091130/28c02075/attachment.sig>