Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
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
Reply to: