On 9/29/13 2:41 PM, hasufell wrote: > It seems this happens more frequently these days, so I'd like to > remind people to check stable reverse deps before stabilizing a > library, especially when this is a non-maintainer stablereq.
+1 to the reminder. It would be great to hear about specific examples of problems happening more frequently recently. FWIW I didn't notice such tendency, but that doesn't mean it's not happening. > Arch teams do not test them, so this is the business of the maintainer > or the dev who requested stabilization. This is new to me. Do you have anything official to point to so that you could back your claim? See e.g. <http://www.gentoo.org/proj/en/base/x86/arch-testers-faq.xml#steptest>: "If the package is a library, emerge a couple of packages that use the library to ensure they still work with the new version (best option: all that depend on it and have a stable version)." I also created a tool (<http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=blob;f=reverse-dependencies.py;hb=HEAD>) to assist arch teams in testing reverse dependencies. As far as I know the person opening the bug does not guarantee anything. Furthermore, the bugs I've filed using an automated tool explicitly ask for maintainer's opinion before adding arches. They are only filed for packages with no open bugs by the way. The person stabilizing the package is ultimately responsible for breakages - otherwise why would we have dedicated arch teams instead of letting anyone stabilize anything? Paweł
signature.asc
Description: OpenPGP digital signature
