Re: releasing major library change to unstable without coordination

2021-12-23 Thread Paul Gevers
Hi, On 23-12-2021 15:03, Alexis Murzeau wrote: Isn't ci.debian.net doing automated builds with experimental version of dependencies ? ci.debian.net doesn't do builds except for autopkgtest that have the "needs-build" restriction, which we discourage unless really needed. Paul

Re: releasing major library change to unstable without coordination

2021-12-23 Thread Alexis Murzeau
Hi, Le 23/12/2021 à 14:51, Stéphane Blondon a écrit : > Le jeu. 23 déc. 2021 à 01:25, Sandro Tosi a écrit : > >>> rebuild 500 packages takes hardware resources not >> every dd is expected to have at hand (or pay for, like a cloud >> account), so until there's a ratt-as-as-service >>

Re: releasing major library change to unstable without coordination

2021-12-23 Thread Stéphane Blondon
Le jeu. 23 déc. 2021 à 01:25, Sandro Tosi a écrit : > > rebuild 500 packages takes hardware resources not > every dd is expected to have at hand (or pay for, like a cloud > account), so until there's a ratt-as-as-service > (https://github.com/Debian/ratt) kinda solution available to every DD

Re: releasing major library change to unstable without coordination

2021-12-23 Thread Rene Engelhard
Hi, Am 23.12.21 um 01:24 schrieb Sandro Tosi: > there's also a problem of resources: let's take the example of numpy, > which has 500+ rdeps. am i expected to: > > * rebuild all its reverse dependencies with the new version > * evaluate which packages failed, and if that failures is due to the >

Re: releasing major library change to unstable without coordination

2021-12-23 Thread Rene Engelhard
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

Re: releasing major library change to unstable without coordination

2021-12-23 Thread Timo Röhling
Hi Sandro! * Sandro Tosi [2021-12-22 19:24]: there's also a problem of resources: let's take the example of numpy, which has 500+ rdeps. am i expected to: * rebuild all its reverse dependencies with the new version * evaluate which packages failed, and if that failures is due to the new

Re: releasing major library change to unstable without coordination

2021-12-23 Thread Paul Gevers
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

Re: releasing major library change to unstable without coordination

2021-12-22 Thread Scott Kitterman
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

Re: releasing major library change to unstable without coordination

2021-12-22 Thread Niels Thykier
Sandro Tosi: > and lets use once again numpy: 2 days ago i've uploaded 1.21.5 to > replace 1.21.4 in unstable. [...] > > Regards, Hi, If you feel discussing patch releases is worth a topic of its own, I think we should start a separate thread for that because the process is likely to be

Re: releasing major library change to unstable without coordination

2021-12-22 Thread Sandro Tosi
> 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

Re: releasing major library change to unstable without coordination

2021-12-22 Thread Scott Kitterman
On December 23, 2021 12:24:16 AM UTC, Sandro Tosi wrote: >> People are expected to do so (coordination/testing etc). >> >> >> - Mistakes happen. >> >> >> BUT: >> >> >> - Apparently some people forgot this and deliberately don't follow (and >> I don't mean the can-happen accidents). >> >> (In

Re: releasing major library change to unstable without coordination

2021-12-22 Thread Sandro Tosi
> People are expected to do so (coordination/testing etc). > > > - Mistakes happen. > > > BUT: > > > - Apparently some people forgot this and deliberately don't follow (and > I don't mean the can-happen accidents). > > (In the speficic case I have in mind the maintainer just added a Breaks: >

Re: releasing major library change to unstable without coordination

2021-12-22 Thread Rene Engelhard
Hi, Am 23.12.21 um 00:45 schrieb Jonas Smedegaard: > 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? People are

Re: releasing major library change to unstable without coordination

2021-12-22 Thread Samuel Thibault
Jonas Smedegaard, le jeu. 23 déc. 2021 00:45:23 +0100, a ecrit: > 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?

releasing major library change to unstable without coordination

2021-12-22 Thread Jonas Smedegaard
Hi fellow developers, 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? Sure, accidents happen - but do the label