Hi Steve, Thanks for your feedback, CC-ing in the Release Team, because it's their policy [1].
On 26-11-2020 00:37, Steve Langasek wrote: > It seems quite counterintuitive that this bug would be marked as closed in > unstable, given that it's the unstable version which fails to build? Yes, I could improve my template generation for these kind of cases. But to my defense, after the initial round of bugs where I didn't do this, there was some push back to the potential additional administration. This was the best approach to solve the overhead for maintainers where the out-of-sync issue could be resolved without an upload of the source. But for cases where the issue can most likely only be solved by an upload of the source, I should not close it. I regularly removed those parts manually from my template now, but sometimes it slips. > And also, it seems counterintuitive to auto-remove the testing version of > the package due to a regression in buildability in the unstable version... The rationale for that is given in the bug message: """ If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. """ We give the maintainer 60 days to solve the issue before filing this bug. In our opinion that aught to be enough. Autoremoval has additional tolerances, so the out-of-sync issue will only be resolved by autoremoval when the package doesn't migrate for at least 90 days. If you have an improvement proposal for the current way of working (which is semi-automated), we'd like to hear it, but several Release Team members have expressed their appreciation that this class of issues is handled now. The list [1] is so much shorter than it used to be, and several problematic cases have surfaced and have been handled due to this process that seemed to be stalled. Obviously we're not married with the current solution, it's the out-of-sync issue we want to resolve in a reasonable and maintainable way. Paul [1] https://udd.debian.org/dev/bugs.cgi?release=bullseye&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=out-of-sync&fusertaguser=release.debian.org%40packages.debian.org&rc=1&ckeypackage=1&clastupload=1&cautormtime=1&sortby=lastupload_s&sorto=asc&format=html#results
signature.asc
Description: OpenPGP digital signature
