Talk:Fedora 13 Final Release Criteria
From FedoraProject
Contents |
Additional Notes, Thoughts, and Questions
- It would be valuable to work in some bullets that address meeting the needs of the target audience for this release
- What are the needs of the target audience for the Final release?
- What are the distinguishing features of the Final Release?
- How is it different from Alpha and Beta?
- Can we call them out a high level even if the distinguishing differences are in the required test cases.
- Requirements should be more stringent than Alpha, but less so than Final
- What problem is the Final trying to solve?
- How will we decide if the Final Release is a success?
- How good does the Final need to be?
- Do we put the Fedora distribution or project at risk if we don't meet this criterion?
- Do we negatively affect users or others if we don't meet this criterion?
- Make sure all MUST and SHOULD items from [QA/ReleaseCriteria] are integrated into the test plans referenced in the requirements
Feedback
- Bruno: I think the two rescue mode criteria are reversed. I.e. they should be working.
- jlaska - thanks, this should be fixed now
- Bruno: RAID/LVM/dmraid/mdraid are mentioned as needing to work with rescue mode. I think if you are going to be that specific, you should also add luks.
- jlaska - thanks, I've added a note about encryption as well
- Bruno: I don't know if this is covered in the details of some of the listed tests, but does anything specifically need to be done to make sure upgrades work well from Fn-1 and Fn-2? For example a comprehensive check that Obsoletes are provided in all cases they are approiate. Another related case could be making sure no updates are pushed to Fn-1 or Fn-2 that have a version-release higher than what is in the media for some period of time (maybe a week after the release) to make media only upgrades go more smoothly at a time when a lot of people will be doing updates.
- jlaska - Good point. This is currently included in the QA:Fedora_12_Install_Test_Plan, I'm not sure yet whether it's worth stating explicitly on this page.
- Kparal: "18. Menu sanity - the following criteria refer to a live image or default installed system." → "18. Menu sanity - the following criteria refer to a live image and default installed system." ?
- jlaska - thanks, I've made that correction to the wiki
- Kparal: "8. Installer boots and runs on all primary architectures: i686 and x86_64" - But referenced page lists also ppc and ppc64. Should one of the documents be modified?
- jlaska - Good tip, the referenced page has been changed to reflect this.
Open Items
- Bruno: For "The installed system runs normally if the user chooses to install without SELinux." does this mean with selinux disabled? My current understanding is that at least some minimal amount of selinux code needs to be included in an install.
- User:mclasen I think point 12 is a bit of a misuse of 'critical path'. There is nothing in the definition of critical path that makes regressions here more of a problem than elsewhere. And the unqualified use of the term 'regression' here is bound to be a point of contention. Was the removal of polkit-gnome-authorization a regression or a design improvement ?
- Poelstra Re: #16 Where should we document know issues?
