> 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: > without telling anyone, > > so "communicating" with d-d- c and/or failing autopkgtests..)
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 version of numpy or an already existing/independent cause * provide fixes that are compatible with the current version and the new one (because we cant break what we currently have and we need to prepare for the new version) * wait for all of the packages with issues to have applied the patch and been uploaded to unstable * finally upload to unstable the new version of numpy ? that's unreasonably long, time consuming and work-intensive for several reason * first and foremost 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, do not expect that for any sizable package, but maybe only for the ones with the smallest packages "networks" (which are also the ones causing the less "damage" if something goes wrong), * one maintainer vs many maintainers, one for each affected pkg; distribute the load (pain?) * upload to experimental and use autopkgtests you say? sure that's one way, but tracker.d.o currently doesnt show experimental excuses (#944737, #991237), so you dont immediately see which packages failed, and many packages still dont have autopkgtest, so that's not really covering everything anyway * sometimes i ask Lucas to do an archive rebuild with a new version, but that's still relying on a single person to run the tests, parse the build log, and the open bugs for the failed packages; maybe most of it is automated, but not all of it (and you cant really do this for every pkg in debian, because the archive rebuild tool needs 2 config files for each package you wanna test: 1. how to setup the build env to use the new package, 2. the list of packages to rebuild it that env). what exactly are you expecting from other DDs? unstable is unstable for a reason, breakage will happen, nobody wants to break intentionally (i hope?) others people work/packages, but until we come up with a simple, effective technical solution to the "build the rdeps and see what breaks" issue, we will upload to unstable and see what breaks *right there*. Maybe it's just lazy on my part, but there needs to be a cutoff between making changes/progress and dealing with the consequences, and walking on eggshells every time there's a new upstream release (or even a patch!) and you need to upload a new pkg. i choose making progress Cheers, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi