Dear Ubuntu Developers, Some members of the SRU team, myself included, have been reluctant to accept SRUs that do not solve any specific problem from a user perspective due to the unnecessary burden this would impose on users. An example of this is an autopkgtest fix.
We wrote this up recently at https://wiki.ubuntu.com/StableReleaseUpdates#When_not_to_upload > Do not upload SRUs for bugs which do not affect users at runtime. If > the bug only manifests on rebuild of the package, the bugfix should > preferably be staged somewhere that it can be included in the next SRU > of the package instead. There is a cost to our users (and our mirror > network) for downloading updates of packages, which should be balanced > against the utility of the update to the user downloading it. We have been trying a new way of staging SRUs not intended to land until a following SRU. The solution is merely to mark relevant SRU bugs with the "block-proposed" tag. The SRU team can then accept the upload into the proposed pocket as usual, but will not release the upload into the updates pocket until the block-proposed tag has been removed. This allows the proposed pocket itself to act as the staging area, ensuring that future uploads are correctly based on it. I expect that any staging will be negotiated between the SRU team and the uploader and documented in the bug and that any change of "block-proposed" tag status in a bug should normally be accompanied with an explanatory comment. As we encounter them, we will probably add to SRU policy a set of classes of SRU bug that will generally always be expected to be staged. If we're staging an upload for some reason that then goes away, please help us by removing the block-proposed tag with an appropriate bug comment when it is ready to land. We have no other means of noticing that a staged SRU needs landing. Finally, please note that it is essential to carry out SRU verification on the bug as usual as soon as it enters proposed because we do not want to burden a future SRUer with verification of your bug. If timely verification is not performed, then as usual the "staged" upload is a candidate for deletion, and a future SRUer is quite entitled to base their upload on the version prior to your staged upload instead. If this happens, the future SRU will not include your changes. Any comments on this plan? If there are no objections, I'll update the wiki page documentation to match. Thanks, Robie
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel