On Sat, Dec 31, 2016 at 04:29:47PM +0100, Francesco Poli wrote:
> Wait, there's something in your line of reasoning that is not clear to
> me.
>
> Some packages were in the following situation:
>
> testing: version x with no RC bugs
> unstable: version y affected by one or more RC bugs
>
> They didn't risk any auto-removal from testing.
> Maybe they risked being part of stretch (as released stable) as version
> x, rather than version y > x. But nothing worse.
>
> Now those packages are in the following situation:
>
> testing _and_ unstable: version y affected by one or more RC bugs
>
> They now risk being auto-removed from testing. If they are indeed
> auto-removed, they won't re-enter stretch and they won't be part of
> stretch (as released stable) at all. Not even as version x...
As you can see from the 2 links I provided in the last email, the
majority of packages that migrated during that broken run were packages
that weren't previously in testing. You can also see that by looking at
graphs like this, where you can see a spike.
https://tests.reproducible-builds.org/debian/testing/amd64/stats_pkg_state.png
I usually account and optimize for the most common case. I acknowledge
what you're saying, but it's not the common case.
> And they do not seem to have one month to get their RC bugs fixed.
> I see that the auto-removals are scheduled for January, the 14th.
Depends on the bug. Somehow I thought most of them would have until the
29th, but apparently that's less than half of them.
396 packages are scheduled for removal the 29th
548 packages are scheduled for removal the 14th
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature