Hi, Am 23.12.21 um 10:44 schrieb Timo Röhling: > That's true. However, I think it is reasonable to expect a > maintainer to > * look at the release notes for documented API breakage, > * rebuild a few reverse dependencies (ideally the ones which > exercise the most functionality, but a random pick is probably > fine, too), > * file bugs if you find any issues, and > * monitor the PTS and check for autopkgtest failures, so you can > help figure out (or even fix) what broke. > Full ACK.
And not to deliberately breaking packages (deliberately because he knew it'd break) without any information except a Breaks:. No bug or any info whatsoever the first failure might be an accident, if you point that out and an other upload causes the same failure mode again with adding a silent Breaks: and people only notice because _no direct r-dep_s autopkgtest fails is nothing else then deliberate. I believe if you are maintainer of an important package with many > reverse dependencies, you should spend more time to avoid breakage > because you have a huge lever effect. For instance, if you can cut > corners to save 10 hours of work, but 100 other DDs will need to > spend 30 minutes each to fix the breakage as a result, it is still a > bad tradeoff. > Or the release team will blame the victim of the change (not the maintainer doing that uncoodinated) change for the breakage... Regards, Rene