Am Mittwoch, 24. Juli 2024 02:52:44 CEST schrieb Gary Buhrmaster:
On Tue, Jul 23, 2024 at 10:38 PM Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
And this one is yet another case of FESCo rubberstamping a change without
even any dissenting vote despite loads of negative mailing list feedback.
How can one determine "loads"? Since the
feedback itself is opt-in, no statistically
valid conclusion can be reached based on
the feedback received(*). FESCo needs to
review the feedback that was received,
and use their best judgement as to whether
to approve or disapprove, and no one
should expect there to be a dissenting
vote just because of negative feedback.
I would actually expect FESCo to unanimously vote against the feature if
the feedback on the mailing list is overwhelmingly negative. Or at least a
majority of FESCo, if it is controversial. But unanimous approval shows
that the feedback on the mailing list has been completely ignored, making
the feedback process entirely useless.
(*) And in addition, there is lots of cases
where only those with negative feedback
will decide to "opt-in" to offer an opinion,
as they are motivated.
If there are not enough people motivated enough to comment in favor of the
Change, this shows that the Change is not valuable enough to be
implemented. If in addition, enough people object to the Change for good
reasons, it follows that the Change should be rejected.
The big issue with the process is that there is this ground assumption in
Fedora that change is inherently good, and hence any Change should be
approved by default. But IMHO, Fedora used to already be almost perfect, to
the point where changing anything could only possibly make it worse. And,
again IMHO, make it worse the Changes did. Some Changes globally increased
the size of the distribution (though admittedly a lot of the creeping bloat
also comes from upstream feature creep beyond the Fedora Project's
control). Some Changes needlessly broke backwards compatibility, making
existing software users were still relying on suddenly break. (The "Retire
Python 2.7" Change is in that category.) Some Changes replaced working
technologies with incomplete and/or buggy replacements that do not work for
users' workflows. Sometimes, an opt-out is possible (and then I end up
opting out on my machines more often than not, making my setup diverge more
and more from the default), sometimes the replacement is unconditionally
forced onto all users (and sometimes the opt-out gets silently discontinued
in a later release without even a new Change). Some Changes were about
gradually making native distribution packages second-class citizens, second
to inferior technologies such as atomic images, containerized applications
(Flatpak, Docker, …), etc. Some Changes are a threat to users' privacy.
(The "Opt-In Metrics for Fedora Workstation" Change is in that category.
All the more if the opt-in process uses the planned weasel wording to trick
users into "opting in".) Some Changes are a threat to users' freedom, e.g.,
by offering proprietary software for download through various means. And
there are probably more reasons I and others objected to Changes. Those
objections were unfortunately never treated by FESCo as a reason to reject
the Change.
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
