Le mercredi 25 mars 2020 à 17:33 +0100, Aleksandra Fedorova a écrit : > My point was to highlight that ELN is not a "stable edition" like > Fedora Server. ELN is Rawhide, its quality is no better than Rawhide > quality, its stability is Rawhide stability, its target audience is > Rawhide audience. Ok, then if I may play the devil’s advocate. Why is it not Rawhide? Are @rh fixes so valueless you wouldn’t want them in Fedora itself? Are community contributors so scary it is not possible to find accocmodations with them? I *think* ELN comes from good intentions. Just like modularity came from good intentions. Just like Centos stream came from good intentions. That beind said, good intentions are not enough for a proposal to succeed. The core problem (root cause in ITIL speak) is that years of EL balkanization Centos and RHEL side, with little Fedora involvment, and a dearth of clear upstream/downstream ground rules, completely tore down the upstream to downstream packaging pipeline. And that modularity, didn’t make the situation any better. Which leaves EL with a huge upstream problem. Fedora itself has no such problem, except for the experimental not- quite-releases Adam ranted about a few days ago. Rawhide → stable → stable - 1. KISS and effective (as long as you do not get into EPEL land, but that’s not due to the Fedora part of the equation). That’s why the *community*, by and large, has been thoroughly unimpressed by the attempts to convert Fedora into the same hodgepole of ill-defined overlapping package fiefdoms/streams. So, before we go full charge ahead on technical solutions, without considering the social challenges (that did not work so well before), could those proposals come with a clear package lifecycle graph, from Rawhide to Fedora to ELN to stream to EPEL to whatever? And answer the following questions: 1. I want <nice software> available on my own non-production system (and the systems of my friends), at what point of the lifecycle graph should I contribute? (<nice software> end user) 2. I want <nice software> available on my own production system (that I maintain without @rh help), at what point of the lifecycle graph should I contribute? (<nice software> work user) 3. I want <nice software> available on my own production system, but I don’t want to maintain it myself, and @rh does not include <nice software> in RHEL/Centos, where should I contract the packaging work (I’m not a software house but I’m rich enough to sponsor the packaging of a few pieces). (<nice software> corp user) 4. I want my own <nice software> to be distributed widely, at what point of the lifecycle graph can I help advancing things? <nice software> creator) You can add other reasons to do community packaging work in Fedora if I missed one. The point is, *community* work, need to be rewarded one way or another. And the only thing you can reward community work with, is shipping the result of this work somewhere. So, all those new proposals, without clear commitments on shipping the result somewhere the contributor can make use of it, are quite disturbing. A picture is worth a thousand words. Please draw us what you are attempting to achieve. That will make it so much easier for everyone here to understand it. And you can say “it’s only for @rh employees”. But that’s giving up on making Fedora work as a community project. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
