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
