Proposed pocket racing uninstallability and SRU verification around release time

[Dimitri John Ledkov]

On 17 October 2016 at 18:57, Robie Basak <robie.basak at ubuntu.com> wrote:
> I just filed this bug: https://bugs.launchpad.net/ubuntu/+bug/1634201; I
> Cc'd the bug so as to try and not fragment any discussion.
>
> During development, we have packages in -proposed that fail to migrate,
> as expected, for good reason.
>
> At release time, these packages are still present. For example, Yakkety
> released with libhcrypto4-heimdal:amd64 1.7~git20160703+dfsg-1 in
> proposed, which is not in the release pocket because it is broken (see
> bug 1617963).
>
> I think we should be encouraging users to volunteer to risk testing
> proposed in stable releases. This helps with SRU verification.
>
> However, our current release process breaks these users when they
> upgrade to a new release (which, given that they are testing the cutting
> edge, they are likely to do early, before the proposed pocket has been
> cleaned out).
>

My understanding was that on upgrade -proposed was disabled, and not
re-enabled after the upgrade.

Usually, on release day the release-proposed pocket only has the 0-day SRUs.

However, since introduction of proposed-migration we have been using
-proposed for everything in devel series; and stable releases
-proposed for SRUs.  This does pose a problem on release day, when we
don't have next release name announced. Meaning that on release day,
yakkety-proposed was a mixture of 0day SRUs & things that never
migrated and were to be moved to zesty-proposed. Maybe at final freeze
we should move all packages in -proposed into a Silo, such that in the
final week of a series development series-proposed only has 0day SRUs
and does not have anything that will never migrate. And then on new
series opening copy things back from that stash silo into
zesty-proposed with a hope that next series it will migrate.

We literarly have devel-proposed littered with things, and on release
day people do see those packages even though it has never been
intented to release them.

For example:
https://launchpad.net/ubuntu/+source/jitsi/2.4.4997-1.2ubuntu1/+publishinghistory

Has been stuck in -proposed for 848 days old and it has not met
release criteria since utopic.

Yet, it was published in yakkety-proposed until yesterday, at which
point it was finally deleted from yakkety-proposed as zesty-proposed
is initialised.
However, duing that time it was not an SRU but a broken devel package
that should be stuck in devel.

My argument is that we should just remove these packages that have not
migrated for years. Others in release team say they don't hurt
anything. Yet, they are visible in a stable-proposed when they should
not be. Without launchpad engineering, we could be moving those out of
$stable-proposed into a ppa between release day and next series
initialisation.

> This means that users, instead of being encouraged, are being
> discouraged from testing the SRU proposed pocket since we are breaking
> them with known bugs but delaying removal of those breakages.
>
> Bug 1633653 is an example: a user with xenial-proposed enabled upgraded
> to Yakkety one day after release, and this broke.
>
> How can we adjust our release process to stop this happening?
>
> --
> Ubuntu-release mailing list
> Ubuntu-release at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release



-- 
Regards,

Dimitri.