Bug#190753: About dropping the ‘should’ recommendation to rename binary programs using a suffix to indicate their programming language.
Charles Plessy <plessy@debian.org> writes:
> There is no consensus for the change, but I would like to underline that
> the directive itself is not consensusual, as some other developpers
> supported me in the thread on debian-devel. I think that this is a
> strong indication that the directive must not be a should and that the
> final decision must be left to the maintainer, without making his
> package buggy.
Philosophically, I don't think this is the way that Policy changes should
work, at least as decided by the Policy team rather than by the Technical
Committee.
The basic idea from how I look at it is that Policy uses consensus as a
stabilizing factor as well as an approval process. This is typical for
very conservative document maintenance, such as for standards. In order
to change the document, one needs consensus, but once one has that
consensus and the change has been made, that change persists not for so
long as it has consensus but rather until there's consensus to change it.
In other words, the barrier is to the document change, rather than
approval of a specific thing the document says. At the time this change
was proposed, I think it clearly had consensus (indeed, from the bug log,
it was apparently unanimous).
The advantage of this maintenance mechanism is that it produces a stable
document. If provisions in the document are removed as soon as they don't
have consensus, you can get "flapping" of provisions that are right on the
border of a rough consensus, where they keep being added and removed.
Furthermore, the Debian Constitution specifically delegates hard technical
decisions to the Technical Committee, so I think it's best to follow that
procedure rather than using the Policy process for changes that are
contentious but that also don't seem right to just reject as not having
consensus. The Technical Committee has the decision-making policies and
clear statements of responsibility required to make difficult decisions,
whereas the Policy process is much more open to interpretation. The
Technical Committee is processing bugs fairly well right now, so as long
as we don't send *too* much in that direction, I think it's a good process
to use for difficult cases where there isn't a consensus for a change but
also not a lot of comfort for not changing things.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: