On Wed, Mar 25, 2020 at 1:00 PM Nicolas Mailhot via devel <devel@lists.fedoraproject.org> wrote: > > 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 don't see this as the case at all. I think the point here is all of those fixes have to be put in through rawhide. One major reason on why it is not rawhide is because it won't run on the average Fedora system. Remember that conversation about build flags last year? AVX2 and similar minimum baselines? Enterprise doesn't have to run on 10 year old hardware. They can set new baselines for every release. Once they are set, that version will support those baselines for years, but the next version may not support the same baseline. Fedora does support older systems, and as you might recall from that thread, it seems a good 70% of current Fedora systems would not support such new baselines. ELN is rawhide, or at least a subset of rawhide, but the build flags are optimized for a different type of system. > 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. > I think there can be multiple wins here for Fedora. RHEL developers paying more attention to Fedora should work out well. For users who have capable systems, there may be some advantage to running a hybrid Rawhide/ELN system. This can be done without having releases and installable media. It just takes a bit of additional dnf configuration (I am assuming the priority option still works on repositories). At least the theory was performance would be better with the higher baseline. Now, none of this does anything to support Fedora stable releases yet, but it does give us a place to test and see if such an effort would be worthwhile. > 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@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 _______________________________________________ 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
