On Wednesday, December 22, 2021 11:07:51 PM EST Sandro Tosi wrote: > > It's not an either or. > > > > Generally, the Release Team should coordinate timing of transitions. New > > libraries should be staged in Experimental first. Maintainers of rdpends > > should be alerted to the impending transition so they can check if they > > are ready. > > > > Debian is developed by a team and we should work together to move things > > forward. Particularly for a big transition like numpy, we all need to > > work together to get the work done. > > > > It's true that breakage will happen in unstable. We shouldn't be afraid > > of it, but we should also work to keep it manageable. > let's not get hung up on the details of numpy; what if the package to > update is a small library, with say 20 rdeps, but one of them is llvm > or gcc or libreoffice, and maybe only for their doc. Are we really > asking the maintainer of that library to rebuild all the rdeps, which > can require considerable time, memory and disk space nor readily > available (we can assume the rdeps maintainers have figured out their > resource availability and so they'd be able to rebuild their packages > easily)? > > and lets use once again numpy: 2 days ago i've uploaded 1.21.5 to > replace 1.21.4 in unstable. should i have instead uploaded to > experimental and asked the RT for a transition slot? how do i know if > a transition is required, in this and in all other cases, for all > packages? while only a patch release, there's a non-zero chance there > should be a regresion or an incompatible chance was released with it. > which can only be discovered by rdeps rebuild and so we go back to my > previous mail. For things like major python packages (other languages too), it's not a simple as for C (and to a lesser extent C++) libraries where it's either binary compatible, no so name change, and not a transition, or it isn't. I sympathize, really. I think that for things that are supposed to be backward compatible, uploading to unstable is generally fine. More extensive work is appropriate for larger, more "major" upgrades. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.