Dear Kurita-san, Hau idatzi du Akihito Kurita (akito5...@gmail.com) erabiltzaileak (2025 eka. 18(a), az. (03:16)): > > 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 don't understand what kind of credit you are looking for. Package was able to be built without any issues, but it was a runtime dependency missing that caused the package to be retired while this was resolved. > - I was not added as a co-maintainer, despite directly resolving the issue As noted in comment #13, co-mantainers are welcomed, but I simply can't add you as one because you're not in the packagers group. Your request for me to orphaning the package or transferring it to you made no sense. https://bugzilla.redhat.com/show_bug.cgi?id=2344510#c13 You need to follow Fedora's rules to be able to contribute. It’s important to walk before we run. > - 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 You did not provide any technical solution. The package could be built, but a runtime dependency was missing and that was solved by Xavier Bachelot in https://bugzilla.redhat.com/show_bug.cgi?id=2348413 just 11 days before you created BZ2372884. > 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 non-packager have many ways to contribute, but they just can't commit and build things by themselves. And it makes sense. > - Historical ownership is prioritized over demonstrated technical work You're not understanding the flow, it has nothing to see with ownership. If you've submitted a PR it would have been reviewed. In this case just a rebuild was required and it took 11 days since the dependency was added. I could have been faster, but it was nothing critical to be honest. > - 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 Nothing has been violated intentionally or unintentionally. > --- > > 📢 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. This will be my last message around opendmarc or EPEL with you. Best regards, Mikel Olasagasti - mikelo2 -- _______________________________________________ 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
