Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

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

 



Hi, Jeff,

On Thu, Oct 22, 2020 at 4:14 PM Jeff Law <law@xxxxxxxxxx> wrote:
>
>
> On 10/22/20 8:09 AM, Daniel P. Berrangé wrote:
> > On Thu, Oct 22, 2020 at 04:03:33PM +0200, Aleksandra Fedorova wrote:
> >> Hi, Daniel,
> >>
> >> On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
> >>> On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote:
> >>>> Hi, all,
> >>>>
> >>>> this is the informational message, no action required.
> >>>>
> >>>> Upon agreement between gcc maintainers and ELN SIG we would like to
> >>>> switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
> >>>>
> >>>> Though ELN is defined as the buildroot where Fedora Rawhide code is
> >>>> rebuilt into EL-like environment, in the ELN proposal we also
> >>>> mentioned that ELN can be used to test certain buildroot-related
> >>>> features on the side so it doesn't block Fedora Rawhide development.
> >>>>
> >>>> We think that GCC11 is one such feature, where we can benefit from
> >>>> testing it first on a small subset of the Fedora content in a separate
> >>>> environment.
> >>> I'm not very enthusiastic about this change.
> >>>
> >>> Fedora maintainers can largely ignore ELN right now, because if stuff
> >>> works in rawhide, it will generally work in ELN, and someone else is
> >>> taking care of ELN builds.
> >>>
> >>>
> >>> New GCC releases almost always trigger new compile warnings or bugs
> >>> in code. So by pushing GCC 11 into ELN, it feels like we're making
> >>> it much more likely that ELN builds will fail, and now Fedora
> >>> maintainers have to debug ELN specific problems that won't reproduce
> >>> in rawhide branches :-(
> >> Expectations for Fedora maintainers does not change.
> >> ELN is a development playground. Think about sidetag, with slightly
> >> better automation around it.
> >>
> >> We provide ELN as the opportunity, option to play with early releases
> >> of the GCC11 on the side. We are not requiring Fedora maintainers to
> >> participate, we are inviting people who may be interested in this
> >> work.
> > As Fedora maintainer I've been sent details of ELN failures / bugs, and
> > asked to deal with fixes for ELN branches, so there's clearly an expectation
> > placed on Fedora maintainers to be engaged in ELN.
>
> And that's unfortunate.  I've tried to signal to the ELN/Bakery folks
> that they should be contacting me first as any build failure related to
> teh compiler change I've probably already seen in one form or another.
> But it doesn't seem to have sunk in.

We haven't merged gcc11 into ELN yet, and there are no builds or tasks
filed about it to Fedora maintainers.
So I am not sure which issues Daniel is referring to.

Of course if a package needs an adjustment of a spec file to be built
in ELN buildroot, members of the ELN SIG might reach out and ask for
help, or suggest a pull request.
And yes, the expectation is that one member of the community can reach
out to another for the specific issue. I honestly believe that this is
how open source collaboration works.

-- 
Aleksandra Fedorova
bookwar
_______________________________________________
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