Re: [all candidates] how to choose Jessie init system
Stefano Zacchiroli <zack@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]
Reply to: