Hi, Jeff, On Thu, Oct 22, 2020 at 4:14 PM Jeff Law <l...@redhat.com> 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é <berra...@redhat.com> > >> 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@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
