Hi, ... > > I fixed this for Galera now in a quick defensive upload: > > https://tracker.debian.org/news/1762331/accepted-galera-4-26425-3-source-into-unstable/ > > > > It would be nicer though if those FTBFS bugs were not 'severe' and > > less urgent, so that there is time to e.g. import new upstream that > > has this and other fixes included and thus spend overall less > > maintenance work on a single package. > > I already answered to that, but will do again: > > If you want to know in advance that your package will break, you have > to talk with the maintainers of libraries which break other packages, > not to me.
Yes, I know how to test my *own* packages. Moreover I maintain ratt in Debian, which most people use for this, and I mentored the development of reverse dependency build automation in Salsa CI for this kind of testing. What I was trying to explain is that your AUTORM bugs will cause urgent issues for dependant packages (on a Debian scale 3-4 weeks is somewhat urgent) that are not maintained by *different people* than the package that broke builds. .. > But as a QA tester, once that a package fails to build from source in > a release architecture like amd64, the right severity is "serious" > according to both Debian Policy and Release Policy. This might be in accordance with the policy, but I am just explaining the viewpoint of a packager who currently has 3 AUTORM bugs open, even after fixing most of them recently. It feel stressful to get the AUTORM bug reports. Maybe you can do something to alleviate such a feeling, perhaps file bugs with lower severity and wait longer before raising the severity. Even better if there would be some mechanism to put the burden more on the person who uploaded the package that triggered the failure to actually test it (which is nowadays very easy) and not let them "off the hook" that easily and put 100% of the burden on the maintainers of dependent packages. I don't have solution on the top of my mind, just letting you know how it "feels" right now.
