-proposed and NotAutomatic ButAutomaticUpgrades

[Michael Casadevall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/15/2012 08:53 AM, Iain Lane wrote:
> Greetings,
> 
> I argued for this at UDS, but we didn't come to a conclusion. I'd
> like to raise this topic again so that we can see whether it is
> wanted it or not.
> 
> I'd like to enable NotAutomatic ButAutomaticUpgrades (as for
> -backports) for the -proposed pocket pre-release (FROZEN or
> DEVELOPMENT). The effect that this would have would be that users
> with devel_release-proposed enabled would not be automatically
> offered upgrades to packages in -proposed. They would still be able
> to explicitly opt-in on a per-package basis (apt-get install
> foo/quantal-proposed, for example), or to opt-in for everything by
> fiddling with package pins.
> 
> We've already reiterated many times that -proposed pre-release is
> not supposed to be something that users (even developers) are
> supposed to be using. It's a staging area for packages, mainly to
> avoid skew and to keep the development release (the release pocket)
> working and installable as far as possible. Thus it seems to me
> that there is little point in imposing the additional irritation of
> dealing with archive problems on users of the development release
> when we don't think they should be using it anyway.
> 
> You could say that people have opted in to the -proposed experience
> by enabling it in their sources list, but what we'd be giving them
> in the development release is very different to what -proposed is
> used for in stable releases, so I don't think it necessarily makes
> sense to say that opting in to stable -proposed implies that you'd
> want the other.
> 
> Another option would be to have the release upgrader disable
> -proposed when upgrading to a development release, but that isn't
> very satisfactory since people with it enabled probably would want
> it back when the release goes stable, and they'd not even have the
> option of cherry-picking packages without having to go and manually
> enable it again.
> 
> It was really quite simple to extend Launchpad for this. I've got
> a branch (not pushed anywhere) that does this, and will submit it
> to Launchpad upstream if there is consensus that this would be
> desirable. (In fact it's protected by a feature flag so it wouldn't
> be harmful to push this now, but would be rather pointless if
> Ubuntu doesn't want it)
> 
> Cheers,
> 
> 
> 
> 

Yet another +1 here (and possibly having apport/whoopies-daisy then
point users to a proposed package should they have a crash post
release if one is available to increase SRU testing)
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP65/sAAoJEHM+GkLSJHY5L48P/3dV4nDga95Z8yJsRbgCqAiu
0+ZWm8Bkb+xXKrK/Zc6Hrm3gZViwpcrJo9VGBl0CGDRysGnI9/bTiFH55doe+KQm
oZjDTKfqk/UsguFquNL+WnV4Cs+wbaTCPsRaFqgu/VBP1ufWr7VvVLt1NeKk+u4M
YrotfTLZJQXB5TAzGHLMqDl8BZj93OtLRS9DDMDkZX0JnIQEgC8mQ1Q9gtUOJd68
5gUyrLnrfiSzyiozwpQEGr6dXPI0/3v7qEUVG8WyhFdB8ShJlujbhwlC3HB6wCsJ
Dw8j6LPe6HwkvMiWEoz5pLayDRm1IWKTBoCYQOZqRLyJYpZWoNpXXRBZcj4a8iTf
Be8f2jR8iyTJcsnIXRza6IQZdL96QYEetbdUBODOKJ6gRBHJh5TUDKRiELyxHr4e
8hYly7pBcm64m9SxHST+g6KBsAzo+zRSAqK4T+lR/7fNVIB6ZHqISyGrLu3yPg3m
6GlhkAdoQRd/V1TTLCMhFzwtI46kQYu2o+80AnSEEE9WiVjqUq3PXPnWmALH5BRQ
QL1Y89GTpz9lawIctJZIle396vqBGTFmqWv4dviJiFSuol9TxcE6EH6QSCq2ItDB
vQ8TSY8/g00eZXxwggOEO6sWHC4yLWUYaabhNoVnxqc5YBIV8Zf5hwqzOPVAxxOU
Wd79syVtdVaDnHRPcMRT
=vHcp
-----END PGP SIGNATURE-----