Russ Allbery <r...@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 S). 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 call. -- keith.pack...@intel.com
pgphGeaU9EDbb.pgp
Description: PGP signature