[ M-F-T and Reply-To set to debian-vote@l.d.o. ]
Hi!
This is the revised draft GR proposal (please see below); I'm looking
for sponsors now.
On Sun, 2014-01-19 at 01:01:44 +0100, Guillem Jover wrote:
> 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.
As mentioned in the thread, if there's any issue with the above, the
secretary can point it out during the discussion period if this gets
support from enough sponsors.
The two main changes are the addition of the explicit TC option,
and the rewording of option B to not mention a GR explicitly, and to
just postpone revisiting that decision to a later time. I chose that
time to let some breathing after the jessie release, and because it's
(usually) 1/3 of the non-frozen release time, so it would give enough
room to deploy any possible changes before jessie+1. Attached is a
diff against the original GR draft, for your convenience.
,--- 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 for their init systems.
- ideally a broad consensus would be reached prior to six months after
jessie's release; and this decision should not be revisited before
at least that time.
- 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
* Defer the decision to the Technical Committee.
- the selection of the default init system is deferred to the resolution
by the Technical Committee as part of the decision (either pending or
resolved) taking place in the Debian bug #727708.
Option D
* 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 E
* 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 F
* 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 G
* 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 H
* 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
diff --git a/draft.gr-init b/draft.gr-init
index ac7e886..ce985bf 100644
--- a/draft.gr-init
+++ b/draft.gr-init
@@ -88,15 +88,23 @@ Option B
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.
+ add support for their init systems.
+ - ideally a broad consensus would be reached prior to six months after
+ jessie's release; and this decision should not be revisited before
+ at least that time.
- 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
+* Defer the decision to the Technical Committee.
+ - the selection of the default init system is deferred to the resolution
+ by the Technical Committee as part of the decision (either pending or
+ resolved) taking place in the Debian bug #727708.
+
+Option D
+
* Switch to sysvinit + OpenRC wherever available.
- architectures where OpenRC is not currently available will switch
whenever OpenRC has been ported, retaining their current default
@@ -112,7 +120,7 @@ Option C
as with non-release architectures, they would be supported to the
extent that their backers would be willing to expend their energy.
-Option D
+Option E
* Switch to Upstart wherever available.
- architectures where Upstart is not currently available will switch
@@ -129,7 +137,7 @@ Option D
as with non-release architectures, they would be supported to the
extent that their backers would be willing to expend their energy.
-Option E
+Option F
* Switch to Upstart exclusively by jessie+1.
- no other init system should be supported, besides the current
@@ -141,7 +149,7 @@ Option E
- a reimplementation of Upstart, providing the same interfaces to
the wider system, would satisfy the criteria above.
-Option F
+Option G
* Switch to systemd only on GNU/Linux architectures.
- architectures where systemd is currently not available will switch
@@ -158,7 +166,7 @@ Option F
as with non-release architectures, they would be supported to the
extent that their backers would be willing to expend their energy.
-Option G
+Option H
* Switch to systemd exclusively by jessie+1.
- no other init system should be supported, besides the current
Attachment:
signature.asc
Description: Digital signature