Fedora 14 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 14. The feedback will be used as a basis for identifying areas for improvement for Fedora 14 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

Otherwise, if you do not have a Fedora account, follow the instructions below ...

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

Things that went well

1. jlaska - Beta released on time - Without a strong turn-out from the fedora-qa community, there is little chance that we would had the test results needed in order to properly assert that the beta release criteria had been met.
2. jlaska - Test Matrix - identifying concerns with the Fedora 13 test matrices, and implementing improvements for Fedora 14 worked really well. I really like to revised organization and cleaning of obsolete tests in the installation matrix (see QA:Fedora_14_Install_Results_Template).
3. jlaska - Release Criteria - For me, the release criteria continue to pay dividends. It's exciting to see bug reports, reported by testers outside the QA team regulars, escalated for blocker consideration that reference specific criteria. While we knew going into this that identifying and documenting 100% of the use cases of Fedora that we would block the release for was impossible, we seem to capture a majority of low hanging use cases as the currently documented. I also like the public discussion around proposing and debating changes to the criteria. Nice work to all involved :)

Could have been better

Fedora 16 alpha (Gnome) fails to complete properly (and does not give compliance warnings) when an NVIDIA Quadro FX3400SLI (HP Supplied) is installed in an HP XW4600 Workstation. (Works fine with NVIDIA GeForce similarly scaled cards). Under Fedora 15 (Gnome) the Quadro card reports no support under Gnome 3. - Cheers - reynolds@mira.net

1. jlaska - Beta RC delayed - Beta RC candidates were delivered late, as there were 2 unresolved beta RC blockers (see below). Specific to the following two issues, it's not clear what can be improved/corrected next time?
   • RHBZ #629719 - parted - random failures when notifying kernel of changes to partitioned md (isw) device's partition table
   • RHBZ #633315 - anaconda - Connections not editable in nm-c-e in anaconda
2. jlaska - Fixing more than blockers - For F-14-Alpha, a new anaconda with 2 blocker bug fixes was requested, but the new version contained many more fixes. Question, did the additional bug fixes break anything?
   • Recommendation - Early creation of f14-{alpha,beta,final} git branches for anaconda to allow for more control over commits.
3. jlaska - Root cause analysis - on why the following issues were discovered late
   1. RHBZ #627789 - several users reporting problems installing from HD ISO due to this bug. However, testing RC3 showed no problems installing HD ISO ... there is a disconnect somewhere between the use case exercised and the test case? (see docs follow-up)
   2. RHBZ #638091 - Kernel panic at boot after glibc update - Updating to glibc-2.12.90-13 (see bodhi) resulted in a kernel panic upon reboot. The system would be fine until the prelink command ran, and then it would never boot and all commands would segfault on a running system. The issue was initially given positive proventester feedback, but was then reverted after the tester found the problem. The good news, the problem was discovered in updates-testing before it landed in updates. However, it would be good to have some documented test procedures for a subset of packages to guide proventesters
4. jlaska - Virt Test Day - Participation in the test day was low and not what we had hoped for. We identified this problem during the Fedora_13_QA_Retrospective, what can be done to provide meaningful public test events for Virtualization?
5. jlaska - KDE bugs - are KDE-only bugs release blockers? It's unclear how to handle this or what FESCO intends (see RHBZ #641338).
6. jlaska - Wiki Test Matrix - we've hit the maximum threshold for mediawiki parser function calls, Category:Pages_with_too_many_expensive_parser_function_calls (for specific example, see Test_Results:Fedora_14_Beta_RC3_Install). Might be able to modify Template:Result to reduce the parser function calls, but not sure what else to do. Switching to a formal test case management system for this specific issue seems like overkill, but certainly an option.
7. jlaska - Proventesters - The proventesters sign-up and instructions are awesome, but I think we have a gap around providing specific instruction for certain packages (kernel, glibc etc...). Can we outline a process and some wiki structure to encourage mailing list discussion and drafting of package-specific test procedures (e.g. [[:Category:Test_Cases] or Category:Test_Plans)?
8. mmaslano - Adding positive/negative karma - In Bodhi should be hint/help for adding karma +/-1. Imho it's not clear that I don't give -1, when I find new bug in update. Therefore, it would be nice to have it next to button 'doesnt work'.
9. mmaslano - Too few testers - I don't care when I don't have many testers. The problem is wrong testing. 0 karma - I've updated and nothing wrong happened, doesn't help me much, but it's much better than +1 without even trying to run something dependent on update. Imho tester should try reproduce bug after update. But it is even better if he run their scripts/apps dependent on update and it's still working. For example if I update threads in perl, then I would be grateful, when someone with his own threads dependent script give me feedback. I was thinking about creating list of dependent packages, so tester could choose his favourite component. It might be useful for libraries and interpreters.
10. rhe - Tests and Criteria - Criteria was kept changing during the test cycle, the tests need to sync with it, so the tests should be reviewed and updated.
11. rhe - Install Test Matrix - Every time one has to click the show/hide button to check the collapse table, better to find an alternative way to save it.
12. rhe - Reference Section Separated - Not sure if it's a good way to separate the references from the tests (the reference used to be in the same row as test case), sometimes we have to look for which test case caused the issues in the matrix.
13. dramsey - To virt or not to virt. I strongly suggest that a review of the ideas and discussion about the Fedora 13 QA Retrospective Virtualization Days be reviewed for your advantage. Too much Smorgasboard food to choose from, may be you like chicken, I like beef, he likes pork and she likes fruits&vegetables.

    "...

    * I would ask that a test week be considered in order to accomplish all the test cases,

    * scale to fit the single test day structure, or

    * cut into individual bitesize chunks...."

14. Adamwill - No Live image ticket for Final-TC - We should have live images created for the test compose milestone
15. Poelstra - ISO delivery time of day - It's never clear when QA should be prepared to announce and begin testing on ISO images. Currently, QA monitors the rel-eng ticket to determine when images are available. I wonder if it would be better to request images at, or by, a specific time of day to ensure someone in QA can begin the processing.
16. jlaska - F-14-Final-TC1 Live images - The KDE and GNOME live images had different kernel packages. It appears that during generation of the images, a different mirror was used and an older kernel package was included for the KDE TC1 live image. mkrizek - The KDE live image had different selinux-policy package which had the https://bugzilla.redhat.com/show_bug.cgi?id=590883.
17. jlaska - Test Case - For several releases now we've included the test case QA:Testcase_Boot_Methods_efidisk.img in the install matrix. However, we don't have any hardware or expertise to run this test ourselves.
18. rhe - Test case - QA:Testcase_Mediakit_ISO_Size didn't include the target sizes for different live images, need to clarify it.
19. adamwill - F-14 go/no-go - The timing of the final release go/no-go was a day earlier than expected. Unclear whether this was intentional.

Wishlist

• I want a pony

1. jlaska - Debugging guide - Would love to have a PolicyKit debugging guide available at Category:Debugging
2. jlaska - Security related fixes - We have no criteria to appropriately prioritize security sensitive bugs
3. adamwill - Final release notes criteria - No criteria covered accepting RHBZ #643220 - Blocker bug for final version of release notes
4. jlaska - Tracking untested ON_QA - when updates are pushed, all ON_QA issues are pushed out to CLOSED ERRATA even if they haven't been tested. We should probably track these bugs.
5. jkeating - Source ISO size - The F-14 Source ISO's are too large (5Gb). QA doesn't currently check these images, should they?

Recommendations

After enough time has been given for feedback, the QA team will discuss and make recommendations on changes to prioritize for Fedora 14. 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 15 roadmap in the QA TRAC instance.

Coming soon...
Recommendations will arrive typically after problems have been diagnosed and improvements reviewed. This typically occurs after the release. Stay tuned ...

References

• See Fedora_13_QA_Retrospective
• See Fedora_12_QA_Retrospective
• See Fedora_11_Retrospective_Notes