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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
