Control: tags -1 moreinfo

Hi josch,

On 04-01-2020 22:13, Johannes Schauer wrote:
> yes, I was aware of the introduction of libcrypt, that's why I uploaded 
> 0.5.1-3
> which addresses precisely this change. My naive assumption was, that once
> libcrypt migrates to testing, mmdebstrap would migrate just fine.

True, if you only look at mmdebstrap.

> Thanks a lot for opening this bug report because apparently I have a
> misunderstanding about how our CI and migration work together with automatic
> migration and maybe you can help me clear up my understanding of it? :)

However, there are cases where other packages are blocked due to the
failure of mmdebstrap. Two examples:

The last couple of days: shadow. shadow somehow triggers britney to add
libcrypt from unstable to the set of packages to test, but NOT
mmdebstrap. The test thus has delayed shadow from migration for about 10
days. Hence, tests like this are harmful for others.

Now libcrypt1 migrated, but mmdebstrap did not (due to this bug, hence
downgrading). The old package now fails in testing and that's something
that we consider RC already. However, until the reference test is run,
all packages that run mmdebstrap as test will be believed to cause
regressions.

Now, you can argue that changes to the base chroot are rare. I don't
know but I could take your word for it. However, *if* they happen, like
now, they do cause issues, like for shadow. If the situation prolongs,
it triggers investigation by others that are not familiar with your test
and it would require an overwrite from the release team if the situation
was critical (e.g. shadow needed to migrate fast) or if it would have
taken longer for libcrypt to finally migrate.

Please consider your options carefully. I can live with you choosing to
keep the test, but I think its smarter to not have these kind of tests
as potential gating for migration of other package unless it's really
worth it and rare.

Paul

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to