Keith Packard <[email protected]> writes: > Right, given that the discussions on this list have been generating what > looks like a pretty darn reasonable consensus on this policy work, I'm > hopeful that we'll be able to resolve this without using the Technical > Committee process. This is not to say that the TC members shouldn't be > involved in this work, only that they should be viewed as Debian > contributors rather than in any special TC role.
> ยง6.3.6 says the TC should only be applied when other efforts have > failed. Frankly, it's pretty darn hard to see the current discussions as > 'failed' given how much progress has been made. > I'd like to see the existing formal process for changing Debian Policy > followed to conclusion by generating a proposal to change the policy and > bringing that to the Debian Policy Team. If the Debian Policy Team is > unable to come to consensus, I would invite the parties to bring their > issue to the TC for us to look at. I've been thinking more about this, and it occurs to me that there's another rather interesting advantage to taking this approach, although it's sort of "cheating." Debian Policy has (at least so far as I can remember) always documented what maintainers should do in packages *right now*, with at most minimal commentary about what could happen in the future. (That's often an intentional choice; speculation about the future is almost always inappropriate in a standards document, since it's usually wrong, and regardless is a distraction that can tempt people into implementing things they're not supposed to be implementing at present.) While there is (sharp) disagreement over what advice we're giving maintainers about the indefinite future, I think we have pretty strong consensus on what maintainers should do right now for jessie, namely keep sysvinit support in packages that already have it, structure dependencies so that an alternative implementation of logind and related DE services will be usable (there's some debate over whether this should be done proactively or reactively in response to such an implementation becoming available, but that will hopefully become moot), adopt support for systemd alongside sysvinit where the maintainer feels like tackling that, and merge patches for any other init systems that people want to do the work to submit patches for. We don't have to and normally wouldn't, in the Policy context, say that this would change after jessie. Rather, we would simply change Policy after jessie for the changing consensus of the project. Now, this does mean that the statement that all packages must support sysvinit would stay in Policy until conscious action was taken to remove it, and that action will almost certainly be controversial and will probably be more than the Policy process can handle. But I at least, as one of the people pushing the viewpoint that we shouldn't support sysvinit forever, feel a lot more comfortable about leaving Policy in that state (particularly since that's what Policy effectively says now) than having the TC say that we're going to support sysvinit forever. One of those things is much less... forceful, I guess. I'm a little worried that we're just going to have this whole fight all over again post-jessie when someone proposes dropping the sysvinit support requirement (and I do think it's important to drop that at some point), but I'm probably just borrowing trouble. Maybe this is the core of a useful compromise. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
