Staging changes for future SRU landings

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Staging changes for future SRU landings

Robie Basak-4
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

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Matthias Klose-6
On 28.08.19 19:32, Robie Basak wrote:
> Any comments on this plan? If there are no objections, I'll update the
> wiki page documentation to match.

afaiu block-proposed tags on bugs are not specific to any series, so you are
blocking updates across all series. Not really desired.

Matthias

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Julian Andres Klode
In reply to this post by Robie Basak-4
On Wed, Aug 28, 2019 at 06:32:13PM +0100, Robie Basak wrote:
> 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.

Does this work sensibly, though? AFAIUI, the tools will set the bug
back to verification once you upload a follow up (at least if you
pass -v<version in -updates> to dpkg-buildpackage, which IIRC is
kind of expected, as otherwise bug closure emails end up weird).

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Colin Watson
In reply to this post by Matthias Klose-6
On Wed, Aug 28, 2019 at 07:41:10PM +0200, Matthias Klose wrote:
> On 28.08.19 19:32, Robie Basak wrote:
> > Any comments on this plan? If there are no objections, I'll update the
> > wiki page documentation to match.
>
> afaiu block-proposed tags on bugs are not specific to any series, so you are
> blocking updates across all series. Not really desired.

block-proposed is in fact specific to the current development series.
block-proposed-$SERIES exists and should work here, though.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Julian Andres Klode
On Thu, Aug 29, 2019 at 03:59:04AM +0100, Colin Watson wrote:

> On Wed, Aug 28, 2019 at 07:41:10PM +0200, Matthias Klose wrote:
> > On 28.08.19 19:32, Robie Basak wrote:
> > > Any comments on this plan? If there are no objections, I'll update the
> > > wiki page documentation to match.
> >
> > afaiu block-proposed tags on bugs are not specific to any series, so you are
> > blocking updates across all series. Not really desired.
>
> block-proposed is in fact specific to the current development series.
> block-proposed-$SERIES exists and should work here, though.

block-proposed seems to work across all series. look at

https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1813581

and

https://people.canonical.com/~ubuntu-archive/pending-sru.html

and you see the blocked icon for the bionic SRU, but the bug
has block-proposed set, not block-proposed-bionic.


--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Colin Watson-3
On Thu, Aug 29, 2019 at 10:33:37AM +0200, Julian Andres Klode wrote:

> On Thu, Aug 29, 2019 at 03:59:04AM +0100, Colin Watson wrote:
> > On Wed, Aug 28, 2019 at 07:41:10PM +0200, Matthias Klose wrote:
> > > afaiu block-proposed tags on bugs are not specific to any series, so you are
> > > blocking updates across all series. Not really desired.
> >
> > block-proposed is in fact specific to the current development series.
> > block-proposed-$SERIES exists and should work here, though.
>
> block-proposed seems to work across all series. look at
>
> https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1813581
>
> and
>
> https://people.canonical.com/~ubuntu-archive/pending-sru.html
>
> and you see the blocked icon for the bionic SRU, but the bug
> has block-proposed set, not block-proposed-bionic.

Sounds like there's a disagreement between proposed-migration and
sru-report.

--
Colin Watson                                    [[hidden email]]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Lukasz Zemczak
Currently sru-report shows the block icon for both block-proposed and
block-proposed-SERIES. Seeing that block-proposed is indeed
devel-specific, I think it makes sense for us to only block SRU
uploads on the -SERIES tag. I can switch that in a moment if there's
an agreement on that in the SRU team.

If we +1 on that, I'll make sure to add the SERIES tags to all current
block-proposed SRU uploads that should be blocked for the given series
in the -proposed pockets.

Cheers,

On Thu, 29 Aug 2019 at 10:48, Colin Watson <[hidden email]> wrote:

>
> On Thu, Aug 29, 2019 at 10:33:37AM +0200, Julian Andres Klode wrote:
> > On Thu, Aug 29, 2019 at 03:59:04AM +0100, Colin Watson wrote:
> > > On Wed, Aug 28, 2019 at 07:41:10PM +0200, Matthias Klose wrote:
> > > > afaiu block-proposed tags on bugs are not specific to any series, so you are
> > > > blocking updates across all series. Not really desired.
> > >
> > > block-proposed is in fact specific to the current development series.
> > > block-proposed-$SERIES exists and should work here, though.
> >
> > block-proposed seems to work across all series. look at
> >
> > https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1813581
> >
> > and
> >
> > https://people.canonical.com/~ubuntu-archive/pending-sru.html
> >
> > and you see the blocked icon for the bionic SRU, but the bug
> > has block-proposed set, not block-proposed-bionic.
>
> Sounds like there's a disagreement between proposed-migration and
> sru-report.
>
> --
> Colin Watson                                    [[hidden email]]
>
> --
> ubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



--
Ɓukasz 'sil2100' Zemczak
 Foundations Team
 [hidden email]
 www.canonical.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Robie Basak-4
In reply to this post by Julian Andres Klode
Thank you everyone for the feedback.

On Wed, Aug 28, 2019 at 07:41:10PM +0200, Matthias Klose wrote:
> afaiu block-proposed tags on bugs are not specific to any series, so you are
> blocking updates across all series. Not really desired.

Following the thread you started, it seems that we can all agree to use
block-proposed-<series> instead. Does this resolve your concern?

