Fedora 12 QA retrospective - feedback needed

Liam lili at redhat.com
Wed Dec 2 03:35:41 UTC 2009

On 11/26/2009 03:29 AM, James Laska wrote:
> Greetings folks,
> Whether you call it a post-mortem, retrospective or lessons learned ...
> the end result is the same.  I'd like to collect thoughts on how
> good/bad of a job the QA group did in planning and testing the Fedora 12
> release.  In keeping with the release-wide retrospective from Fedora 11
> [1], feel free to share any wishlist items as well.
> I've started the discussion on the wiki at
> https://fedoraproject.org/wiki/Fedora_12_QA_Retrospective.
> Adding your thoughts is easy ...
>        * Edit the wiki directly (instructions provided for ~anonymous
>          feedback)
>        * Or, reply to this mail (I'll collect feedback and add to the
>          wiki)
> Over the next week, I plan to organize any feedback and discuss the
> highlights during an upcoming QA team meeting.  The goal will be to
> prioritize the pain points and use as a basis for defining objectives
> for Fedora 13.
> Thanks for your feedback!
> James
> [1] https://fedoraproject.org/wiki/Fedora_11_Retrospective_Notes
Sorry for reply this mail so later. The following is my feedback:
Things that went well:
1.The schedule of  Fedora 12 Quality Tasks is accurate,from there, we 
can exactly know when to start the install testing.
2. The ticket to request Compose or media is very convenient and has 
high performance
3. People who participate in install test are increasing

Could have been better:
1. Install test on ppc platform is not sufficient. I mean some cases can 
not be executed comparing with i386/x86_64
2. Speed of test Media for download is snow,people are unwilling to 
download DVD to test.could we put this to mirror?or think about other 
way to solve this problem?
3. The install time is very long,most of the time is spent on package 
install stage,but most of the bugs are not occurred on packaging install 
stage,can we build a CD which is very similar with LiveCD, but it just 
for install test,only install gnome and other basic packages?By this 
way, we can find anaconda bugs, but the size of this media is less then 
700M. Or we can add this function to LiveCD,there is an option to start 
install on boot stage,not to start install after login desktop like liveCD.
4. The bug maintenance takes lots of time.Can we build a bug report 
instructions about what logs need to attach when report a bug for 
specified component.or this can build to bugzilla? when selected a 
component,some logs/information are recommended to attach to save the 
communication time between the developers and testers. By this way,at 
least some necessary information will not be missing because of the 
carelessness of testers, and the reproduce time will be reduced when 
some necessary information missed

Wishlist :
1. Have more method and more broadcast way to let more people know our 


More information about the fedora-test-list mailing list