Release process leaves stable -proposed with broken packages, breaking users who volunteer to test stable -proposed for SRU verification purposes

[Robie Basak]

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).

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.

How can we adjust our release process to stop this happening?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dylan Borg (borgdylan)]

This is due to me having the i386 variant of wine installed on an amd64 system alongside the amd64 packages. These package seem to have changed differently in yakkety causing the upgrade hiccup. I did the necessary changes to allow the upgrade to be complete by manual means.

[Steve Langasek (vorlon)]

Hi Robie,

[corrected the launchpad bug cc]

On Mon, Oct 17, 2016 at 05:57:07PM +0100, Robie Basak 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).

> 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?

I have previously argued that -proposed should be treated the same way as
-backports on end user systems, allowing users to have it enabled and select
specific packages for installation without an apt upgrade pulling everything
from that pocket. While the problem you describe is /worst/ right after a
release has been marked stable, it's not unique to that time of the cycle;
-proposed is always the place where packages sit *before* they are
guaranteed to be coherently installable, so a wholesale upgrade is always
risky. Just as an example, we have had various bug reports in the past
about users who have enabled -proposed, then rendered their systems
unbootable under Secure Boot because they upgraded at just the right moment
for grub-efi-amd64-signed to come uninstalled. This is intrinsic to the
core function of -proposed, and not something that we can shield users from
except by discouraging them from dist-upgrading to -proposed.

I don't think end users should be installing random packages from -proposed
for purposes of fuzz testing of SRUs; it's just not worth the collateral
damage nowadays.

--
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 http://www.debian.org/
<email address hidden> <email address hidden>

[Dylan Borg (borgdylan)]

I suggest disabling the proposed archive during the position disable step during the upgrade.

[Dylan Borg (borgdylan)]

I meant ppa