Am Montag, 9. Jänner 2023 23:06:17 CET schrieb Zbigniew Jędrzejewski-Szmek:
On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
Kevin Kofler via devel wrote:
PS: The impression I get is that everything was deliberately
rigged so that
the vote would end up the way it did:
You're mixing up two things: a vote being "rigged" with a result you don't
like.
No, the result is NOT why I got the impression that the vote was rigged.
The way that result was obtained is. In fact, I had explained exactly that
in the remainder of the message, which you omitted from your quote and
pushed to the bottom of the mail (and even that quotes only half of it) for
some reason.
Absolute majority (6 out of 9) of voting members voted in favour.
As I believe, as a consequence of the incomplete and misleading data that
was provided to them in the one-sided discussion, in particular, the flawed
comparison with the _FORTIFY_SOURCE=3 change. (It might not have mattered
to you personally, but you were the only one who had been in favor of that
change from the beginning anyway.)
The changes to this Change proposal were not considered major
changes that would require a repeat discussion on fedora-devel,
And that was a fatal misjudgement. A crucial point that swayed the vote was
a comparison with another change, the _FORTIFY_SOURCE=3 one, which had not
previously come up in the discussion. Therefore, we had no chance to debunk
the flawed comparison. And flawed it was:
* It neglected that _FORTIFY_SOURCE=3 is a security feature for end users
whereas frame pointers are a developer-only feature.
* It made wrong assumptions about the performance impact of
_FORTIFY_SOURCE=3, which, compared to the already existing (!)
_FORTIFY_SOURCE=2, appears to actually have NO performance impact at all
(!), only compared to no _FORTIFY_SOURCE at all.
* It came with an implied accusation of hypocrisy (double standards)
against the Tools Team which makes no sense when you consider the above
details, and the Tools Team was given no chance to defend themselves. That
matters particularly because that false accusation was used to justify
ignoring the Tools Team's stakeholder opinion on the frame pointer change.
If you were to look at FESCo meeting logs, this happens every once in
a while: a proposal is made, it get's a few +1 votes but not enough
and is effectively rejected, so a different-but-similar proposal is
made and the vote repeats. Sometimes we go through a few of those in
one meeting. In this case this was split over two meetings, but is not
substantially different.
This is substantially different in that it was publicly communicated that
the change was rejected and then suddenly FESCo changed their mind out of
the blue. That is different from voting on multiple proposal variants
during the same meeting and then communicating the final outcome.
(And by the way, what was ultimately accepted was not really a *different*
proposal, but effectively the same as your proposal that had been voted
down a couple weeks earlier.)
Discussion was ongoing all that time, both publicly and privately,
This was not transparent at all. We all got the impression that the
discussion was closed and the feature conclusively rejected, and had no
idea that there was still a discussion ongoing to which we were not
invited.
and there is nothing that says that FESCo members must not change their
votes based on new information.
But, as I explained above, said "new information" was misleading or
incorrect, and the stakeholders were not given a chance to prove that.
The intent of this particular proposal is to learn and adjust based on the
feedback from the initial implementation. The specific flags on different
architectures can and should be adjusted to get the desired result.
That is effectively treating stable Fedora releases and their users as
guinea pigs. Especially since you want to wait 2 whole release cycles
before even considering a revert (and there is already the expectation from
the Change owners that a revert will have the burden of proof reversed in
its disfavor, which I consider unacceptable, but which was neither
confirmed nor denied by FESCo – that is not what I would consider a
provisional acceptance of the change).
I really do not see why gathering data cannot be done in a side tag and/or
as a Fedora Remix. Experiments belongs into an experimental branch, not
into a stable release.
An interesting phenomenon is that before the Change was approved, most
of the feedback on fedora-devel was about whether we need the change
at all, and how horrible the performance degradation will be, and what
distribution to switch to. After it was approved, the feedback
immediately became more technical, with suggestions about specific
flags and architecture differences.
That is because the people have apparently resignated to accept that Fedora
has decided to become unusable and are already looking for another
distribution. I know I am.
If we had approved the Change 3 months ago, we would have gotten that
useful part of the feedback much earlier. For me the lesson is that we
shouldn't dawdle on high-stakes controversial votes, but instead approve
ambitious proposals early and have more time to adjust or even revert if
it turns out necessary.
That is also the very wrong lesson to get out of this. FESCo needs to be
more willing to actually REJECT changes that make Fedora worse. (And with
that I mean, STICK to the rejection, of course!) I am fed up of seeing
every single such detrimental change getting approved by FESCo despite all
the warnings and negative feedback from the mailing list. Often with
disastrous consequences, e.g., just see how badly mandatory Modularity
(with the intent to move some packages to module-only) has failed, for
example. The failure modes were exactly the ones I and others had warned
about from the onset. We were ignored and the change approved anyway.
Unsurprisingly, it failed, and Modularity had to be made optional and
module-only packages banned to fix the chaos. And now, for once, FESCo
finally had the courage to reject an unfixably flawed change ("unfixably"
because the performance loss is not going to go away no matter how you
reword the change, rejecting it is the only reasonable thing you can do to
it), and what happens? The decision suddenly gets reversed in a mid-holiday
commando action. What the heck?!
Why is it so bad to just say no when you have to? Why can we not accept
that some changes are just flawed by design and just cannot be fixed? Why
is an acceptance always treated as a success and a rejection as a failure?
The default reaction to a change needs to be to reject it. What has worked
for decades should only be changed if there is a really strong reason to.
Rejecting a change is always safer than accepting it.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
