Dear Akihito,How about following the official guidelines how to become Fedora (and therefore EPEL) contributor?
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ There is even SIG which could help you with that: https://docs.fedoraproject.org/en-US/fedora-join/ Vít Dne 18. 06. 25 v 12:53 Akihito Kurita napsal(a):
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 acknowledgedI 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 issueAs 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 completeYou 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 issuesnon-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 workYou'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 processNothing 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
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