On Wed, Aug 28, 2019 at 09:24:10PM +0200, Julian Andres Klode wrote:
> Does this work sensibly, though? AFAIUI, the tools will set the bug
> back to verification once you upload a follow up (at least if you
> pass -v<version in -updates> to dpkg-buildpackage, which IIRC is
> kind of expected, as otherwise bug closure emails end up weird).

This is a good point. If we adjusted the tooling to avoid reopening the
bug for verification in this case, would this resolve your concern?

It looks like the logic is here:
https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/sru_workflow.py#L76

The new logic might be: if the bug (has blocked-proposed-<series>) and
(verification-done or verification-done-<series> for the series being
accepted) and (doesn't have verification-failed or
verification-failed-<series> for the series being accepted), then do not
reset the tag for that series at accept time. Are there any edge cases I
haven't considered? Alternative suggestions appreciated.

Robie

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Rafael David Tinoco-3

>> afaiu block-proposed tags on bugs are not specific to any series, so you are
>> blocking updates across all series. Not really desired.
> Following the thread you started, it seems that we can all agree to use
> block-proposed-<series> instead. Does this resolve your concern?
>
> On Wed, Aug 28, 2019 at 09:24:10PM +0200, Julian Andres Klode wrote:
>> Does this work sensibly, though? AFAIUI, the tools will set the bug
>> back to verification once you upload a follow up (at least if you
>> pass -v<version in -updates> to dpkg-buildpackage, which IIRC is
>> kind of expected, as otherwise bug closure emails end up weird).
> This is a good point. If we adjusted the tooling to avoid reopening the
> bug for verification in this case, would this resolve your concern?
>
> It looks like the logic is here:
> https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/sru_workflow.py#L76
>
> The new logic might be: if the bug (has blocked-proposed-<series>) and
> (verification-done or verification-done-<series> for the series being
> accepted) and (doesn't have verification-failed or
> verification-failed-<series> for the series being accepted), then do not
> reset the tag for that series at accept time. Are there any edge cases I
> haven't considered? Alternative suggestions appreciated.
>
Robie, using a real example now:

https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1849342

Its a FTBS for Disco on Libvirt. I'm assigning this to Christian, who
will likely add to this notes as he is the maintainer. But lets suppose
there was no particular maintainer. I would tag this bug as
"block-proposed-disco".

Would the uploader have to manually check for bugs with that tag before
finishing the next SRU ? Would he discover only when migration failed
after SRU was already uploaded and accepted, lets say ?


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Steve Langasek-6
On Tue, Oct 22, 2019 at 12:30:34PM -0300, Rafael David Tinoco wrote:

> > > afaiu block-proposed tags on bugs are not specific to any series, so you are
> > > blocking updates across all series. Not really desired.
> > Following the thread you started, it seems that we can all agree to use
> > block-proposed-<series> instead. Does this resolve your concern?

> > On Wed, Aug 28, 2019 at 09:24:10PM +0200, Julian Andres Klode wrote:
> > > Does this work sensibly, though? AFAIUI, the tools will set the bug
> > > back to verification once you upload a follow up (at least if you
> > > pass -v<version in -updates> to dpkg-buildpackage, which IIRC is
> > > kind of expected, as otherwise bug closure emails end up weird).
> > This is a good point. If we adjusted the tooling to avoid reopening the
> > bug for verification in this case, would this resolve your concern?

> > It looks like the logic is here:
> > https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/sru_workflow.py#L76

> > The new logic might be: if the bug (has blocked-proposed-<series>) and
> > (verification-done or verification-done-<series> for the series being
> > accepted) and (doesn't have verification-failed or
> > verification-failed-<series> for the series being accepted), then do not
> > reset the tag for that series at accept time. Are there any edge cases I
> > haven't considered? Alternative suggestions appreciated.

> Robie, using a real example now:

> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1849342

> Its a FTBS for Disco on Libvirt. I'm assigning this to Christian, who will
> likely add to this notes as he is the maintainer. But lets suppose there was
> no particular maintainer. I would tag this bug as "block-proposed-disco".

> Would the uploader have to manually check for bugs with that tag before
> finishing the next SRU ? Would he discover only when migration failed after
> SRU was already uploaded and accepted, lets say ?

It is the responsibility of the SRU uploader to base their upload on the
current state of the archive at the time; so they should not be unaware that
there is a previous version in -proposed which their upload needs to base
on.  And I think in principle the block-proposed tag should be removed by
the SRU team member when accepting the newer, non-proposed-only upload.  But
if they overlook this, it's appropriate for whoever notices it (SRU team, or
uploader) to remove the block-proposed-$series tag when it no longer
applies.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
[hidden email]                                     [hidden email]

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Staging changes for future SRU landings

Robie Basak-4
In reply to this post by Robie Basak-4
Discussion seems to have concluded on this thread, and I've seen quite a
bit of use of the block-proposed-<series> tag now.

We (the SRU team) decided to continue with this feature, so I've
adjusted the SRU documentation to match:

Policy:
https://wiki.ubuntu.com/StableReleaseUpdates#Staging_low_priority_uploads

I think this section can probably grow over time to document common
cases and general decisions as we develop more experience over this.

Procedure:
https://wiki.ubuntu.com/StableReleaseUpdates#Staging_an_upload

I think all concerns in this thread have been addressed. If you think
anything needs adjusting, I'd appreciate the feedback.

Thanks,

Robie

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment