I don't want to contribute much to this discussion because I have not done any packaging
for over 15 years and I never did packaging for Fedora, and since I am currently
overwhelmed with other work, I also couldn't read all posts thoroughly. However, even if
my perspective on packaging and such cases might be a little limited, it might be also
less biased by "this is how packaging always used to be"-type perspectives, and
could possibly induce some yet unconsidered incentives:
Being involved in several security considerations of Fedora and being a discourse moderator who ends up with many of users'
feedbacks and requests (which includes issues about packages that led me more than once to packagers): my perception of this
discussion is that it still emphasizes on symptoms rather than origins, and my "provisional personal opinion" (which I
question myself given my limited involvement in packaging) is that this COULD be just another symptom of packaging in Fedora
being focused much on quantity and less on quality, and that this maybe is not limited to impacts on obsoleted packages but also
led to the need for individuals to respond informally and in an improvised manner "where the system (of people and rules)
remained silent", which might have led to "intuitive unspoken consents" and "ugly but informally
accepted" behaviors, not documented but accepted by many to keep the "socio-technical system of Fedora packaging"
somehow running.
I have had found over time many packages that have not been updated (without the time to report all of them),
sometimes for years (often from people maintaining very large amounts of packages that I personally consider
to be not "maintainable" by one individual), and followed the documented processes (often this
included the process of starting although not ending the process for unresponsive maintainers): yet, I
experienced everything. From "thanks to let me know, and can you maybe test in bodhi to get it updated
quickly?" to lies about "SIGs that requested the packages to be not updated for compatibility
reasons" (while these mentioned SIGs didn't know anything about it) up to hostile behavior.
However, the one issue that I always keep in mind and that I experienced more
than once: I got early in the process informed by other packagers that those
packagers responsible but who I cannot reach are not active in devel mailing
lists and such, and hard to get anyway, and one has to use informal means to
reach them, or, alternatively, someone else does the job and everything goes on
as usual. I experienced this not often enough to say if that is representative
or just exceptions not worth to be mentioned, but my perception was that those
packagers who answered my request were already used to this, and yet, it didn't
provoke any change of thinking.
My point is: based on my "limited" perspective, when I read what is said as justification about pbrobinson, the first subjective instinctive thought I have in mind when reading about the actions he is said to have conducted: wow, he seems to be someone who cares about the conditions and acts when necessary to keep the system running and make it as stable/secure as possible for users. Of course this is a very subjective thought and my perspective about this is limited, and I am not sure if it is applicable at all: I am neither arguing for nor against the decision. But I think this issue might be just a symptom of a deeper problem, and I do mean deeper than FESCo decision making or updating a process/packager documentation that seems to be, from my limited external perspective, already replaced by an informal reality (with a strong emphasis on quantity in our major repositories) that feels like "take more than we can manage and coordinate, and hope that when a leak/issue rises,
someone will be there to find it and someone to fix it". This might lead to much needs for improvisation, informal behavior, and therefore much space for conflict: it likely ends up in a split of "practically exercised rules/behaviors" and thus a split of a group into many groups (and large potential for conflict if two or more of these groups experience each other after they informally-standardized their respective behaviors and wonder why the other don't follow the same pattern).
As far as it concerns me, I do not trust our packages in general: I trust some
individual maintainers, and I trust some SIGs/WGs, and therefore, I trust only
the packages these people/SIGs/WGs provide. This includes most of what is
shipped by default, but not much more. Not sure if the reason for my limited
trust has the same origin as cases like this?
I am aware that what I was writing is written a little provocative, and I hope
no one feels offended. I am aware that packagers here do a lot of work to keep
Fedora running, and they shape the system that satisfies my needs best, for
about 20 years now. Thanks for these efforts to everyone :) Yet, I think my
perspective has more potential to add useful incentives rather than harm ;)
Just my two cents, not sure how far they apply, but I thought in a case that
makes many to ask for major changes, it might be useful to have this
perspective at least mentioned :)
Best,
Chris
On 18/12/2024 22.21, Matthew Miller wrote:
On Tue, Dec 17, 2024 at 02:28:09PM +0100, Vít Ondruch wrote:
This is not recent example, but really bad example of PP's work IMHO:
https://src.fedoraproject.org/rpms/ruby/c/c31c7edb6913eb7417ee68c59997548df2943dde
I do not think nitpicking over _ten year old_ commits is helpful.
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
