Setting NotAutomatic for hirsute+1-proposed

[Julian Andres Klode]

Hi people,

I'd like to suggest that we start setting NotAutomatic: yes for the
proposed pocket with hirsute+1, such that things like SRU verification
will be easier, and all those people who enable proposed in sources.list
for I don't know what reasons don't get their systems destroyed as much.

This would obviously require some changes to pin the repo back up on the
builders, but I think it would be useful overall.
--
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

[Robie Basak-4]

Hi Julian,

On Thu, Jan 21, 2021 at 02:15:59AM -0800, Julian Andres Klode wrote:
> I'd like to suggest that we start setting NotAutomatic: yes for the
> proposed pocket with hirsute+1, such that things like SRU verification
> will be easier, and all those people who enable proposed in sources.list
> for I don't know what reasons don't get their systems destroyed as much.
>
> This would obviously require some changes to pin the repo back up on the
> builders, but I think it would be useful overall.

I have no objection, and if it works without UX edge cases then I think
it would be useful to users.

https://wiki.ubuntu.com/Testing/EnableProposed will need a rework
though. We link to that from every SRU bug.

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

[Iain Lane-6]

On Thu, Jan 21, 2021 at 02:15:59AM -0800, Julian Andres Klode wrote:
> Hi people,
>
> I'd like to suggest that we start setting NotAutomatic: yes for the
> proposed pocket with hirsute+1, such that things like SRU verification
> will be easier, and all those people who enable proposed in sources.list
> for I don't know what reasons don't get their systems destroyed as much.
>
> This would obviously require some changes to pin the repo back up on the
> builders, but I think it would be useful overall.

Sounds good to me.

I think the Launchpad support is still missing, although we started on
this several years ago. That will need to be picked up and finished off:

  https://bugs.launchpad.net/launchpad/+bug/1016776

That bug report talks about doing it pre-release (for devel only) but I
think I'm now in favour of doing it always, and the proposed
implementation in there would allow that. For devel, the main reason is
that I frequently come across users who have misunderstood what proposed
is for and manually enabled it themsleves, resulting in various degrees
of brokenness on their systems and bug reports that take developers'
time to triage and eventually close. These are not (always) people who
have updated from a previous release, where we could have had tools
disable -proposed for them, but also people who have explicitly turned
it on after installing a daily out of an attempt to help test the
upcoming release.

On the client side, as Robie says, we will at least need to update
documentation. I'm also not sure what update-manager will do if there
are NotAutomatic updates present. It might need some tweaking to show
them differently. This could be checked by looking at something in
-backports, which is already present with these flags set.

And finally, there's some implication for package builds; both Launchpad
buildds and other builders would need to ignore this. Launchpad does  
this for -backports currently, i.e. -backports builds get Build-Depends
from -backports wholesale; hoepfully that means the buildd side isn't
too hard because we can reuse that.

So yes, let's get this work scheduled if we can. :-)

Cheers,

--
Iain Lane                                  [ [hidden email] ]
Debian Developer                                   [ [hidden email] ]
Ubuntu Developer                                   [ [hidden email] ]

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

[Brian Murray-5]

On Wed, Feb 03, 2021 at 11:12:57AM +0000, Iain Lane wrote:

> On Thu, Jan 21, 2021 at 02:15:59AM -0800, Julian Andres Klode wrote:
> > Hi people,
> >
> > I'd like to suggest that we start setting NotAutomatic: yes for the
> > proposed pocket with hirsute+1, such that things like SRU verification
> > will be easier, and all those people who enable proposed in sources.list
> > for I don't know what reasons don't get their systems destroyed as much.
> >
> > This would obviously require some changes to pin the repo back up on the
> > builders, but I think it would be useful overall.
>
> Sounds good to me.
>
> I think the Launchpad support is still missing, although we started on
> this several years ago. That will need to be picked up and finished off:
>
>   https://bugs.launchpad.net/launchpad/+bug/1016776
>
> That bug report talks about doing it pre-release (for devel only) but I
> think I'm now in favour of doing it always, and the proposed
> implementation in there would allow that. For devel, the main reason is
> that I frequently come across users who have misunderstood what proposed
> is for and manually enabled it themsleves, resulting in various degrees
> of brokenness on their systems and bug reports that take developers'
> time to triage and eventually close. These are not (always) people who
> have updated from a previous release, where we could have had tools
> disable -proposed for them, but also people who have explicitly turned
> it on after installing a daily out of an attempt to help test the
> upcoming release.

Just as a reminder ubuntu-release-upgrader does disable -proposed during
the upgrade to a development release of Ubuntu.

Cheers,
--
Brian Murray

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