Dear EPEL maintainers, I would like to formally raise several structural and procedural issues I encountered while contributing to the restoration of the `opendmarc` package in EPEL10. This message is meant to promote community discussion and identify areas for process improvement.
--- 🧩 Background - In early 2025, `opendmarc` was retired from EPEL10 due to a missing runtime dependency: `perl(Switch)` (Bug 2344510). - I (Akiyoshi Kurita, FAS: redadmin), as part of infrastructure work for a government-related organization in Japan, independently rebuilt the package and verified it in production. - My build was published on GitHub with SRPM, SPEC file, and runtime results: → https://github.com/redadmin-k/opendmarc-almalinux10-rpm - I provided technical findings and offered co-maintainership via Bugzilla (Bug 2344510, Comment #12 and #17). --- 🛑 What Happened - The existing maintainer later rebuilt the package, ignoring the previous Bugzilla contributions and GitHub materials. - I was not credited, nor acknowledged, nor offered collaboration. - I was informed that without being in the “packager” group, my co-maintainership request was invalid—regardless of technical merit. --- 🌍 Infrastructure Barrier Additionally, I experienced a long-standing issue where SSH access to `src.fedoraproject.org` times out from multiple Japanese networks (Issue #12602). This prevented me from pushing to dist-git even if I had sponsorship. --- ⚠️ Ethical and Procedural Concerns - Working contributions were disregarded based on group membership, not merit. - Communication was ended abruptly, with no discussion or resolution. - The original solution was rebuilt and submitted without acknowledgment. - If contributors cannot be credited unless in a certain group, how can we encourage new involvement? --- 📌 Request for Discussion 1. Should working, public contributions from non-packagers be recognized in changelogs or credits? 2. Is there a better pathway for non-packagers to assist during emergencies? 3. Can infrastructure barriers like SSH geoblocking be addressed more openly? --- 📢 Additional Note on Product Integrity Given that EPEL packages are widely used in government and enterprise environments (including projects I work on using RHEL8), I may be required to confirm product integrity through the appropriate Red Hat Japan support channel. I hope that community processes can address these issues transparently—without the need for escalation to formal vendor channels. --- I raise these issues with respect for the community and the hope that we can improve transparency, fairness, and inclusiveness in EPEL governance. Best regards, Akiyoshi Kurita FAS: redadmin -- _______________________________________________ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
