Dear Fedora/EPEL community, I would like to report a structural issue in how technical contributions to EPEL packages are handled when performed by contributors who are not yet members of the "packager" group.
--- 🧩 Background In February 2025, Bug 2344510 identified that `opendmarc` was broken in EPEL10 due to a missing dependency: `perl(Switch)`. As someone responsible for maintaining secure mail infrastructure for government-related institutions in Japan, I (Akiyoshi Kurita, FAS: redadmin) took initiative to address the issue while no fix was yet proposed in the build system. --- 📦 Actions I Took (Feb–June 2025) - Rebuilt `opendmarc` for AlmaLinux 10 using mock with EPEL10 config - Verified runtime under `systemd` and confirmed successful delivery in production - Published SRPM, SPEC file, mock logs, and results: → https://github.com/redadmin-k/opendmarc-almalinux10-rpm - Shared working results publicly on Bugzilla (Comments 9–10, 12) - Forked dist-git and prepared EPEL10 build: → https://src.fedoraproject.org/forks/redadmin/rpms/opendmarc - Formally offered co-maintainership (Comments 12, 17) --- ❗ What Happened Despite this: - The existing maintainer (Mikel Olasagasti) later submitted the rebuild to Bodhi - My fork, working SRPM, and validation results were not acknowledged - I was not added as a co-maintainer, despite directly resolving the issue - Instead, I was advised by another community member (Comment 18) that my request was procedurally inappropriate and that I must first become a packager—even though the technical solution was already proven and complete Let me be clear: I am not questioning Mikel’s rights as the maintainer. However, the fact that a contributor who resolved a blocking bug, verified the fix, and offered collaboration was entirely bypassed—without attribution or follow-up—is deeply problematic. In the broader context of open source, this type of behavior is widely regarded as unethical. Taking technical credit for another's working solution without acknowledgment violates core OSS principles of transparency, meritocracy, and collaborative respect. Even if not intentional, it sets a precedent where contributors are discouraged from helping if their work is likely to be disregarded or rebranded. --- 🚫 Infrastructure Barrier To make matters worse, I encountered an additional obstacle: - I was unable to push my fixes to Fedora dist-git due to a long-standing network-level SSH access failure from Japan - This issue is documented here: https://pagure.io/fedora-infrastructure/issue/12602 This effectively prevented me from submitting my fix even though I had already completed the work and prepared the RPMs. As a result, my contributions were delayed or rendered invisible, which allowed the rebuild to proceed without acknowledging the original work. --- 🛠️ Structural Issue This case reveals a deeper process problem: - Non-packager contributors are structurally unable to participate—even when they resolve real-world issues - Historical ownership is prioritized over demonstrated technical work - Infrastructure-level barriers (e.g., SSH restrictions by geography) can further block new contributors from participating - OSS ethical norms around credit and transparency may be unintentionally violated in the current process --- 📢 Request for Consideration I respectfully propose the community consider: 1. Acknowledging non-packager contributors when their work directly informs package restoration 2. Establishing a clear, merit-based co-maintainership path for proven contributors 3. Ensuring Bugzilla and dist-git contributions are not discarded due to group status 4. Investigating and resolving infrastructural barriers that block package submission from certain regions 5. Promoting ethical standards of credit and transparency consistent with broader OSS values I remain committed to supporting EPEL and Fedora. In addition to `opendmarc`, I have independently packaged and submitted `gftp`, `meld`, and `inxi` for EPEL10, all with tested results and full logs. I raise this issue not out of frustration, but to help ensure that Fedora truly remains a meritocratic and inclusive community where technical contributions speak for themselves—and where contributors are encouraged, not erased. Thank you for your time and consideration. Sincerely, Akiyoshi Kurita FAS: redadmin -- _______________________________________________ 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
