> I wasn't commenting on that here one way or another. I was observing that this would hand one crowd a new weapon, in the form of a mandatory 6-12 month delay.

Right, but the problem is, as you say, there's the "unreasonable" 5-10% on both sides that are using "tactics" to block the other agenda and push their own. Option 'B' basically gives all the power to the pro-systemd crowd, because there's no real mechanism to force a stubborn maintainer to even review a patch tweaking things to work without systemd, much less accept it.

Option 'H', it appears to me to be trying to balance things, such that neither side can actually block things for long. I think that's a much better goal to aim for.

(The text of proposal H is at [1] for those following along.)

> That might have sounded reasonable to the developers of software like sysvinit that doesn't actually change anymore, and is mostly in permanent maintenance mode with its current set of features. It doesn't sound at all reasonable regarding actively developed software.

I'm involved in "actively developing" software, and often come across interfaces that I'd like to just throw away and start over; but instead, we have to make a plan to deprecate the old interface over the course of line 10 years.

That's because systems software is all about compatibility. If you wanted to be able to throw everything away every 6 months you should be writing Javascript.

In any case, look at the votes. Of the 425 people who voted, 116 people favored "Support for multiple init systems is Required" over "Focus on systemd"; and most people voted in favor of some option that allows for init system diversity. Diversity of init systems is clearly important to the community as a whole. It seems to me then that guidelines need to be put in place to prevent extremists on either side from imposing their will on the whole community.

> Many people run the testing or unstable distributions.

Indeed, and many of those people want to be able to not run systemd, for a variety of reasons; and most of the community want to accommodate them, at least at some level.

> That's not what that proposal said. What it said was that if you want to use any new feature, you'd have to ask first, document it in Policy first...

That procedure is in a section which specifically says it's about:

> For example, creating system users or temporary directories. Current Debian approaches are often based on debhelper scripts.

That looks to me like it's not about a dependency on random shiny new features; it's about replacing some core Debian functionality with systemd functionality, in a way which affects all users of the system. Given that system diversity, at least at a basic level, is the goal for most Debian maintainers, doesn't it make sense that such a change should be taken carefully?

So you seem to acknowledge that there are people on both sides unreasonably using procedural quirks to impose their view on the majority.

'H' seems to me very balanced in that regards. You seem to think it's skewed too far towards the non-systemd people. How would you tweak it to make it more balanced?

[1] https://lists.debian.org/debian-vote/2019/11/msg00163.html