Re: proposed-migration, "SMOOTH_UPDATES", and NBS reports
On Fri, Mar 04, 2022 at 08:58:03AM +1300, Michael Hudson-Doyle wrote: > On Thu, 9 Dec 2021 at 05:42, Julian Andres Klode > wrote: > > On Wed, Dec 08, 2021 at 05:29:19PM +0100, Sebastien Bacher wrote: > > > Hey again, > > > Le 08/12/2021 à 00:14, Steve Langasek a écrit : > > > > I expect that with this option set, we will find much fewer problems > > > > with entanglement of library transitions, and in turn I hope > > > > developers will be less frustrated by migration delays. > > > Right, I expect that to be the case. It's going to come at the cost > > > of reducing the pressure for the team to complete the transitions > > > since that's not going to get in the way of having their updates to > > > land. My personal feeling is that it's going to turn out to be an > > > issue for the archive and the release teams and that we aren't going > > > to find proper staffing to deal with the problems, but hopefully I'm > > > wrong there, we will see. > > I think we should > > - disable smoothing at feature freeze > So we're now a little past feature freeze and smooth_updates is still in > effect. This made the recent python/perl/the world transition a bit easier > so that was probably a good thing overall but now that's behind us, maybe > we should disable it now? FWIW I didn't respond to this at the time because I expect this to have low impact in practice. It would be exceptional for a transition to start after feature freeze, and transitions that were already in progress prior to the freeze but not completed are usually ones that we want to finish before the release - for which smooth updates are still a benefit. Weighed against the cost of another place that we have to make a config change every time we reach feature freeze, I would prefer to leave the current policy intact. Also, since this thread began, we've also limited the smooth updates to only apply to packages in the libs and oldlibs sections, which should further limit any collateral damage. Do you all think this is ok as a path forward? > > - work on getting NBS to 0 by beta freeze > So this becomes less of a whackamole. > > If it doesn't work, maybe we need to revert to not autosmoothing > > and force or add a smooth hint. -- 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 https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposed-migration, "SMOOTH_UPDATES", and NBS reports
+1 Michael Hudson-Doyle schrieb am Do., 3. März 2022, 20:58: > On Thu, 9 Dec 2021 at 05:42, Julian Andres Klode < > julian.kl...@canonical.com> wrote: > >> On Wed, Dec 08, 2021 at 05:29:19PM +0100, Sebastien Bacher wrote: >> > Hey again, >> > >> > Le 08/12/2021 à 00:14, Steve Langasek a écrit : >> > > I expect that with this option set, we will find much fewer problems >> with >> > > entanglement of library transitions, and in turn I hope developers >> will be >> > > less frustrated by migration delays. >> > Right, I expect that to be the case. It's going to come at the cost of >> > reducing the pressure for the team to complete the transitions since >> that's >> > not going to get in the way of having their updates to land. >> > My personal feeling is that it's going to turn out to be an issue for >> the >> > archive and the release teams and that we aren't going to find proper >> > staffing to deal with the problems, but hopefully I'm wrong there, we >> will >> > see. >> >> I think we should >> >> - disable smoothing at feature freeze >> > > So we're now a little past feature freeze and smooth_updates is still in > effect. This made the recent python/perl/the world transition a bit easier > so that was probably a good thing overall but now that's behind us, maybe > we should disable it now? > > >> - work on getting NBS to 0 by beta freeze >> > > So this becomes less of a whackamole. > > Cheers. > mwh > > >> If it doesn't work, maybe we need to revert to not autosmoothing >> and force or add a smooth hint. >> -- >> debian developer - deb.li/jak | jak-linux.org - free software dev >> ubuntu core developer i speak de, en >> >> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposed-migration, "SMOOTH_UPDATES", and NBS reports
On Thu, 9 Dec 2021 at 05:42, Julian Andres Klode wrote: > On Wed, Dec 08, 2021 at 05:29:19PM +0100, Sebastien Bacher wrote: > > Hey again, > > > > Le 08/12/2021 à 00:14, Steve Langasek a écrit : > > > I expect that with this option set, we will find much fewer problems > with > > > entanglement of library transitions, and in turn I hope developers > will be > > > less frustrated by migration delays. > > Right, I expect that to be the case. It's going to come at the cost of > > reducing the pressure for the team to complete the transitions since > that's > > not going to get in the way of having their updates to land. > > My personal feeling is that it's going to turn out to be an issue for the > > archive and the release teams and that we aren't going to find proper > > staffing to deal with the problems, but hopefully I'm wrong there, we > will > > see. > > I think we should > > - disable smoothing at feature freeze > So we're now a little past feature freeze and smooth_updates is still in effect. This made the recent python/perl/the world transition a bit easier so that was probably a good thing overall but now that's behind us, maybe we should disable it now? > - work on getting NBS to 0 by beta freeze > So this becomes less of a whackamole. Cheers. mwh > If it doesn't work, maybe we need to revert to not autosmoothing > and force or add a smooth hint. > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposed-migration, "SMOOTH_UPDATES", and NBS reports
On Wed, Dec 08, 2021 at 05:29:19PM +0100, Sebastien Bacher wrote: > Hey again, > > Le 08/12/2021 à 00:14, Steve Langasek a écrit : > > I expect that with this option set, we will find much fewer problems with > > entanglement of library transitions, and in turn I hope developers will be > > less frustrated by migration delays. > Right, I expect that to be the case. It's going to come at the cost of > reducing the pressure for the team to complete the transitions since that's > not going to get in the way of having their updates to land. > My personal feeling is that it's going to turn out to be an issue for the > archive and the release teams and that we aren't going to find proper > staffing to deal with the problems, but hopefully I'm wrong there, we will > see. I think we should - disable smoothing at feature freeze - work on getting NBS to 0 by beta freeze If it doesn't work, maybe we need to revert to not autosmoothing and force or add a smooth hint. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposed-migration, "SMOOTH_UPDATES", and NBS reports
Hey again, Le 08/12/2021 à 00:14, Steve Langasek a écrit : I expect that with this option set, we will find much fewer problems with entanglement of library transitions, and in turn I hope developers will be less frustrated by migration delays. Right, I expect that to be the case. It's going to come at the cost of reducing the pressure for the team to complete the transitions since that's not going to get in the way of having their updates to land. My personal feeling is that it's going to turn out to be an issue for the archive and the release teams and that we aren't going to find proper staffing to deal with the problems, but hopefully I'm wrong there, we will see. Cheers, Sebastien -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposed-migration, "SMOOTH_UPDATES", and NBS reports
Hi Seb, On Tue, Dec 07, 2021 at 10:56:09PM +0100, Sebastien Bacher wrote: > Hey Steve, > Thanks for the email explaining the change, I've some questions > Le 07/12/2021 à 07:56, Steve Langasek a écrit : > > The flipside is that this now means more packages will make it to the > > release pocket while there are still reverse-dependencies of an old library > > name; so when folks are working on proposed-migration, such as for +1 > > Maintenance, more attention will need to be paid to cleaning up these > > stragglers. > So you started by stating the change has been made to help on the openssl3 > transition, it's a bit unclear to me if you mean it as a temporary thing or > if you are suggesting that configuration to stay the default going forward? Unblocking openssl was the impetus, but my intention is to keep this new configuration permanently unless we see that it's causing problems. As I outlined in my mail, this configuration is already in principle what we have as a policy for retention of old binary packages in the release pocket, it's just that without this configuration option the implementation was inconsistent. I expect that with this option set, we will find much fewer problems with entanglement of library transitions, and in turn I hope developers will be less frustrated by migration delays. > If the option is the proposed new default, what's the position of the > release team on having NBS binaries around for the release? I guess that in > principle we would want to clean that report, but in practice if we don't > enforce that at proposed migration and lower the pressure to get those > things resolved it's likely that we end building up debts we don't manage to > pay. Yes, the position on NBS packages in the release hasn't changed - I expect us to zero out this list before release. That's why I'm asking for people to start paying attention to the report on an ongoing basis, to minimize the amount of work that gets backed up to the end of the cycle. We did already have NBS packages in the release pocket before, and driving the list to zero has remained manageable. I'm not sure how much work other folks have put into keeping the list under control - it's the kind of work that's invisible and thankless :) - I have personally paid attention to it quite a lot over the past few cycles and it hasn't been too much to keep up with. So I'm hoping just having folks more broadly aware of this will be enough to organically keep the backlog under control. If not, I will be sure to escalate well before the end of the jammy cycle :) Cheers, -- 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 https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposed-migration, "SMOOTH_UPDATES", and NBS reports
Hey Steve, Thanks for the email explaining the change, I've some questions Le 07/12/2021 à 07:56, Steve Langasek a écrit : The flipside is that this now means more packages will make it to the release pocket while there are still reverse-dependencies of an old library name; so when folks are working on proposed-migration, such as for +1 Maintenance, more attention will need to be paid to cleaning up these stragglers. So you started by stating the change has been made to help on the openssl3 transition, it's a bit unclear to me if you mean it as a temporary thing or if you are suggesting that configuration to stay the default going forward? If the option is the proposed new default, what's the position of the release team on having NBS binaries around for the release? I guess that in principle we would want to clean that report, but in practice if we don't enforce that at proposed migration and lower the pressure to get those things resolved it's likely that we end building up debts we don't manage to pay. Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
proposed-migration, "SMOOTH_UPDATES", and NBS reports
As part of getting openssl 3 to migrate into the release pocket without waiting for everything in the world to be rebuilt to drop its dependency on libssl1.1, I've made a change to the config of britney to enable what are called "smooth updates": explicitly telling britney that it's ok to keep old (no-longer-built) binary packages around in the release pocket when updating a source package. In fact, the way britney interfaces with launchpad, it's always the case that old binary packages are left behind in the release pocket and have to be cleaned up by hand; so by explicitly instructing britney that it's ok for them to be left around, britney will more quickly calculate that a source package is ready to go to the release pocket, improving development velocity overall. The flipside is that this now means more packages will make it to the release pocket while there are still reverse-dependencies of an old library name; so when folks are working on proposed-migration, such as for +1 Maintenance, more attention will need to be paid to cleaning up these stragglers. We have always had an "NBS" (not built from source) report showing us when this is the case, it's just that with the new configuration there are going to be more such packages needing more attention to clear the reverse-dependencies: https://people.canonical.com/~ubuntu-archive/nbs.html In some cases these are packages that simply need no-change reuploads in order to build against the new library package name, but in other cases the packages have been rebuilt but are stuck for one reason or another in -proposed. So please pay attention to this list when you're working on -proposed; you should find that the change makes proposed-migration run faster overall, but we still need to make sure we're following through on cleaning up old binaries afterwards. Thanks, -- 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 https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
