Fedora 12 QA retrospective - feedback needed
jlaska at redhat.com
Mon Nov 30 14:02:34 UTC 2009
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
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the fedora-test-list