Hi, On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote:
> If we're going to have a GR, part of the goal should be to either > confirm the current state that we're never moving very far past the > capabilities of sysvinit even when most people don't run it, or that > we're allowed to use the full capabilities of our default init system > even when there's no equivalent elsewhere. I doubt we have that choice. Those packages embracing systemd will require all the features, and it will be hard enough to put our foot down and insist that they restrict themselves to the set in the stable release. Debian is a community distribution, and we're competing with distributions maintained by full-time employees that have less trouble following the releases of a project driven by other full-time employees. Of course we're having a hard time catching up if we keep our processes. On the other hand, these very same processes have been what distinguished us from other distributions in the past, and what has led to our current reputation as a very stable distribution with very few quality issues. I believe this GR is less about technical than about organizational aspects. If we want to fully adopt systemd, we need a faster policy process, which will disenfranchise users with less-common use cases, because there is no time to integrate their concerns (I'm also sceptical that we have the necessary influence upstream to alter the trajectory of development). This is a massive change for Debian, because the technology decisions drive policy decisions here, and we need to formulate a vision for where the project will be in a few years. Can we provide something unique? One option I'd like to see on the ballot is splitting packages into systemd-integrated and standalone versions where these deviate too much from each other, and making it normal that such packages are team-maintained. If we can't find people for one variant, that is fine, but it should be the exception, and it should be normal and acceptable to depend on or conflict with systemd-sysv as needed (those that conflict would go to Priority: extra). There is still a massive Free Software scene outside the Linux+systemd world, so I expect that we won't run out of software that works without systemd anytime soon. Simon
