© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
I spoke to Andreas and Renan about this bug just now. I'm told that 32.2 in proposed passes all verification tests against the exceptional test plan except for this bug. But we also need this bug fixed and don't want to have to wait for the additional time a full test rerun would take along with a further ageing period.
If we were to land exceptional SRU from proposed into updates right now, then perform a regular SRU for a 32.3 with this bug fixed, then the second SRU would only require normal SRU verification for the particular fix being applied (test plan to include both the B->F upgrade case and the fresh installation F case, but checking apparmor behaviour only).
Given that exceptional test plan verification against 32.2 is already complete and passed except for this bug, I think that not releasing 32.2 in proposed currently, replacing it with a 32.3, and then SRU-verifying only this bug is equivalent from a QA perspective and therefore acceptable and preferable in this case. We would then be able to release 32.3 to updates as normal.
Plan of action:
1. Update this bug "Where problems could occur" with the specifics that Renan mentioned earlier, and link to this comment to explain what is going on from both this bug and tracking bug 2060732.
2. Complete the Test Plan for this bug to the satisfaction of one SRU team member (Andreas?) treating it as the Test Plan like one would for a regular SRU of this fix only (exercising AppArmor sufficiently for both the B->F upgrade and F fresh install cases and a smoke test to make sure the client still works if not included implicitly in exercising AppArmor is sufficient IMHO; use of automation is fine as always).
3. Complete the verification report for 32.2 in bug 2060732 as normal, except without the final change of the tags since we do not intend to release it.
4. Accept 32.3 into proposed (for all series) to address this bug 2067319. The upload should use -v to include the previous upload as well.
5. The bugs already verified (eg. tracking bug 2060732 but also any others previously verified) can be re-marked as verified with only a link to this comment as explanation (no re-verification required).
6. SRU-verify this bug 2067319 like you would a regular SRU.
7. Release when ready. I also agree that we can skip the ageing period as the only testing expected to be done is by us.