Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters
On Fri, 8 Sept 2023 at 05:22, Russ Allbery <rra@debian.org> wrote:
>
> Luca Boccassi <bluca@debian.org> writes:
>
> > And I am more than a bit sad that sensible, clear-cut, binding and
> > already-implemented decisions taken by our constitutional bodies get
> > constantly second-guessed and belittled because of an irrational
> > attachment to inconsequential accidents of history. But what can we do,
> > we'll just have to be sad together, I guess.
>
> > Aside from that, in the future please avoid using the word 'minorities'
> > when talking about silly things such as liking or disliking symlinks, as
> > in common English it is used to refer to much more serious matters.
>
> Okay, stop. We are not going to have a Policy conversation like this.
> Nothing about this discussion style helps in making a good decision.
>
> Luca, you have asked repeatedly what you can do to advance the status of
> your open Policy bugs. Most of the answer to that question is that a lot
> of it is outside of your control; I've been having a spectacularly
> annoying summer in a bunch of minor ways and, frankly, simply haven't done
> much of anything I'm responsible for in Debian. But the most helpful
> thing that you could possibly do would be to stop being utterly
> emotionally exhausting to deal with.
I hope you will fare better in autumn, and take all the time you need.
If I inquire about status on the other open bugs is only because I am
unsure of whether I have missed something on my side, and want to
double check that nobody is waiting on new revisions or so, because I
find it hard to track things in long email threads, and I easily miss
stuff, especially as when I asked if I missed something, someone else
said "Yes, Russ posted some comments on your most recent revision, I
believe.", but I couldn't find it. I wouldn't have thought that
sending a reply with "Anything I can do to unblock this?" once a month
or so would be classed as abusive, but given it exhausts you, I'll
stop and just hope I got everything right as-is.
> Case in point: now I'm writing this email message rather than doing any of
> the other things that I am quite sure you would rather that I be doing and
> that you would consider a much higher priority.
>
> In this bug, about a point that from the Policy perspective is mostly not
> even normative, which appears to partly be a bug report against Lintian by
> proxy (the Policy Editors do not maintain Lintian), you started at an
> emotional level of eight out of ten before anyone even disagreed with you.
> Let me quote the start of this bug:
>
> I heard many times the policy maintainers mention something along the
> lines of 'policy should not be a hammer to beat other maintainers
> with'. Today I saw policy being used to force a maintainer to re-add
> support for the deprecated and unsupported split-usr filesystem
> layout, as 'policy only mentions /bin/sh, not /usr/bin/sh'.
>
> So let's update the policy to refer to modern and supported filesystem
> paths as adopted by Debian de-facto and de-jure, and stop other
> maintainers from getting beaten with it.
>
> So right from the first message, you're saying that the goal of this
> proposal is to stop other people from doing something socially you don't
> like that Policy doesn't even tell them to do. And you're using phrasing
> that you know is loaded and contentious and that you know the people
> you've been arguing with all over Debian will disagree with.
No. The point of this proposal is to fix something that is
self-evidently unclear - non-normative (as I've been told, I thought
it was normative when I opened the bug) language being used as if it
were normative, both by Lintian (yes, the issue has been raised
separately and a fix provided) and by bug reporters. Given, again,
I've been told many times (I believe by yourself, too) that policy
should not be used as a tool to bash developers with, and given I have
witnessed precisely that the other day, I hence decided to spend some
of my time to try and fix that.
As already discussed earlier on this thread, I am fine with changing
the wording of the patch however it fits best, as long as it improves
clarity for this purpose.
> I have no idea why. Because you like making them mad? Because you're mad
> and you want to keep rubbing in their face the fact you disagree with
> them? Maybe you think this is your strongest argument? (It is not.)
>
> This is pretty much guaranteed to turn the bug into a fight regardless of
> its technical merits, because this presentation essentially says that
> you're spoiling for a fight and want someone to attack you.
>
> I cannot remember the last time I have seen someone who is this unwilling
> to win an argument. It's driving me nuts. You are winning your technical
> arguments in Debian! The technical design that you support is being
> implemented because you and others have convinced people that it is a good
> idea, even though some people are very upset about this! There are even
> people who don't entirely agree with you investing significant amounts of
> time and energy to help you realize your technical vision of how Debian
> should be assembled.
>
> And yet, every time I see you in a Debian architectural discussion, you're
> fighting with everyone in sight as if you're losing. You come across as
> the most furious winner of an argument I can remember seeing. This is
> directly undermining what you're attempting to achieve, because the sheer
> vehemence of the way that you argue every point you care about means that
> even people who agree with you don't want to help you get things done
> because even being around this level of fighting is deeply exhausting.
>
> A lot of this hasn't been on Policy, although you do have some of the same
> tendency to reply to everything you disagree with until people stop
> disagreeing even here. But elsewhere, including the Technical Committee
> discussion that I assume you were referring to above, it happens a lot. I
> can only assume that you think you have to shove harder and harder to get
> things to move faster, but this isn't how anything works, particularly in
> a volunteer organization. People work on things they enjoy working on.
> Calm and productive technical work is enjoyable to a lot of us. Watching
> people fight is not enjoyable. What you're actually accomplishing is
> building a subconscious emotional association in the brains of people who
> are watching and reading between your name and angry arguments. You are
> literally training people to avoid you.
>
> You are never going to convince people to stop disagreeing with you.
> Never. We have a process for making decisions because sometimes consensus
> is not achievable, and the people who don't agree with those decisions
> may, in fact, *never* agree with those decisions. They get to do that.
> It's not a crime. It's also not a personal offense against you.
>
> When people voice that disagreement, again, to a decision-making body and
> the immediate response is for multiple members of that body to politely
> but quite clearly indicate that, although they're willing to listen, the
> discussion is probably going nowhere and no decisions will change, this is
> what winning an argument looks like. This is what you're going to get.
> You're not going to get unanimous consensus. Take the win and *leave it
> alone*.
>
> Right now, you keep risking undermining architectural decisions that
> you've worked hard to achieve because you pile into discussions with your
> intensity knob already maxed and say a whole lot of confrontational stuff,
> some of which is careless or imprecise, and then the people *who already
> agree with you* feel obligated to disagree and clarify. And *then you
> start fighting them*, and absolutely nothing about this is achieving any
> goal that you have.
>
> Please, for the sake of my blood pressure, I beg of you, dial it *way
> down*. I swear that when I do process Policy bugs I will read all the
> messages and understand the technical arguments and clearly state what I
> think the most convincing points are, and everyone will get a chance to
> review that, and changes can even be reverted later if we get it wrong.
> Nothing is going to happen by surprise, and you do not have to be the last
> arguer standing in order to get your change into Policy. The more
> messages there are, and the more emotional heat there is, the more energy
> the whole process requires and the longer it takes.
For a message that started with "We are not going to have a Policy
conversation like this", this sure looks a lot like a long-winded
tangent to me. I don't think this policy issue is the place nor time
for such a flamewar, but I am going to clarify a few points given you
brought them up.
Firstly, I couldn't possibly care less about who agrees or disagrees
on what with whom. Nor who 'wins' or 'loses' - this is not a football
game. If someone writes a blog post saying "Debian is pure shite and
it's all bluca's fault", I'm not even going to flinch, have at it,
disagree all you want. I do however care a great deal when work is
hampered by obstructionism, and misinterpretation of the rules
(whether willful or not we shall not speculate), and all the way up to
open and plain sabotage, because that's not just "disagreement". This
has been and still is a constant struggle. For years. You don't think
_that_ is exhausting? Have you stopped for a second to think that
maybe, just maybe, that's the reason the "intensity knob is already
maxed"?
Secondly, and less importantly, while I appreciate it's not how you
handle policy changes, the way the rest of the distribution works is
by 'building consensus' on mailing lists. Now I don't particularly
like it, but it is what it is. And that means if somebody comes up
with the most egregious nonsense like, to pick a completely fictional
example, "hey folks, usr-merge broke docker, rsync and ansible, we
need to revert it", and it is left unchallenged, then it becomes doxa.
So it has to be challenged. Every time. After half a decade, you don't
think _that_ is exhausting?
Reply to: