Sorry for yet-another-mail on that (long-lasting) bug, but I feel it's important; so feel free to dismiss it if it isn't bringing to the conversation.
Le jeudi, 6 février 2014, 16.27:15 Anthony Towns a écrit : > Rankings between remaning actual outcomes is: > > 4x UL > DL > UT > DT (steve, colin, ian, andi) > 2x DT > DL > UT > UL (russ, don) > > So that's > > UL > DL > DT 4:2 > UL > UT > DT 4:2 > DL > UT 6:0 I'm quite puzzled by this (partial) result, generally ranking the L variants over the T's. I think letting any L variant win would create quite a precedent on what software is "allowed in Debian". "Software" doesn't imply "package" and is loosely defined, the same goes for "degraded operation". Is "KDE" a software, or are all of its independent parts "softwares"? Would "failure to suspend under OpenRC" be an acceptable degraded operation of the whole "KDE" or only of its upower/Solid/whatever component? L really reads to me like a way to enforce support for all init systems alike (thereby ensuring that the default init gets the same [bad] support) on maintainers and I feel it's too coercitive. On the other hand, T apparently brings in the fear of archive fragmentation by allowing the various init islands to develop on their own. Now, I think there is currently a shared agreement in Debian that "all Debian packages (unless there's a good reason) should run on sysvinit + Linux + amd64 , support outside that is best-effort" Now, I think this "default init" decision's purpose is to change the above agreement by replacing the "syslinux" in the above sentence by one of the contenders. Both the T and L riders purposedly don't say anything about the default init, and I think that's wrong: * T would permit islands outside of the default init (while I think that some prefer it because it allows the "default init island" to be technically sane) * L would enforce that any software can run on all inits (failure to work on one is equivalent to requiring any of the other ones, henc failing the requirement of L) The "common agreement" above stood until packages started to depend on systemd, which in the end, lead to the opening of this bug. I think the technical committee resolution on this issue should focus on outlining what the "new deal" should be, without stepping into defining what set of init systems the software shipped by Debian should or must support: the resolution should be limited to deciding what the new "default init" will be. Now, if there are concerns of eventual bad faith from the maintainers, the resolution could include something outlining the boundaries of the common agreement such as (which I think is the current consensus): "All but specific packages are expected to work with the default init system. However, where feasible, packages should interoperate with all init systems; maintainers are encouraged to accept technically sound patches to enable interoperation, even if it results in degraded operation while running under the init system the patch enables interoperation with." That (or any consensual phrasing along these lines) would completely replace both the T and L riders and be part of the resolution deciding which init system will be the default. I think that would vastly help making the decision largely understandable and consensual, where I'm afraid that any T or L variant would significantly unplease large sets of maintainers. Thanks for considering, cheers, Didier
signature.asc
Description: This is a digitally signed message part.