4 ms·

> the anti-systemd crowd has demonstrated repeatedly that they'll use any weapon to slow down systemd usage, which means in practice every single new mechanism

• JoshTriplett 7y ago
  > The same sort of thing is described on the pro-systemd crowd. 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. (In general, I think the vast majority of the pro-systemd crowd is not interested in actively killing alternatives; they're just interested in actually using features that other alternatives don't have. Problems and disputes certainly happen, as well as people getting frustrated or burnt out trying to deal with the constant battles, as well as people just trying to get things done.) (I also think many of the anti-systemd crowd is just interested in trying to maintain what they care about, but that in practice it's become evident that "keep up" would require than the available development resources, while the far more acrimonious "slow others down" requires less. I suspect it's a survival/threat response, but that still doesn't make it the right one.) > Debian only does a release every 2 years. Many people run the testing or unstable distributions. And in any case, that's not the issue here: > If that number were set to '6 months', in practice what that would mean is that if you want to introduce a breaking dependency, you have to introduce it in the first 18 months of a release development, 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 (which is not the norm, usually Policy follows experimentation and documents what has become existing practice), make sure it's something that could theoretically work not just on non-systemd but also on non-Linux, then wait "at least 6 months, preferably at least 12 months" to see if someone bothers to make an alternative implementation, before you can actually use it. And any further enhancement to such a mechanism needs another 6-12 months. 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.
  • gwd 7y ago
    > 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 https://lists.debian.org/debian-vote/2019/11/msg00163.html