From Fedora Project Wiki
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.TC1specified as the--versionargument topungi. This results in a file/.buildstampin the install image with an incorrect version (Version=16-Alpha.TC1) that is used as the$releasevervariable 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
fedora-release[fedora]withenabled=1. As a result, TC1 images included a fedora-release package that didn't enable the Fedora 16 repos. - The
- 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...
- jlaska - Alpha RC3 - RC3 was composed to resolve the following issues ...
- jlaska - Alpha RC4 - RC4 was composed to resolve the following issues ...
- jlaska - Alpha RC5 - RC5 was composed to resolve the following issues ...
- 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
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.
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.