On Thursday, May 14, 2020 5:37:10 AM MST Josh Boyer wrote: > On Thu, May 14, 2020 at 4:54 AM Nicolas Mailhot via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > Le mercredi 13 mai 2020 à 15:17 -0400, Josh Boyer a écrit : > > Hi, > > > > > > > > > If the consensus from the Fedora community is that RHEL should shift > > > development elsewhere, the Fedora Council can always reach out to me > > > and I can start that internal conversation. I do not believe for a > > > second that's actually the consensus though. Fedora and RHEL are > > > symbiotic in so many ways that it is naive to believe Fedora is > > > somehow self-contained and RHEL gets no value from it or has no > > > impact on it. > > > > > > > > The most downloaded part of Fedora is EPEL, and even Fedora packagers > > that do not contribute to EPEL will often use it or got involved in the > > project in the first place because of EL and EPEL. So, no question that > > EL & server is important for Fedora (people should remember that when > > they try to conflate Fedora with its desktop edition in Fedora > > communications). > > > > > > > > However, EL as a critical Fedora dimension, is something very different > > from RHEL the product. Products have short term local deadlines and > > market positionning tactics that conflict with wider (time or scope) > > strategies. > > > > > > > > Thus, while I personnaly welcome greater EL implication within Fedora, > > it needs some organisational thought, to be able to handle gracefully > > objective divergences. Because those divergences *will* eventually > > happen, and inventing a process at crunch time when things are on fire > > and everyone is too busy dealing with the fire to listen to others, is > > no fun. > > > Will? Divergences have happened since the Fedora project was founded. > They will continue to happen. Let's review a brief history of some > divergences and convergences and their outcomes! > > 1. Fedora was created after RHEL became the focus instead of RHL. Two > distros, a rocky start to building a community, but it was done. Yay! > > 2. Fedora Extras and Fedora Core were merged. This now complicated > the RHEL product development flow, but it was overall beneficial. > Yay! > > 3. Software Collections were created, proposed, and rejected by > Fedora. They are alive and well in RHEL and customers that use them > see lots of value. Not ideal, but an example of divergence. > > 4. EPEL. A convergence, wildly useful, very valued by both community, > RHEL, and Red Hat customers. Yay! > > 5. Fedora secondary architectures. A convergence at the start for > things like s390x and ppc/ppc64/ppc64le, but then a divergence with > things like armv7hl and riscv. Yay! Fedora to more places and for > more uses! > > 6. Introduction of Fedora Editions. This could be viewed as a > convergence in a way, since they mirrored the RHEL variants in many > ways, but they also spun out KDE, IoT, etc. Yay! > > 7. Modularity. Introduced in Fedora before RHEL, adopted into RHEL. > Having some growing pains, but open collaboration continues. RHEL > usage is limited but provides value there. I won't claim yay on the > technology, but I'll certainly say Yay! to the > community interaction. > > 8. ELN. A convergence, actively being worked, actively being shaped > by the community to address concerns and make it generally useful. > Yay x2! > > The point here isn't to rest on laurels and say we're done. It's also > not to say we're perfect, or frankly even good, at figuring out > Enterprise needs vs. non-Enterprise. My point is this: we have done > this together since the project was created, Red Hat have always > considered the community before proposing anything, and we will > continue to do it together as long as Fedora exists. I am old enough > now to have been both a non-RHT and RHT Fedora community member and > have seen these interactions through both perspectives. There is a > MASSIVE amount of internal discussion and mental energy put into where > we develop, what benefits all sides can have, and how to start those > discussions. Then, after those discussions start, Red Hatters are > often the ones arguing and shaping on behalf of Fedora. For anyone to > assume there isn't this kind of organizational thought at this point > given the project's history is very odd. > > People need to realize this will never be easy and stop throwing up > the "this is a RHEL thing" wall as soon as something new is proposed. > The bias there is both large and unfounded. I didn't see anyone > claiming Fedora community members we're being used as unpaid labor > when we announced Lenovo was preinstalling Fedora on Thinkpads. It > was massively celebrated as a victory, as it should be! Why? Because > together the community has created something even more people will > benefit from by that vendor's choice. Lenovo is making a smart choice > because they see the value in Fedora and open source. That doesn't > change the fact that it was still work Fedora did and will continue to > do to make that successful in the long run. RHEL is no different. > > If I have any good will left in this community, I'd use it to ask that > we all stop the "Fedora vs. RHEL" mentality. It's not healthy and it > creates unnecessary division. There will be more proposals in the > future that aim to address Enterprise needs. Let's just work on them > as we would anything else and find compromise to make everyone > successful. In my humble opinion, the worst thing that can happen is > those proposals stop coming to Fedora and start going elsewhere. There are times when these proposals are only useful for RHEL, and not Fedora. For some reason, those scenarios are actually more common than things that are only beneficial to Fedora, and not RHEL, though we have some of those too. These are the situations I'm suggesting we should approach in a different way. For example, Modules have caused nothing but headache for Fedora users and RHEL sysadmins alike. I wish I could say what the impact on packagers has been, but I've not built any packages requiring modules, and I'm not an active packager for Fedora or EPEL at this time. This is a good example, because they're not useful in Fedora. I'd argue they're not useful in RHEL either, SCLs come out ahead, because they can actually be installed in parallel. In Fedora, it makes sense to only have the latest stable, compatible with our libraries, available as a normal package. Maybe Modularity for Fedora could be handled alongside the standard repos, instead of suddenly switching packages to modules, with an ever growing list of default modules. This way, RHEL devs could have gotten their toy into Fedora, but without disrupting Fedora. I didn't really mean to make this about Modularity, so to get back on track.. I don't believe anyone in the Fedora community views the Fedora community itself as "unpaid labor". Most of the folks doing stuff that only benefits RHEL are Red Hat employees, and that makes sense. It's not some much of a versus scenario as it is that there are some things that are beneficial to both, and some things that are only beneficial to one side. We can work together for the things that are beneficial, but it makes no sense to damage Fedora for the benefit of RHEL, or the opposite. At the very least, that's my opinion now. There may still be hope for me yet. ;) -- John M. Harris, Jr. Splentity _______________________________________________ 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
