Re: releasing major library change to unstable without coordination

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 OpenPGP_sign

Re: releasing major library change to unstable without coordination

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 >> (https://git

Re: releasing major library change to unstable without coordination

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 If

Re: releasing major library change to unstable without coordination

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 > n

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 pi

Re: releasing major library change to unstable without coordination

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 versio

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

Re: releasing major library change to unstable without coordination

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 trans

Re: releasing major library change to unstable without coordination

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 consider

Re: releasing major library change to unstable without coordination

> 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 t

Re: releasing major library change to unstable without coordination

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 th

Re: releasing major library change to unstable without coordination

> 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: > witho

Re: releasing major library change to unstable without coordination

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 e

Re: releasing major library change to unstable without coordination

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

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 "unstab