Re: releasing major library change to unstable without coordination
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
Reply to: