Some procedural points, without going into the merits of the technical committee doing as you ask or not:
On Wed, 18 Nov 2020 at 17:33:26 +0000, Matthew Vernon wrote: > I invite the technical committee to rule that: > * The network-manager init script should be restored > * Network-manager should Depend: on default-logind | logind rather than > libpam-systemd This looks like a request to use the technical committee's power to overrule the maintainer of network-manager under section 6.1.4 of the Debian constitution. Is that what you are asking for? This is clearly something that the technical committee is empowered to do, if we choose to do so (which requires a 3:1 majority in favour of overruling the maintainer). > * Similar init-compatibility changes should not be blocked by package > maintainers unless they are defective on their own merits This seems like a broader request, and it's less clear which of the technical committee's powers you are asking us to use. Please could you either clarify what you are asking us to do, or reduce the scope of this request to the issue that you are immediately concerned with, namely network-manager? If what you want on a relatively short timescale is for the maintainer of network-manager to be overruled, and the timing is important to you because of the imminent bullseye freeze, then I would suggest that it might be more expedient to turn this tech-ctte bug report into a request to overrule the network-manager maintainer, and put aside the broader point for now. If that's the case, retitling it to something more like tech-ctte: Overrule network-manager maintainer to apply non-systemd init patches would seem appropriate. As Josh has said elsewhere in the thread, we can give advice (6.1.6), we can decide matters of technical policy (6.1.1), and we can tie-break on technical matters where developers' jurisdictions overlap (6.1.2); but we cannot overrule the views of Debian's membership as a whole, as expressed by GRs. Elsewhere in this thread there has been some dispute over whether it is the TC's place to make this resolution. If we can stop thinking about that question, then it seems to me that we are more likely to be able to answer the other request on the timescale you need. Obviously, when we decide to overrule or not overrule the network-manager maintainer, that can certainly give maintainers of other packages in a similar position a hint as to what the likely outcome would be if there was a request to overrule *them* - but different packages' circumstances are different, so our decision would not necessarily always go the same way. For example, if the maintainers of dbus and gnome-initial-setup chose to make them depend on systemd and you asked the technical committee to overrule both decisions, I suspect we would be more likely to overrule on dbus (because losing dbus would make a lot of packages, uses and high-level features unavailable to those who want to experiment with other init systems), and less likely to overrule on gnome-initial-setup (because that's just one feature). (With dbus maintainer hat on, I do not intend to remove its LSB init script, and I certainly don't intend to remove the init script and then use TC powers to require myself to put it back! :-) It's just an example of a package for which losing non-systemd init support would have a wider impact on users of non-systemd init.) smcv