Bug#741573: Two menu systems
Dear TC,
I would like to react to Ian's message, that uses words like "deliberate
dismantling" that can be interpreted as if the misbehaviour is on my side, and
will add a remark on the fact that Policy maintainers have no "veto" in
contrary to what seemed implied in November's TC meeting on IRC.
First, there is no dismantling of the Debian menu in the Policy. Ian calls
this menu "comprehensive", but the reality is that its coverage is patchy, in
sharp contrast with the "must" directive in the Policy. The patch applied
changed this to a "should", which is a strong statement that is ground for
overriding maintainers refusing patches with no reason. This adjustement of
the Policy to the current practice was the core answer to the original
requirement in #707851.
On top of this change I wanted to take the opportunity to brush up the Policy
by describing how to use FreeDesktop menu entries in Debian. Very
unfortunately, this gave the impression that one menu system replaces the
other, but in practice it is two parallel changes. This is why I am asking the
TC to refrain from refactoring that part of our work: it has full consensus,
and to be honest, I would feel it a big slap in my face (in the sense that it
would call for me reconsider if my contribution is really welcome) if the TC
would bypass the Policy change process to modify the changes related to the
FreeDesktop menu.
Ian's message goes in length on obstructive behaviours. I disagree with such
behaviours and I think that the TC should override maintainers who deliberately
block the work of others for tactical reasons. The obstruction discussed here
is the one of a Policy editor who ignored the Policy changes process and
engaged in an blocking strategy by withdrawing the discussion and then
reverting the consensus-driven changes unilaterally.
In the Policy changes process there is no vote and there is no veto. Bill had
ample time to make his points when the discussion was opened. See through the
BTS entry: I took all the time needed - more than eight months ! - to address
people's reactions and seek consensus. The consensus was assessed by a Policy
editor, which is the final point of the process. Bill's behaviour turns the
whole discussion into a waste of time, and leaves the Policy in a state that
does not reflect the reality. Far from increasing the coverage of the Debian
menu systems, Bills commit reversal undermines the value of Debian's policy
manual and sends the message that the personal opinion of Policy editors has
precedence on consensus (and the *work* that it represents to create that
consensus).
For this reason, sorry to repeat myself, I am asking the TC to please rule on
the question that I raised: should Bill's commit reversal be overriden ?
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: