On Mon, 05 Aug 2024 at 09:02:51 +0200, Marc Haber wrote: > On Mon, Aug 05, 2024 at 02:07:54AM +0200, Timo Röhling wrote: > > > If trixie was identified as trixie, and sid was identified as unstable, > > > what compromise would be, er, compromised, precisely? > > Unstable would become less useful at weeding out bugs in packages before > > they reach testing, > > Can you elaborate on that? Why does providing more and better > information make it harder to identify bugs?
I think the concern is somewhere along these lines: * Some package, let's call it foobar, reads os-release and changes its behaviour according to whether it sees trixie/testing or unstable * foobar_1.2-3 is in unstable and works correctly there * The testing migration scripts let it migrate * trixie's os-release is different from unstable's (this is the essence of what Luca is asking for) * Unfortunately, when it sees trixie's os-release, foobar_1.2-3 behaves incorrectly * Now our mechanisms to avoid regressions in testing have failed to prevent a regression, because the regression was never visible to users of unstable, and in fact didn't exist until foobar migrated (All of this assumes the current state, where trixie = testing. The same would be true, with appropriate name changes, during development of forky or later.) That's my understanding of why we try to make unstable as similar as possible to a hypothetical future state of testing, and ideally programmatically indistinguishable - unless you specifically go looking at the apt configuration, at which point you're responsible for looking at the *whole* apt configuration, and not just trying to derive a single suite name from it. A mitigation is that when autopkgtest tests a proposed migration, what it is actually testing is a hypothetical future state of testing where we pretend that this one package and its mandatory dependencies have already migrated, in order to answer the question: if we really allowed this package to migrate, would it break anything? So if foobar has good enough autopkgtest coverage, *that* would stop it migrating - but this is also why it's important that autopkgtests work with the apt configuration that they're given (as Helmut described in more detail in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#278>) instead of figuring out whether they're on testing or unstable and then using that information (and only that information) to construct a test fixture. There is a completely valid trade-off to be made about whether the concern that I've described here (or similar reasons why testing and unstable should be hard to distinguish) is more or less important than the reasons why Luca and others want testing and unstable to be easy to distinguish. That's fine! We make decisions all the time about which option is better, or about which option is less-bad. But I think it's an over-simplification to imply that this is a decision with only valid arguments in one direction, and no valid arguments in the other. When I talk about seeing both sides of a dispute, this is part of what I mean. smcv not a TC member
