Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 25, 2020 at 1:00 PM Nicolas Mailhot via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> 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@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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux