[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: releasing major library change to unstable without coordination



Hi,

[I've read the rest of the thread so far, answering the transition question].

On 23-12-2021 00:45, Jonas Smedegaard wrote:
Is it normal and ok to upload a new major release of a library to
unstable, without either a) testing that reverse dependencies do not
break, or b) coordinating with maintainers of reverse dpendencies
_before_ such upload?

What we (the Release Team) expects/hopes for is documented on the wiki [1]. A lot of the page is also valid for uploads that are known, expected or suspected to be intrusive. In case of doubt, please always coordinate with the Release Team (but don't overdo your doubt ;)). To answer your question, most people do what you expect, but not all.

We (again, the Release Team) don't expect maintainers of libraries/core packages to fix all regressions caused by their uploads. What we do expect is communication. Either a plain warning (well) in advance (easy, but less effective) or by uploading to experimental, checking reverse (test) dependencies and filing (important) bugs, which are raised to serious once the upload to unstable happens. In either case, when breakage is expected, please give your reverse dependency some time to prepare to not have their package instantly RC buggy. Maybe an interesting note to all, if the bug has already aged at lower severity, the autoremoval counter starts counting immediately once the bug is raised to serious.

The main point from my message may be: if we break unstable too much, we may not be able to have packages migrate to testing, because it gets harder and harder to find sets that are ready together.

Having all that said, unstable is unstable. Expect breakage there. But I hope we can try to avoid unannounced large breakage when the breakage is expected.

Paul

[1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: