Hi Matthias, On 27-01-2021 22:42, Matthias Klose wrote: > I have been following the way the linux source package was uploaded. Apparently > the package entered unstable with just an announcement like this. And more than > one time. For linux there was alignment, but see below. >> So, can you please clarify why you think these changes are needed? What >> are the risks of including or not including these changes? How are the >> risks mitigated? > > staging in experimental is not possible, unless you remove 2.36, or override it > bumping the epoch. (or a +really version number). > - PR27218 is an obvious bug fix, avoiding a segfault. > - DWARF5 is not enabled by default, the DWARF5 fixes are > required for GCC 11 defaulting to use DWARF5. And no, > I'm not planning to upload gcc-11 to unstable. > > I'm very unhappy about the private decision making for some uploads, while > showing a pedantic attitude towards others. I must confess that indeed the alignment with the Release Team on linux uploads happened in private. It shouldn't have, or at least the outcome should have been public. > - PR27218 is an obvious bug fix, avoiding a segfault. Sound OK to have. > - DWARF5 is not enabled by default, the DWARF5 fixes are > required for GCC 11 defaulting to use DWARF5. https://release.debian.org/britney/pseudo-excuses-experimental.html#binutils (for 2.36-1) shows a regression for glibc. Hence we're not totally confident. If it's not the default, why do we want this feature now? We would be happy with either of the following: 1) upload to unstable with PR27218 only 2) upload to experimental first (with a 2.36+really2.35.2 version) to check all is fine. > Not so kind regards, Matthias It saddens me to read this. Still with kind regards, Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature