Staging changes for future SRU landings

[Robie Basak]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20190828/1a9e9b47/attachment.sig>