Fedora 16 QA Retrospective

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

• Gwjasu - I like ____ about the new ____ process

Adding feedback is fairly straight forward. If you already have a Fedora account ...

1. Login to the wiki
2. Select [Edit] for the appropriate section below.
3. Add your feedback using the format:

   * ~~~ - I like ____ about the new ____ process

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

1. Select the appropriate page for your feedback...
   • Something that worked well
   • Something that didn't work well
   • Anything on your QA wishlist
2. Add your feedback using the format:

   * ~~~ - I like ____ about the new ____ process

3. When done, Submit your changes

Feedback

Could have been better

1. 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.
2. 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
3. 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?
4. 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 to pungi. 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 match repo=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 package was not properly updated to include [fedora] with enabled=1. As a result, TC1 images included a fedora-release package that didn't enable the Fedora 16 repos.
   • The fedora-release 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-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
5. jlaska - Alpha RC2 - RC2 was composed to resolve the following blocker bugs...
   • libreport-2.0.5-4.fc16 for RHBZ #692433
   • NetworkManager-0.8.9997-7.git20110721.fc16 for RHBZ #727501
   • anaconda-16.14.3-1.fc16 for several NTH bugs
   • selinux-policy-3.10.0-15.fc16 for RHBZ #728863
   • abiword-2.8.6-12.fc16 for RHBZ #716005
6. jlaska - Alpha RC3 - RC3 was composed to resolve the following issues ...
   • libreport-2.0.5-4.fc16 for RHBZ #692433 -- appears this wasn't pulled into RC2 as expected.
7. jlaska - Alpha RC4 - RC4 was composed to resolve the following issues ...
   • anaconda-16.14.5-1.fc16 for RHBZ #720070
   • libreport-2.0.5-5.fc16 and lorax-16.4.1-1.fc16 for RHBZ #723666, RHBZ #729537 and RHBZ #730438
   • at-3.1.13-2.fc16, dracut-011-41.git20110810, xen-4.1.1-3.fc16 and accountsservice-0.6.13-2.fc16 for RHBZ #728707 and RHBZ #728863
8. jlaska - Alpha RC5 - RC5 was composed to resolve the following issues ...
   • anaconda-16.14.6-1.fc16 for RHBZ #730863
   • libreport-2.0.5-6.fc16 for RHBZ #730887
9. 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
10. 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
11. 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.

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.