[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: Call for votes on init system resolution

Russ Allbery <rra@debian.org> writes:

> I consider the L option as currently written to be a commitment to a
> course of action that is technically broken and unsustainable.  I also
> think the effect of L is contrary to its intended goal and will make it
> less likely, not more likely, that Debian will provide working support for
> any init system other than the default in the long run.  (More on that
> below.)

I agree with this, with a slightly greater emphasis on ensuring that
Debian developers continue to have great latitude in choosing how to
package software. I would also have preferred to continue Bdale's ballot
which didn't mention this issue at all.

I think a fair number of us seem to feel that the T/L notion is at
least as important, if not more important, than the D/U/O/V decision as
it sets a broader and longer-term precedent for the project than
choosing which init system should be the default for jessie.

Would it make sense to actually build a ballot that voted this issue
separately, and do that *before* the default init system for jessie
vote? We would list all four of the proposed versions (<nil>, L, T and

I don't think guiding the project in this particular area should depend
on which init system was chosen as the default for jessie. I do think
that either you believe that packages should work with any init system,
so that you can separately choose any combination of them, or you
believe that package maintainers should be able to choose a subset of
the available init systems to support, ruling out some combinations.

I readily admit to not really understanding all of the subtleties of our
polling process, but when looking at the votes cast for Ian's proposed
ballot, it looks like we've got a clear set of votes for L vs T already;
each vote places the xL and xT options in the same order for each 'x'.

It seems to me that this issue is clearly a matter of technical policy
and falls under the ctte purview under section 6.1.1, although I believe
it has some ambiguity as to whether it is valid because of 6.3.5. These
options have certainly been proposed and reasonably thoroughly
discussed, although one might not consider the init system bug thread as
separate from the ctte. Of course, it's really a dependency of an issue
which was brought to the ctte, so in a sense, it's a recursive function


Attachment: pgpxD1BJOp9K_.pgp
Description: PGP signature

Reply to: