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/
slangasek@ubuntu.com vorlon@debian.org
