On 3/15/24 21:52, Paul Gevers wrote:
Hi,
Disclaimer: exception only valid while the time_t transition is ongoing.
On 15-03-2024 6:15 a.m., Steve Langasek wrote:
Migration to testing is largely out of control of the maintainers at this
point, it's very much dependent on folks rebootstrapping armel and armhf
against the new library names. Should these bugs be downgraded again to
important severity?
As I'm normally watching out for out-of-sync packages, I'm fine (with my
Release Team hat on) with maintainers downgrading RC bugs in testing
that have been fixed in unstable and that don't require a quick update
in testing (e.g. security issues probably warrant discussing the tpu
path with the RT). Once time_t 64 bit is done, I'll be filling bugs for
packages that don't migrate again, so the lack of the fix in testing
won't go unnoticed.
For bookkeeping purposes, please usertag downgraded bugs with user
release.debian....@packages.debian.org and usertag time_t-downgrade.
Please be careful with downgrading RC bugs.
Paul
Hi Paul,
I leave this to your own judgement, of course (with your "release team
hat"). But when the AUTORM period was announced as reduced, I thought
like it was probably a bad call, and that the previous AUTORM was
aggressive enough. I didn't dare to express myself about it at the time,
as maybe you knew better. My thinking was: after all, people should fix
their bugs, no? Plus release team people must know better...
But after a few months with the shorter AUTORM period, my opinion is
growing firmer: the previous one (whatever it was) seemed more
appropriate to me with the way Debian is being developed (ie: largely by
volunteers on their free time), and for those of us in charge of
maintaining a long (and sometimes complicated) chain of dependencies.
Now, with this type of (breaking) transition, would growing back the
AUTORM period (to what it used to be) help? Or are you still in the
opinion making it shorter was a good move? Your thoughts?
Cheers,
Thomas Goirand (zigo)
