(→Wishlist: add my 2 cents) |
|||
Line 65: | Line 65: | ||
# [[User:Adamwill|adamw]] - [[QA:Fedora_16_Install_Test_Plan|Install test plan]] was mostly neglected this cycle; might be a useful framework for working out plans for stuff like grub2. in f17 we could use it for anaconda re-design | # [[User:Adamwill|adamw]] - [[QA:Fedora_16_Install_Test_Plan|Install test plan]] was mostly neglected this cycle; might be a useful framework for working out plans for stuff like grub2. in f17 we could use it for anaconda re-design | ||
# [[User:Tflink|tflink]] - We really didn't do a whole lot with EC2 testing for F16. Since EC2 issues are now release blocking issues, we should probably be coordinating something or working with the Cloud SIG to make sure that the testing gets done. | # [[User:Tflink|tflink]] - We really didn't do a whole lot with EC2 testing for F16. Since EC2 issues are now release blocking issues, we should probably be coordinating something or working with the Cloud SIG to make sure that the testing gets done. | ||
# [[User:Mkrizek|mkrizek]] - We should have tested if transition between SysV and systemd init scripts went fine. For instance cups was not enabled when upgrading from F15. | |||
=== Wishlist === | === Wishlist === |
Revision as of 14:09, 14 November 2011
Introduction
This page is intended to gather feedback from the Fedora QA community on things that worked well and things that could have been better with the testing of Fedora 16. The feedback will be used as a basis for identifying areas for improvement for Fedora 16 testing. Any thoughts, big or small, are valuable. If someone already provided feedback similar to what you'd like to add, don't worry ... add your thoughts regardless.
For any questions or concerns, send mail to test@lists.fedoraproject.org.
Providing feedback
Adding feedback is fairly straight forward. If you already have a Fedora account ...
- Login to the wiki
- Select [Edit] for the appropriate section below.
- Add your feedback using the format:
* ~~~ - I like ____ about the new ____ process
- When done, Submit your changes
Anonymous
If you do not have a Fedora account, follow the instructions below to submit anonymous feedback. Please note, mediawiki records the IP address associated with any anonymous page edits.
- Select the appropriate page for your feedback...
- Add your feedback using the format:
* ~~~ - I like ____ about the new ____ process
- When done, Submit your changes
Feedback
Things that went well
Could have been better
- jlaska - Pre-release acceptance - the Rawhide Acceptance milestones continue to sneak up on us ... and it takes a bit to get images lined up. It's better this release with twu owning the QA side of the process, but it still feels like there is more room for transparency/communication around the process.
- adamw - when there are showstoppers in anaconda early we tend to just sit around and wait for them to get fixed, but without much urgency; which means we're getting no idea of what bugs are lurking behind the showstoppers, and we wind up trying to fix a lot of blockers in a small amount of time once the showstoppers are finally fixed
- jlaska - Alpha TC1 - Missed the Alpha-TC1 milestone by 1 week, little to no communication regarding status. With only two weeks Alpha ISO test time, losing 50% of time almost certainly results in a slip. See
rel-eng ticket#4844
. None of the Alpha rel-eng release tickets have been filed at this time.- adamw - perhaps releng image compose SOP should require updating of ticket with progress info, especially when image compose / delivery is delayed?
- jlaska - Alpha branch - Unclear when the F16 branch was completed as not all tasks in the Mass_Branching_SOP were completed. The SOP either needs to be followed or updated.
- MirrorManager was not updated to add a fedora-16 repo tag, therefore, TC1 installations could not find a repository to install from (RHBZ #727428)
- TC1 images were built with
Version=16-Alpha.TC1
specified as the--version
argument topungi
. This results in a file/.buildstamp
in the install image with an incorrect version (Version=16-Alpha.TC1
) that is used as the$releasever
variable for yum. The net result is that there are no yum repos that matchrepo=16-Alpha.TC1&arch=x86_64
. The version needs to be an integer, or MirrorManager redirects need to be established prior to compose. - The
package was not properly updated to includefedora-release
[fedora]
withenabled=1
. As a result, TC1 images included a fedora-release package that didn't enable the Fedora 16 repos. - The
package was not updated to include the Fedora 16 release name Verne. This is a minor issue, but results in login prompts claiming the system is Rawhide. Recommend updating (or creating) the existing Mass_Branching_SOP to document expected results when updating fedora-releasefedora-release
- adamw - seems branching may not actually have been completed by time of TC1 delivery, even. Perhaps appropriate releng SOPs should be updated to clarify that branching - or at least some specified subset of branching tasks - must be completed before Alpha TC1 delivery
- jlaska - Alpha RC2 - RC2 was composed to resolve the following blocker bugs...
for RHBZ #692433libreport-2.0.5-4.fc16
for RHBZ #727501NetworkManager-0.8.9997-7.git20110721.fc16
for several NTH bugsanaconda-16.14.3-1.fc16
for RHBZ #728863selinux-policy-3.10.0-15.fc16
for RHBZ #716005abiword-2.8.6-12.fc16
- jlaska - Alpha RC3 - RC3 was composed to resolve the following issues ...
for RHBZ #692433 -- appears this wasn't pulled into RC2 as expected.libreport-2.0.5-4.fc16
- jlaska - Alpha RC4 - RC4 was composed to resolve the following issues ...
for RHBZ #720070anaconda-16.14.5-1.fc16
andlibreport-2.0.5-5.fc16
for RHBZ #723666, RHBZ #729537 and RHBZ #730438lorax-16.4.1-1.fc16
,at-3.1.13-2.fc16
,dracut-011-41.git20110810
andxen-4.1.1-3.fc16
for RHBZ #728707 and RHBZ #728863accountsservice-0.6.13-2.fc16
- jlaska - Alpha RC5 - RC5 was composed to resolve the following issues ...
for RHBZ #730863anaconda-16.14.6-1.fc16
for RHBZ #730887libreport-2.0.5-6.fc16
- adamw - it wasn't an A+ idea for both rpm maintainers to be on vacation at the same time, with no cover in place, during a critical freeze period
- adamw - when we hit an obvious showstopper we tend to focus in on it exclusively until it's fixed, iterate, and then be surprised when there are bugs hidden behind it; we should work harder to try and workaround showstoppers in a way that has as small an impact as possible, and continue testing, to avoid this problem. e.g. RHBZ #730863 hid behind RHBZ #729563, but we could have exposed it by editing /etc/selinux/config in the installed system prior to rebooting from the installer
- robatino - Alpha and Beta torrents often have unsigned checksum files - this just happened with 16 Alpha. It also happened during F13 and F14 - see http://lists.fedoraproject.org/pipermail/test/2010-April/090106.html for F13 Beta, and https://bugzilla.redhat.com/show_activity.cgi?id=638738 for F14 Alpha and Beta. When it's pointed out, we're told that it's not feasible to change them once people have started downloading, but if this is true, there needs to be better checking (at least as much as for mirror content, which can be changed) to make sure the torrents are correct before being posted. Filed https://fedorahosted.org/fedora-qa/ticket/237 and https://fedorahosted.org/rel-eng/ticket/4906 . No response from releng as of yet. Unless QA is given access prior to public posting, it is powerless to prevent this.
- robatino - Also, it's possible that the checksum files can be signed more than once. There are two versions of the signed checksum files for F15, one on the torrents (the original ones) and a different one on the mirrors. See http://robatino.fedorapeople.org/checksums/15-Final/ for the two versions - for example, Fedora-15-i386-CHECKSUM.orig and Fedora-15-i386-CHECKSUM. While not nearly as serious as the above issue (since the checksums are the same and both signatures are good), it could be confusing.
- adamw - we completely and utterly whiffed on EFI testing for Alpha and Beta. Need to sort things out so at least two QA team members have EFI capable hardware and test EFI installs at all release points.
- adamw - NFS testing instructions may need to be more precise to avoid pilot errors, and may need to account for NFSv4 quirks.
- adamw - need to do more direct personal pinging of maintainers who seem unresponsive to blockers; some respond when contacted directly but do not appear to place a high priority on bug reports
- adamw - Install test plan was mostly neglected this cycle; might be a useful framework for working out plans for stuff like grub2. in f17 we could use it for anaconda re-design
- tflink - We really didn't do a whole lot with EC2 testing for F16. Since EC2 issues are now release blocking issues, we should probably be coordinating something or working with the Cloud SIG to make sure that the testing gets done.
- mkrizek - We should have tested if transition between SysV and systemd init scripts went fine. For instance cups was not enabled when upgrading from F15.
Wishlist
- robatino - Proposed regular naming scheme for blocker and NTH tracker bugs (https://fedoraproject.org/wiki/Talk:BugZappers/HouseKeeping/Trackers)
- adamw - we need to extend our coverage of various methods of booting the installer: we need to check all the combinations of EFI / BIOS boot with installer written to spinning disc or USB, using dd or livecd-iso-to-disk or liveusb-creator. We may need to do this by extending the columns in the matrix rather than by adding test cases; so we'd have more results columns for some of the test cases. Particular problem cases that came up in F16 were different bugs in EFI booting with different images, and various issues that show up when you boot the installer from USB rather than a spinning disc.
- tflink - Maybe it was due to the high number of TC/RC spins that we did for F16 but it would be awesome to have some more automation around image generation for testing. I'm not talking about any rel-eng processes but it would be nice to be able to request generation of a boot.iso made from custom packages and packages in koji in order to do testing. I can see this being helpful for test day coordination as well but there are issues with complexity and hosting so this is a bit of a "pony list" item.
- tflink - Since qemu/kvm VMs are all legacy BIOS emulation, it would be awesome to do EFI emulation. There are some projects out there on using EFI in qemu VMs but it is unknown whether they actually work. Either way, it might be good to look into them in order to evaluate whether their use is practical
- adamw - wider upgrade coverage: upgrade with KDE installed and EFI upgrade are two areas that probably need testing
- cwickert - wider upgrade coverage: Test all supported grub locations, not only MBR but also first sectors of /boot
- cwickert - ChangeLog in the wiki to seee which packages were updated and which bugs are supposed to be fixed by a new compose.
- cwickert - More testers for spins, otherwise it's hard to catch up with the speed the new composes are done.
Recommendations
After enough time has been given for feedback, the QA team will discuss and make recommendations on changes to prioritize for Fedora 17. This section organizes and lists the recommendations.
In order to coordinate efforts, and measure effectiveness of recommendations, please record and track any action taken in the Fedora 17 roadmap in the QA TRAC instance.