> 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.
> So you seem to acknowledge that there are people on both sides unreasonably using procedural quirks to impose their view on the majority.
No, I just didn't want to derail the discussion in that direction; my original post was, in isolation, a statement of a problem with proposal H that made it unacceptable to me. That statement is not invalidated with "but the other side ..." arguments.
But since the topic has come up: There are definitely people who favor systemd and say things like "could we just kill sysvinit already", but words aside, I don't see substantial actions that gratuitously hurt sysvinit, rather than just side effects of using things that sysvinit doesn't support. Instead, I see many people just getting their work done by making other software better, and thus as a side effect causing alternatives to fall further behind.
Nobody set out to say "let's make GNOME work exclusively on systemd". They built atop features that systemd had and sysvinit didn't.
When you're trying to stay in permanent maintenance mode, someone doing active development looks like a threat. And when you have a much smaller and community, sometimes most of the people you have left are the extremists.
An interesting alternative to systemd doesn't look like sysvinit, it looks like a better and different solution to people's problems. The proposal that won leaves room for that to happen someday, while not slowing down active development. There'd be some very different conversations going on if, for instance, people were proposing runit as an alternative rather than raw sysvinit, or proposing an inittab.d directory and some helper programs that make inittab.d support inetd-style daemons, or otherwise asking people to include four lines of code to support an alternative rather than hundreds of lines.
> 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.
Nobody's talking about throwing away interfaces and breaking compatibility. On the contrary, systemd still supports init scripts. What we're talking about is not continuing to use the old interface forever because people want to run software that will never support the new interface.
To use an analogy to SONAMEs: a new version of a library can introduce new interfaces without breaking the old ones, that new version will have the same SONAME, and code using the old interfaces will run on the new library, but code using that library's new interfaces won't run on the old library. And that's perfectly acceptable; that allows both sides of an interface to evolve together.
> 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.
1) See above.
2) There's no need for gratuitous insults or contempt culture here. Discussions on this topic already descend into flamewars very easily, let's not push them in that direction.
3) Javascript is still an environment where people have to care deeply about compatibility, both in the provision of interfaces (making sure old Javascript still runs) and in the use of them (making sure multiple browsers work).
4) I work entirely on systems software, and one of the things that happens regularly is introducing and using new interfaces, while carefully preserving compatibility with old interfaces.
> 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.
First of all, there are already such mechanisms, including the technical committee if it comes to that. But I personally don't think it needs to come to that.
If you're approaching this from a mindset of "force a stubborn maintainer", perhaps rethink your mindset. The whole point of option B is that we're not going to force maintainers to work on things they don't have any interest in. So, perhaps show that you can provide compatibility in a minimally invasive way. Perhaps convince a maintainer that you'd be happy to co-maintain the package to handle those bits. And perhaps don't cultivate the kind of personality that makes people want to ignore an entire email thread when they see your name (https://joeyh.name/blog/entry/thread_patterns/), so that people actually want to work with you.
Architectures have a similar tension. Debian supports many different target architectures, and that sometimes requires patching software to help it run on other architectures. People who care about the architecture help write those patches, people who maintain packages include those patches, and Debian occasionally has to decide which architectures are viable for release. There are occasional packages that only run on certain architectures. But for the most part, packages tend to run on every architecture, and architectures don't generate flamewars nearly as often.
But if an architecture came along that, say, didn't support something fundamental like mmap (such targets do exist), and the maintainers of that architecture wanted every package in Debian to do the work to support systems without mmap, that doesn't seem especially likely. In terms of invasiveness, I think that seems more analogous to the work required to support sysvinit.
> In any case, look at the votes.
I did. Per https://vote.debian.org/~secretary/gr_initsystems/ , "Support for multiple init systems is Required" resoundingly lost (below even "Further Discussion"), "Support for multiple init systems is Important" lost to everything else, and all the options submitted by anti-systemd folks lost to all the systemd options. The option that won is the one that allows for something better to come along in the future, which I think is exactly the right balance.
> clearly important to the community as a whole.
The vote demonstrates what is important to the community as a whole. It's a vote for "no, we won't slow down or stand still, but other alternatives are welcome to keep up".
> 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.
Such guidelines were put in place. Nobody on either side is in a position to impose their will on the whole community. The problem is that one side did want the ability to impose their will on the whole community.
> 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.
Remember that the proposal you're quoting was written by sysvinit folks. It only mentions a couple of minor features of systemd that the sysvinit folks are pretty sure they can implement.
I wrote a mail last month with a long list of systemd features people may want to use, along with many of the same points from this discussion: https://lists.debian.org/debian-devel/2019/10/msg00346.html . Please see that whole mail.
Please also see the note in that mail: I'm not trying to say "we should wholeheartedly adopt every one of these technologies"; [...] The issue is that we don't even have the option of considering most of these technologies in the current environment. Even if Policy changed tomorrow to have a full "unless you're using capabilities that alternate init systems don't have" clause, people would still be afraid of using those capabilities or merging patches that do so, lest their work become the subject of a giant flamewar. We should get to a state where people building something interesting using these capabilities and technologies can expect useful feedback, and potentially excitement and collaboration, rather than flames.
I think we need to move past the framing of "people don't want to write init scripts"; this is also about being unable to use a decade of additional capabilities that go far beyond sysvinit.
The net result of the decision years ago was, effectively, "we can use systemd as 'a better sysvinit', but we can't use any capabilities that go substantially beyond sysvinit".
The net result of the decision today is that people can finally start considering the use of capabilities that systemd has, without worrying about the next flamewar.
> doesn't it make sense that such a change should be taken carefully?
Are you under the impression that such a change won't be taken carefully? Such a change just won't be vetoed on the basis of "but sysvinit doesn't have that feature". That doesn't mean that every single feature will be adopted without due consideration.
Debian is typically very careful about compatibility and stability, and holds those as primary virtues, and I have confidence in Debian's continued ability to do so.
> '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?
I have no interest in relitigating this vote. The option that won is the one I consider the correct balance. Rather than handing one group power over the other, it simply says that everyone is free to work on what they want to work on, and to convince others to join them, without giving any special treatment or veto power to sysvinit.