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@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
