Stefano Zacchiroli <z...@debian.org> writes: > Some of the longest -devel thread in recent years have been about > Debian's (default) init system: SysV, SystemD, Upstart, OpenRC, etc. > Despite folklore, I don't think those thread have been (entirely) > trollish, they all hint at a concrete problem:
(For the record, it's systemd, not SystemD. Sorry!) > How do we make an inherently archive-wide technical decision when > multiple, possibly equally valid solutions do exist? What I believe to be a solution in cases like this, is to sit down with the stakeholders (preferably in person; a conference or DebConf would be a perfect opportunity for this): maintainers of said systems, porters (primarily kFreeBSD & Hurd folk), the security & release teams, and if possible, upstream developers of the individual init systems too. I'd do this behind closed doors, initially, because the number of arguments and the level of noise needs to be controlled, and we've seen how well that works on a public mailing list. We need to estabilish the key requirements (which in this case, will be a though cookie to crack too), and see what compromises the stakeholders are willing to make. The primary role of the DPL in this case would be organisation and mediation, to make sure that those involved understand that compromises will have to be made, or we'll be stuck with sysvinit forever, which is likely not what most of them would want. Also, since there's many people involved, and I would very much like to get upstreams in too, this would not be doable within a single sitting - rather, one discussion where Debian members attempt to come to a few agreements, and another, where upstreams can help us clarify things, or point out any mistakes in our thinking. There will be conflicts of interest, which is another reason I would strongly prefer holding this sprint in person: it is far easier to reason with people in person, far easier to calm the waters when one does not have to fight latency and distance too. Ultimately however, this is a decision that the technical stakeholders will have to make, but the DPL should be there to faciliate the decision, and keep strong opinions from clashing into each other's face. But the task is not nearly done once key requirements are found, not even when compromises are ready to be made - that's just the beginning. A painful transition will have to be planned, the change throughly documented, with strong reasons behind the decision. With all these, the DPL can help, but he'll be at the instructor's wheel at best. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3p3bp6a....@galadriel.madhouse-project.org