Dear Mikel, Thank you for your reply. I appreciate you taking the time to respond.
However, I must respectfully clarify a few misunderstandings and address what I believe is a deeper issue. --- 🔍 **Technical Contributions** It is inaccurate to state that "no technical contribution" was made. - My work involved not only rebuilding `opendmarc` for AlmaLinux 10, but also verifying its runtime behavior under systemd. - I confirmed that mail delivery worked as expected in a production-grade environment. - I published the SRPM, SPEC file, runtime results, and build output publicly, providing a working, traceable solution long before the EPEL Bodhi build appeared. - The fact that Xavier Bachelot added `perl(Switch)` does not invalidate the runtime testing and verification work I performed. This is a standard part of software engineering: **runtime validation** is essential, and not limited to adding a missing spec field. --- 📦 **Process and Rules** I understand and respect the packager policy in Fedora. I am not contesting the need to follow procedures. But when a contributor shares a **verified, working solution** for a broken package, and the fix is then incorporated into the official build *without any attribution, response, or engagement*, it sends a very clear message that community contributions are not welcome unless you're already part of the inner circle. This is not just about process—it's about **community values**. --- 🌍 **Infrastructure Barriers** I also want to emphasize that I attempted to submit my work via the correct channels, including a dist-git fork and Bugzilla reports. However, a documented infrastructure barrier (Issue #12602) prevented me from pushing to Fedora's Git even after following all procedures. In such a situation, contributors are stuck in limbo: **doing the work, proving it works, and still being ignored.** --- 🤝 **What I Expected** Let me be very clear: I never demanded maintainership or ownership. I simply expected one of the following: - Acknowledgment in the Bugzilla that the package had already been rebuilt and verified - A reply stating that the package would be handled, and my contribution appreciated - Possibly being added as co-maintainer *if* trust had been established (subject to packager status, of course) Instead, the rebuild went forward, and all prior efforts were completely disregarded. This is what I believe deserves reflection—not out of ego, but out of respect for transparent collaboration. --- 🙏 **Final Thoughts** This is not personal. I have no issue with you as an individual. But as someone helping maintain secure infrastructure for government-related systems in Japan, I find this experience disheartening. The Fedora/EPEL ecosystem is built on community effort. When meaningful contributions are discarded or absorbed silently, it erodes trust. I have no desire for conflict. I want to continue helping improve Fedora/EPEL, and I am now actively contributing several other packages (gftp, meld, inxi). I hope we can work together more constructively in the future. Sincerely, Akiyoshi Kurita (FAS: redadmin) 2025年6月18日(水) 19:49 Mikel Olasagasti <mi...@olasagasti.info>: > > 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 -- _______________________________________________ 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
