[ 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 support in a package
for an init system shipped as the default on a release architecture
would constitute a serious bug, taking into account the necessary
transition period of at least one release.
- 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 D
* Switch to Upstart wherever available.
- architectures where Upstart is not currently available will switch
whenever Upstart has been ported, retaining their current default
in the meantime.
- a reimplementation of Upstart, 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 support in a package
for an init system shipped as the default on a release architecture
would constitute a serious bug, taking into account the necessary
transition period of at least one release.
- 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 E
* Switch to Upstart exclusively by jessie+1.
- no other init system should be supported, besides the current
default during a transition period of at least one release.
- architectures where Upstart is not currently suitable for use as
default will switch whenever Upstart has been ported; if they
cannot switch before the jessie+1 release, they will be dropped
from the list of release architectures.
- a reimplementation of Upstart, providing the same interfaces to
the wider system, would satisfy the criteria above.
Option F
* Switch to systemd only on GNU/Linux architectures.
- architectures where systemd is currently not available will switch
whenever systemd has been ported, retaining their current default
in the meantime.
- a reimplementation of systemd, 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 support in a package
for an init system shipped as the default on a release architecture
would constitute a serious bug, taking into account the necessary
transition period of at least one release.
- 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 G
* Switch to systemd exclusively by jessie+1.
- no other init system should be supported, besides the current
default during a transition period of at least one release.
- architectures where systemd is not currently suitable for use as
default will switch whenever systemd has been ported; if they
cannot switch before the jessie+1 release, they will be dropped
from the list of release architectures.
- a reimplementation of systemd, providing the same interfaces to
the wider system, would satisfy the criteria above.
`---
Thanks,
Guillem
Attachment:
signature.asc
Description: Digital signature