Users are offered updates to packages in -proposed

Per some discussions with LP folks, we'll implement this for statuses and admins can disable/enable whenever they like.

Will implement part of

  https://blueprints.launchpad.net/ubuntu/+spec/other-support-o-sru-process

Bug 800515 and bug 1016454 have been marked as duplicates of this bug report, but this one is specifically about pre-release behavior while the others are not. Either this bug report should be broadened, or the others are not duplicates.

It has been.

Fixed in db-stable r11728 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/11728>.

03/07 13:28:22 <cjwatson> Laney: 2012-07-03 11:19:52 INFO 2209-25-1 applied just now in 0.3 seconds
03/07 13:28:27 <cjwatson> on sourcherry

The column now exists on production.

If anyone is interested in helping testers choose which -proposed updates they have installed, here's a design I prepared earlier. <https://wiki.ubuntu.com/ContributorConsole#updates>

Hi Iain,

I had missed the discussion of this on ubuntu-release, because I didn't realize from the bug title that this was about -proposed for the devel release.

I'm concerned that such a setting for the ${devel}-proposed pocket actively contradicts the purpose of -proposed for devel releases - namely, that it exists *only* for the purpose of ensuring archive consistency, and therefore is only meant to be used for build environments, where we *do* want automatic upgrades to the packages available.

Therefore, from what I can see, users should have -proposed disabled entirely on upgrade to the development series, because they should never be installing packages from -proposed; and build environments which do have -proposed enabled should most definitely get upgrades automatically from -proposed.

How are you expecting this to work for $devel-proposed, as enabled on the launchpad buildds?

I believe that Adam's proposed solution for buildds (bug #888665, which really ought to get fixed soon) is for them to ignore NotAutomatic, which will have the outcome that you desire.

It would be tricky to handle disabling proposed on upgrade to devel release and then re-enabling it for users when the release goes stable, which is what we would want to do since they have opted into testing proposed updates. And not possible for those who upgrade by editing their sources.list.

Having the NotAutomatic flag means that people can choose to take the hit for some particular update if they want to, but then they will be on their own.

Finally, this will be per-series, so you can always choose not to enable it for the devel series and implement whatever other mechanism for disabling proposed for these users. I still would like to see this enabled for those series too though, for the reasons I outlined above.

I plan to stop slacking on implementing this today. :-)

A related thread from January 2021:

https://lists.ubuntu.com/archives/ubuntu-devel/2021-January/041324.html

Mostly done from the Launchpad end of things, but we still need to deploy the launchpad-buildd changes and then make the configuration change to various series.

launchpad-buildd changes deployed; reopening Launchpad task until the actual configuration change is made.

This is now ready to use on the Launchpad side; somebody in ~techboard just needs to set proposed_not_automatic to True on the relevant series using the Launchpad API.