[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?



Hi,

On 29/11/2020 16:59, Simon McVittie wrote:
Some procedural points, without going into the merits of the technical
committee doing as you ask or not:

Broadly, I expect the TC to know their procedural stuff better than I do, but I'll try and answer your points :)

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?

Yes, I think so; I mean, you might also decide that this is a matter where jurisdictions overlap (between the init diversity folk and the network-manager maintainers), and I wouldn't think that unreasonable.

* 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?

I'm not going to answer this directly, but instead try and explain what I was hoping to achieve - as you say (in text I've snipped), there are a number of ways you might wish to address this question.

Let us beg the question for the moment, and suppose you agree with me that the changes I outline should be made to network-manager. Suppose further that there are other packages where fundamentally the same question arises between now and the bullseye freeze (this isn't a hypothetical; there are). I would suggest that it's not in anyone's interests for each bug report to have to come before the TC in turn (I think this is obviously true, but can justify this if you like).

To that end, you might want to say something about the more general case at least in period leading to the bullseye release, whether that's expressed as deciding a matter of policy or giving advice. If that's a longer decision-making process, I don't see why you couldn't say "The TC rules on the request to overrule thus; and will say more on the matter hereafter" and then say something more general later.

I don't think any statement of this kind would be overriding the GR - as I said in my initial bug report, I think the GR supports what I'm trying to achieve here (pace Josh).

To briefly address the question on network-managers utility raised elsewhere: I think it is true both that there are many systems where it is roughly essential (portable devices - nothing else comes close from a managing multiple networks POV), and also classes of systems where being able to install GNOME without it is clearly desirable (desktop systems with complex but stable networking where ifupdown or netplan are more appropriate).

Regards,

Matthew


Reply to: