Re: Understanding the current state
Keith Packard <firstname.lastname@example.org> 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@example.com) <http://www.eyrie.org/~eagle/>