Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: qa-schedule
Packages affected:
Summary
Write a QA schedule that complements the distribution release schedule, noting important milestones in testing and bug management.
Release Note
With a heightened focus on Quality Assurance in the 8.04 cycle we now follow an explicit schedule for all major QA events.
Rationale
The QA schedule is a bit off of the regular development release cycle. For example, we need to triage the high profile bug reports before any freezes so they can be brought to developers attention in time to fix them. Furthermore, we also need to keep looking for bug reports after the final release to identify any bug reports that need are candidates for a Stable Release Update. An explicit schedule would make it easier for the QA and release teams to coordinate their work.
Use Cases
- QA team members use the schedule to structure their work
- Distro team members can easily look up when extended ISO testing will start and how bug triage efforts wll be focused during a given time period
Assumptions
Design
Implementation
- Post the above schedule for wider review
BoF agenda and discussion
- How long should QA be focused on SRU bugs?
- Suggested to have UDS 4-5 weeks into the release cycle for hardy+1 instead of 2 weeks after release, with work on specs beforehand; so some of that time should be used for QA for SRU
- this change would apply to all future releases, not just LTS
- at least until Alpha 1
- demarcation point when you start tracking the showstopper bugs and review them on a weekly basis
- start creating lists of showstopper bugs at feature freeze
- begin tracking these bugs with the availability of first daily builds after feature freeze, before that they won't receive much developer attention
- After this point each showstopper bug should have someone assigned to it
- Kernel showstoppers should be prioritized earlier due to the earlier freeze date
- asking of testing of old 2.6.22 bugs should happen as soon as there is an image with 2.6.24 that people could test without installing
- output of this should be a schedule for the QA team to indicate where there efforts should be focused
- disseminate information regarding the schedule as widely as possible
- e-mails to mailing lists and updating wiki pages regarding focus
- included should be information about when daily image testing starts
- Forwarding bugs upstream should happen with sufficient lead time before the feature freeze: as soon as they're seen to apply to the current version