[ M-F-T set to debian-vote@l.d.o, not seeking sponsors yet see below. ]
Hi!
I think that forcing a decision through the TC at this time was very
premature and inappropriate, because I don't think enough effort had
been made to reach consensus (failing §6.3(6)), because the TC seems
to have been trying to do design work (failing §6.3(5)), and because
even if they do have the power to decide on this (likely requiring a
3:1 majority in any case if they need to override the sysvinit
maintainers, per §6.1(4)), I feel it's inappropriate for a small group
of individuals to forcibly decide the global direction for the entire
project. Such decisions, on issues that are as much technical as
strategic, political or of a subjective design nature, can have huge
implications for what contributors or other Debian-based projects
might have to work on, or stop working on. I feel that such decisions
must belong to the project at large.
Moreover, none of the proponents of alternative init system seem
to have expended much energy in seeking wide deployment of their
solutions within Debian (or, with the exception of upstart, even
updating the policy manual) before this binding ruling was sought.
If they had done so, Debian could follow its usual organic and
decentralized process, allowing the best solution for the project
as a whole to emerge naturally through the consensus formed from the
experience of these deployments. Instead, we have seen giant flamewars
seemingly based largely on speculation, which have only made
the situation worse by increasing acrimony within the project,
with further polarization and antagonization between the different
factions. IMO, forcing this issue via a small committee will not
improve this in any way.
In general, I've been quite unhappy with the excessive invocation of
the TC recently, with developers seeming to view this as a first,
rather than absolute last, resort. I think it's pernicious for the
project to instill a regime of threats and force, that will almost
always alienate at least one side of a dispute. It clearly denotes
a dysfunctional project. It has even crossed my mind many times now, to
propose a GR for each issue concerning project direction (if not all)
escalated to the TC, or even propose a constitutional change to remove
the TC's powers of coercion; restricting its rulings to be strictly
advisory and non-binding, though I'm not sure this option would get
wide traction amongst developers, if at all.
I've been sitting back and trying to see the extent to which other
developers support the view that the TC should not be deciding on
issues of project direction; unfortunately, canvassing support from
mailing lists is difficult, and handling a GR is quite a large
undertaking, requiring a lot of time and energy, that others might
not want or be able to invest, but would gladly get behind.
So, with much reluctance and disappointment, I've finally caved and am
considering proposing the following GR draft. Unfortunately nothing has
changed up to this point; the TC is not backing off. I think the draft
text should cover most of the options people seem to have expressed
support for up to now.
Note that it's not entirely clear how a _pending_ resolution by the
TC would interact with a GR on the same, so I'd like input from the
secretary before seeking support from sponsors, although to be honest
I don't expect any problems here.
,--- DRAFT GR TEXT ---
A General Resolution to select the default init system for Debian.
Option A
* Reinforce sysvinit and sysv-rc as the default init system.
- the level of support for other init systems would remain unchanged;
as with non-release architectures, they would be supported to the
extent that their backers would be willing to expend their energy.
Option B
* Changing the default init system is ultimately desirable, but
premature at this point in time.
- supporters of other init systems should continue their efforts
towards full adoption by Debian through guidance in the policy
manual, natural formation of consensus, and wider support through
Debian packages by persuading maintainers to accept patches to
add support.
- if a broad consensus cannot be reached before jessie+1, another
GR could be held to determine the default init system.
- the level of support for other init systems would remain unchanged;
as with non-release architectures, they would be supported to the
extent that their backers would be willing to expend their energy.
Option C
* Switch to sysvinit + OpenRC wherever available.
- architectures where OpenRC is not currently available will switch
whenever OpenRC has been ported, retaining their current default
in the meantime.
- a reimplementation of OpenRC, providing the same interfaces to
the wider system, would satisfy the criteria above.
- the level of support for each init system would depend on the
release status of the architecture: lack of suppo
