I was asking for ELN branch for ages and it was always denied and there you have it [1]. So what is the current stance on this topic?

Vít [1] https://src.fedoraproject.org/rpms/gcc/commits/eln Dne 22. 10. 20 v 14:27 Aleksandra Fedorova napsal(a): > 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. > > We would like to invite everyone to join this effort. > > The work is currently tracked on Github: > https://github.com/fedora-eln/eln/issues/8 > > Once GCC11 is merged to the eln tag in koji, one would be able to use > it via, for example, mock or container environment: > quay.io/fedoraci/fedora:eln-x86_64 > > For more info on ELN please refer to ELN Docs (as soon as I update > them, which hopefully happens later today): > > https://docs.fedoraproject.org/en-US/eln/ > _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)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

On 10/22/20 2:51 PM, Aleksandra Fedorova wrote: > Hi, Vit. > On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch<vondruch(a)redhat.com> wrote: >> I was asking for ELN branch for ages and it was always denied and there >> you have it [1]. So what is the current stance on this topic? > You were asking for a branch to overcome the issue with building a > package in ELN. And we have a suggestion for the alternative solution > which wouldn't require maintaining a separate eln branch forever. > > For gcc we are using a temporary branch for the development of a new > feature in Fedora. > I would have named it "gcc11" branch rather than "eln", but it is a > bikeshedding exercise. This is not about naming / bikeshedding. Whatever you call it, this is a "branch used exclusively to build in ELN". Vít wanted this, I wanted this and many other Fedora/RHEL packagers wanted this. Yet you argued so passionately against it. For example you said: > I think that not having eln-branch is very important part of the > concept as we don't want to fork Fedora. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... But there were countless other arguments against having such branches. Have the situation changed? Can other packages have eln branches as well?

-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)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

> It is also not the only one, which we can handle through ELN. We were > considering the update of the baseline of the x86 cpu's to be such a > feature, but then it was discarded. The other example would be the > Default Module Streams setup. Should we expect an eln branch for redhat-rpm-config as well, or this is still under consideration?

I do not think the Fedora Change process applies to parts of %{?rhel} conditionals that are inactive in Fedora.

On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: > > On 10/22/20 6:33 PM, Aleksandra Fedorova wrote: >> On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: >>> >>> On 10/22/20 2:51 PM, Aleksandra Fedorova wrote: >>>> Hi, Vit. >>>> On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch&lt;vondruch(a)redhat.com&gt; wrote: >>>>> I was asking for ELN branch for ages and it was always denied and there >>>>> you have it [1]. So what is the current stance on this topic? >>>> You were asking for a branch to overcome the issue with building a >>>> package in ELN. And we have a suggestion for the alternative solution >>>> which wouldn't require maintaining a separate eln branch forever. >>>> >>>> For gcc we are using a temporary branch for the development of a new >>>> feature in Fedora. >>>> I would have named it "gcc11" branch rather than "eln", but it is a >>>> bikeshedding exercise. >>> >>> This is not about naming / bikeshedding. Whatever you call it, this is a "branch >>> used exclusively to build in ELN". Vít wanted this, I wanted this and many other >>> Fedora/RHEL packagers wanted this. Yet you argued so passionately against it. >>> For example you said: >>> >>>> I think that not having eln-branch is very important part of the >>>> concept as we don't want to fork Fedora. >>> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... >>> >>> But there were countless other arguments against having such branches. Have the >>> situation changed? Can other packages have eln branches as well? >> >> No, the situation has not changed. > > Glad to hear that, because that eln branch in gcc was a big surprise for all of > us who have been told this is not an option. > >> I'll reiterate: >> >> We don't want to fork packages from the Fedora Rawhide. We don't want >> to provide eln-branch as an option to overcome build failures in ELN. >> ELN's purpose is to provide motivation and tooling for downstream >> developers to work on Fedora, not to share parts of Fedora >> infrastructure for downstream developers to do their downstream work. > > From where I stand, this gcc eln branch / update in ELN seem to be primarily > motivated by downstream. But I agree that I might miss all the important > information to make that claim, so I'll try to not be biased. It would be nice if we could stop playing political games and start looking at the content of the work, rather than discussing who brings it.

eln-branch to handle downstream incompatibility with rawhide and eln-branch made to test Fedora features are two different types of work.

>> We expect downstream to have its own infrastructure and process for >> branched packages. And we do have it in RHEL. If you want to discuss >> how exactly RHEL downstream does it, I can provide more information. >> But I consider it to be offtopic in this mailing list, or at least in >> this thread. > > I thought I have a decent idea about how this is done. For example that there > will be no eln branches and this will be done "somewhere else later". At least > that is what we've been told when ELN was introduced. So I seem to have the > wrong idea. Could you please summarize this? What kind of downstream changes > will happen in ELN branches and what kind of downstream changes will happen > "somewhere else later"? Again, you are mixing up changes made in downstream and changes in Fedora sponsored by downstream.

GCC11 is not a downstream change. Of course downstream is interested in landing GCC11 in Fedora as fast and as clean as possible, why wouldn't it. And yes downstream sponsors this work in Fedora.

>> At the same time, we would like to use ELN as an experimental >> playground for features, when it makes sense, when it is helpful for >> Fedora and when these additional features don't contradict the primary >> purpose of the ELN buildroot. > > Do I understand correctly that as long as the downstream work aligns with > "helpful for Fedora" it is OK to have an eln branch? As long as it is not a downstream work, but a feature of Fedora.

>> We consider the update to GCC11 to be one of such features. It is not >> a fork of the Rawhide into a downstream branch, it is a future Fedora >> feature. > > Fedora features are coordinated via the Fedora change process. May we please > have a GCC 11 Fedora change proposal that explains why is this done in ELN-only > first instead of "just doing it"? Is see many packagers would like to be > involved in the process and I feel like that they have been bypassed. From where I stand I don't see many packagers who are feeling bypassed, I see you trying to control how development is organized for some other component. And I don't see the reason for that.

For those who are indeed interested in the work around gcc and ELN, I wrote this mail. Despite the way it is treated here on the mailing list, it is an actual invitation.

But it is a preliminary work which has no impact on anyone but the SIGs and maintainers involved in it. It is just too early to handle it via the Change process.

>> If you would like to propose another Fedora feature, and you would >> like to work together with the ELN SIG on it - please file a ticket in >> the ELN tracker [1]. > > Yet again, Fedora features should be proposed trough a change process, not some > tracker on GitHub. Even when so, the gcc 11 update was discussed on the GitHub > tracker only after it had the eln branch and builds from it. Fedora features can be planned and discussed anywhere. In the mailing list, bugzilla, github, IRC, Telegram, university hallway or Delirium Cafe. Change Process is an important and necessary step in landing the feature in Fedora. But it is never the first step.

> There was no community involvement here, whatsoever. Please just stop excluding me from the community.

We were supposed to have this discussion right now. Unfortunately you choose to discuss the motivations of people doing ELN rather than the work they do.

Look, I do agree that communication of the ELN SIG could be done better. Maintaining a SIG is hard. The update of the docs I promised yesterday is still pending. And we discussed with Stephen the bi-weekly meetings but neither him nor me found the time to actually schedule them yet. We will. And I opened this thread exactly for the reason to provide more visibility into what SIG is planning to do.

Yes we need to improve. If you want to help (and btw your questions on other threads do count as help, so thanks for them), please do. But treating every update from ELN SIG with yet another round of conversation about "downstream secretly trying to contribute to Fedora" is also not helping. I'd rather spend time on actual work. I mean "secret downstream agenda to update GCC in Fedora", really?

From: "Aleksandra Fedorova" <alpha(a)bookwar.info&gt; To: "Development discussions related to Fedora" <devel(a)lists.fedoraproject.org&gt; Sent: Friday, October 23, 2020 2:45:41 PM Subject: Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide On Fri, Oct 23, 2020 at 12:40 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: > > On 10/23/20 11:52 AM, Aleksandra Fedorova wrote: > > On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: > >> > >> On 10/22/20 6:33 PM, Aleksandra Fedorova wrote: > >>> On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok <mhroncok(a)redhat.com&gt; > >>> wrote: > >>>> > >>>> On 10/22/20 2:51 PM, Aleksandra Fedorova wrote: > >>>>> Hi, Vit. > >>>>> On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch&lt;vondruch(a)redhat.com&gt; > >>>>> wrote: > >>>>>> I was asking for ELN branch for ages and it was always denied and > >>>>>> there > >>>>>> you have it [1]. So what is the current stance on this topic? > >>>>> You were asking for a branch to overcome the issue with building a > >>>>> package in ELN. And we have a suggestion for the alternative solution > >>>>> which wouldn't require maintaining a separate eln branch forever. > >>>>> > >>>>> For gcc we are using a temporary branch for the development of a new > >>>>> feature in Fedora. > >>>>> I would have named it "gcc11" branch rather than "eln", but it is a > >>>>> bikeshedding exercise. > >>>> > >>>> This is not about naming / bikeshedding. Whatever you call it, this is > >>>> a "branch > >>>> used exclusively to build in ELN". Vít wanted this, I wanted this and > >>>> many other > >>>> Fedora/RHEL packagers wanted this. Yet you argued so passionately > >>>> against it. > >>>> For example you said: > >>>> > >>>>> I think that not having eln-branch is very important part of the > >>>>> concept as we don't want to fork Fedora. > >>>> > >>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... > >>>> > >>>> But there were countless other arguments against having such branches. > >>>> Have the > >>>> situation changed? Can other packages have eln branches as well? > >>> > >>> No, the situation has not changed. > >> > >> Glad to hear that, because that eln branch in gcc was a big surprise for > >> all of > >> us who have been told this is not an option. > >> > >>> I'll reiterate: > >>> > >>> We don't want to fork packages from the Fedora Rawhide. We don't want > >>> to provide eln-branch as an option to overcome build failures in ELN. > >>> ELN's purpose is to provide motivation and tooling for downstream > >>> developers to work on Fedora, not to share parts of Fedora > >>> infrastructure for downstream developers to do their downstream work. > >> > >> From where I stand, this gcc eln branch / update in ELN seem to be > >> primarily > >> motivated by downstream. But I agree that I might miss all the important > >> information to make that claim, so I'll try to not be biased. > > > > It would be nice if we could stop playing political games and start > > looking at the content of the work, rather than discussing who brings > > it. > > I am not playing any political games. I express my opinion that this is not > how > I expect changes to land in Fedora. There's nothing political about that. > What > do you actually mean by political in this context? > > > eln-branch to handle downstream incompatibility with rawhide and > > eln-branch made to test Fedora features are two different types of > > work. > > You said "no ELN branches". Is that no longer true? You can keep taking my words out of context, I can only keep bringing the context back as the answer. > >>> We expect downstream to have its own infrastructure and process for > >>> branched packages. And we do have it in RHEL. If you want to discuss > >>> how exactly RHEL downstream does it, I can provide more information. > >>> But I consider it to be offtopic in this mailing list, or at least in > >>> this thread. > >> > >> I thought I have a decent idea about how this is done. For example that > >> there > >> will be no eln branches and this will be done "somewhere else later". At > >> least > >> that is what we've been told when ELN was introduced. So I seem to have > >> the > >> wrong idea. Could you please summarize this? What kind of downstream > >> changes > >> will happen in ELN branches and what kind of downstream changes will > >> happen > >> "somewhere else later"? > > > > Again, you are mixing up changes made in downstream and changes in > > Fedora sponsored by downstream. > > I don't understand how is that difference relevant. You've made arguments, > you've set up expectations, now you broke them with some new "this is > actually > Fedora change, so it is possible to have eln branch" narrative. I am > completely > fine if we have a discussion about this and we agree that this is a > supported > way of doing things. Yet you've done two things: > > 1) you were absolutely and unconditionally against ELN branches I could have asked you to provide the proof for the "absolutely and unconditionally" part. But I am not going to. In my vision of a constructive discussion, when i say "By saying this I meant this" you are supposed to say "ok, now i understand it better, but it wasn't clear before" and we could move on. Note that the "move on" may include the step like "with the new knowledge I've got I want us to reconsider some decisions we made before". That would be constructive as well. And if you do want to change something given the updated knowledge - please suggest it. > 2) you've just created (or supported to create) ELN branch in gcc > > I am confused by this. This is not a game for me. I am not writing those > emails > for fun. I feel like either we've been lied to or that something has > changed > now. I'd like to see this resolved. > > > GCC11 is not a downstream change. > > > > Of course downstream is interested in landing GCC11 in Fedora as fast > > and as clean as possible, why wouldn't it. And yes downstream sponsors > > this work in Fedora. > > I know. I've newer said otherwise. I've implied that having this done in > ELN was > motivated by RHEL. The boundary between "a downstream change" and "Fedora > change" is fuzzy especially since it is both in this case. Your definition of the term "downstream change" is definitely different from mine. > >>> At the same time, we would like to use ELN as an experimental > >>> playground for features, when it makes sense, when it is helpful for > >>> Fedora and when these additional features don't contradict the primary > >>> purpose of the ELN buildroot. > >> > >> Do I understand correctly that as long as the downstream work aligns > >> with > >> "helpful for Fedora" it is OK to have an eln branch? > > > > As long as it is not a downstream work, but a feature of Fedora. > > So the new rule is "we can have ELN branches in Fedora as long as it is not > a > downstream work, but a feature of Fedora"? Can we document that rule > somewhere? > How does it work in practice? Who decides what's a feature of Fedora? https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose ---- ELN will allow us to explore new ideas like a higher baseline for CPU architectures in a way that will not disrupt the rest of Fedora. Other developers: Package maintainers who wish their package to diverge in ELN should coordinate their changes with the ELN SIG ahead of time. ---- From the very beginning we claimed that ELN Buildroot is a development environment. It originated from the Alternative Buildroot proposal, or even from the earlier idea [1] and it was documented there in the Change. Despite my best effort FESCo decided to focus the ELN discussion on the conditionals and the impact ELN may cause on regular development workflow. That's why the majority of our conversations were circling around how NOT to involve Fedora developers in the ELN work, branching and which conditionals should be allowed. I have made several attempts to explain that ELN Change is not about forcing Fedora maintainers to do the work for RHEL. But you chose not to believe me. Thus I am not really surprised that you didn't fully understand the ELN purpose back then. I told you so myself several times. You can blame me for being not clear enough, if you want, but I'd rather move on and use the current GCC11 work as an example which shows the real power of the ELN proposal, and the real benefit for Fedora which it brings. Despite the accusation of us bypassing the Fedora Change process, we are doing a different thing. GCC11 will definitely go through the Change process as usual. What we are doing right now, is that _before_ making the change to Fedora mainline, we onboard GCC maintainers, ELN SIG, and RHEL developers to be the first testers of the upcoming change. We actually use Red Hat resources and turn RHEL developers into pre-alpha-testers of the GCC11 for Fedora. (I hope this is not taken as an offence, but rather as acknowledgement of the work and effort invested in it) This activity could have been done internally in RHEL, or externally in some upstream working groups. But ELN now allows us to do this work in public in Fedora, and invite Fedora community to join it, if they _want_. As we promised by the ELN Change we have provided the platform for GCC upstream, RHEL downstream and Fedora community to collaborate on the work for Fedora, and motivation for Red Hat to sponsor this effort. > >>> We consider the update to GCC11 to be one of such features. It is not > >>> a fork of the Rawhide into a downstream branch, it is a future Fedora > >>> feature. > >> > >> Fedora features are coordinated via the Fedora change process. May we > >> please > >> have a GCC 11 Fedora change proposal that explains why is this done in > >> ELN-only > >> first instead of "just doing it"? Is see many packagers would like to be > >> involved in the process and I feel like that they have been bypassed. > > > > From where I stand I don't see many packagers who are feeling > > bypassed, I see you trying to control how development is organized for > > some other component. And I don't see the reason for that. > > I have no desire to control gcc development. I simply desire that major > changes > in Fedora are driven by the Change process. That's why we have it. It's a > disservice to our community (and that includes you and me) if we develop a > side > channel to land changes into Fedora without going trough the process. If > you > disagree with the process, we can have that discussion as well. But you > simply > decided to skip it. I don't see how pre-verification of Fedora changes is a side-channel. > > For those who are indeed interested in the work around gcc and ELN, I > > wrote this mail. Despite the way it is treated here on the mailing > > list, it is an actual invitation. > > It is innovation. I've never said it isn't. Can we please discuss > innovative > ideas and scope their impact on others before we execute them? Discuss - yes, we should. Making a Fedora Change request about setting up the development environment to prepare a Fedora Change request - no. > > But it is a preliminary work which has no impact on anyone but the > > SIGs and maintainers involved in it. It is just too early to handle it > > via the Change process. > > I disagree. The amount of responses (or rather the amount of participants) > here > IMHO proves it is not too early. > > >>> If you would like to propose another Fedora feature, and you would > >>> like to work together with the ELN SIG on it - please file a ticket in > >>> the ELN tracker [1]. > >> > >> Yet again, Fedora features should be proposed trough a change process, > >> not some > >> tracker on GitHub. Even when so, the gcc 11 update was discussed on the > >> GitHub > >> tracker only after it had the eln branch and builds from it. > > > > Fedora features can be planned and discussed anywhere. In the mailing > > list, bugzilla, github, IRC, Telegram, university hallway or Delirium > > Cafe. > > Change Process is an important and necessary step in landing the > > feature in Fedora. But it is never the first step. > > Right, sorry about that. I can discuss a Fedora feature with let's say Neal > on > Telegram. But when we decide to actually do it, we'll use a public channel > to > discuss the change with the rest of the community before we execute our > plan. > > >> There was no community involvement here, whatsoever. > > > > Please just stop excluding me from the community. > > I am not excluding you. When members of our community decide something > privately, I don't consider it as community involvement. > > > We were supposed to have this discussion right now. Unfortunately you > > choose to discuss the motivations of people doing ELN rather than the > > work they do. > > You've announced this. There was no discussion. When I read an > announcement, it > is natural that I feel excluded from the decision process. Sorry, but you just need to accept the fact that some _early development_ work in Fedora can happen without your decision on it. You don't control the content of the copr repositories of the KDE SIG for example. We need a centralized decision-making process to coordinate multiple Fedora groups, to land changes in the release and to inform users about them. Development work done in smaller groups has a risk of a wasted or overlapping effort. But it has a benefit of moving faster. There is always a trade-off, and it is up to the development team to weigh them and decide, when is the right time to start the integration effort. Ideally FESCo and Council should help dev teams with the process to encourage the early exposure, so that benefits brought by the open conversation outweigh the associated overhead. But demanding the dev teams to report their every move to FESCo is not how this help should look like.

> I don't care thta > much about my feelings wrt. this (I'm used to that), but I see that others > felt > the same. As a FESCo member, I feel like I need to represent all the > packagers > who will be impacted by this decision and who were left out from the > decison > process. > > I don't discuss the motivations, I discuss the process and the way this has > been > handled so far. I don't agree with that way. > > If ELN is part of Fedora, I strongly believe it should follow the > established > processes. The amount of energy we spend arguing about this could have been > spend by proposing a Fedora change proposal about GCC 11. If it explains > why to > do this in ELN first, I am sure that it would help to clear the confusion. > I > would support such change. (See, my "political agenda" is not to stop the > GCC > update at all. Nor it is to tell you not to do it in ELN first.) > > > Look, I do agree that communication of the ELN SIG could be done better. > > Maintaining a SIG is hard. The update of the docs I promised yesterday > > is still pending. And we discussed with Stephen the bi-weekly meetings > > but neither him nor me found the time to actually schedule them yet. > > We will. > > > > And I opened this thread exactly for the reason to provide more > > visibility into what SIG is planning to do. > > I appreciate that. However, now you received some feedback (not only from > me). I see the feedback that ELN SIG should be more open. Agreed, noted. > You can choose to treat me like a troll who enjoys playing "political > games" > (whatever that is) or you can treat me like a passionate Fedora contributor > who > feels frustrated by the fact that you do the exact things you said we > cannot > have and who genuinely believes that changes like this should go trough the > change process. > > The choice is yours. Either ELN can be perceived like a first class Fedora > citizen, or it can be perceived like downstream's private playground. I'd > rather > much see the first, so we won't have replies like "any and all FTBFS bugs > filed > against my packages on ELN will be summarily closed as NOTABUG or WONTFIX" > here. > > > Yes we need to improve. If you want to help (and btw your questions on > > other threads do count as help, so thanks for them), please do. > > > > But treating every update from ELN SIG with yet another round of > > conversation about "downstream secretly trying to contribute to > > Fedora" is also not helping. I'd rather spend time on actual work. > > > > I mean "secret downstream agenda to update GCC in Fedora", really? > > I've said: > > "How come we have eln branches when you said there will be no eln > branches? > Can we please coordinate major toolchain updates in Fedora (including > ELN) > via the Change process?" > > Yet you choose to respond to: > > "This is a secret downstream agenda to update GCC in Fedora." > > Obviously, we cannot have a constructive discussion if you choose to reply > to > accusations that I've never made. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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 [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... -- Aleksandra Fedorova bookwar _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)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

On Friday, 23 October 2020 at 14:45, Aleksandra Fedorova wrote: [...] > You can blame me for being not clear enough, if you want, but I'd > rather move on and use the current GCC11 work as an example which > shows the real power of the ELN proposal, and the real benefit for > Fedora which it brings. > > Despite the accusation of us bypassing the Fedora Change process, we > are doing a different thing. > > GCC11 will definitely go through the Change process as usual. That's reassuring.

> This activity could have been done internally in RHEL, or externally > in some upstream working groups. But ELN now allows us to do this work > in public in Fedora, and invite Fedora community to join it, if they > _want_. How can we join, then? How is this better than doing this, say, in COPR? Or a rawhide side-tag.

> As we promised by the ELN Change we have provided the platform for GCC > upstream, RHEL downstream and Fedora community to collaborate on the > work for Fedora, and motivation for Red Hat to sponsor this effort. So far I haven't seen any clear instructions on how I can, say, rebuild my packages with GCC11 to catch any fall-out early. Or where you're going to publish (if at all) the results of any rebuilds you'll perform.

On Friday, 23 October 2020 at 20:36, Jeff Law wrote: > On 10/23/20 8:01 AM, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 23 October 2020 at 14:45, Aleksandra Fedorova wrote: [...] > And as I've mentioned before on this thread, we're trying to figure out > how to drop that change in earlier than we have in the past. There's > technical as well as non-technical concerns. The time period Jakub and > myself were looking at was dropping it in at the end of stage1 upstream > gcc development which would be mid Nov. But we both feel it's > imperative that the implications be discussed here and that the change > in procedure gets highlighted in the usual change proposal. Great! I'm all for landing major GCC updates as early as it makes sense for both upstream and Fedora. Does landing the update in ELN first give us any benefits compared to landing it directly in rawhide? Everybody involved with the ELN-GCC11 proposal in this thread seems to be avoiding the answer to this question.

> >> This activity could have been done internally in RHEL, or externally > >> in some upstream working groups. But ELN now allows us to do this work > >> in public in Fedora, and invite Fedora community to join it, if they > >> _want_. > > How can we join, then? How is this better than doing this, say, in COPR? > > Or a rawhide side-tag. > > Right now the build is on a side tag and hasn't been merged into ELN (to > the best of my knowledge). Once the bits are merged in then I expect > anyone can join in the "fun". And yet the post starting this thread invited everyone to join. So which is it? Can I join now or must I wait until the tag is merged?

> >> As we promised by the ELN Change we have provided the platform for GCC > >> upstream, RHEL downstream and Fedora community to collaborate on the > >> work for Fedora, and motivation for Red Hat to sponsor this effort. > > So far I haven't seen any clear instructions on how I can, say, rebuild > > my packages with GCC11 to catch any fall-out early. Or where you're > > going to publish (if at all) the results of any rebuilds you'll perform. > We don't generally publish them -- though we've certainly discussed it > in the past and the only impediment is my time. The jenkins server > which drives my testing is on Red Hat's internal network, but there's a > publisher that would allow us to push the build info out to a public > facing server. There's nothing inherently private and/or secret about > the work. We also use that jenkins system to do wide scale testing of > GCC work before it lands in upstream GCC. I wasn't implying there was anything secret anywhere. Thanks for the background details, though. > If you have specific packages in mind, I'm happy to let you know their > build status with gcc-11. It's just some clicking. Well, let's see. I'm interested in all my packages which have gcc* in their BuildRequires. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)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

On 10/23/20 2:45 PM, Aleksandra Fedorova wrote: > Sorry, but you just need to accept the fact that some _early > development_ work in Fedora can happen without your decision on it. I except (and accept) that most of the development work in Fedora happens without my decision on it. I would like you on the other hand to accept that major changes in Fedora are coordinated trough the change process and ELN is part of Fedora.

I would also like to you to tone it down with the personal accusations you are repeatedly making towards me. If you don't, this discussion is not productive. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)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

On Fri, Oct 23, 2020 at 1:07 PM Clement Verna <cverna(a)fedoraproject.org&gt; wrote: > > > > On Fri, 23 Oct 2020 at 17:20, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: >> >> On 10/23/20 2:45 PM, Aleksandra Fedorova wrote: >> > Sorry, but you just need to accept the fact that some _early >> > development_ work in Fedora can happen without your decision on it. >> >> I except (and accept) that most of the development work in Fedora happens >> without my decision on it. >> >> I would like you on the other hand to accept that major changes in Fedora are >> coordinated trough the change process and ELN is part of Fedora. > > > This for me highlights the fact that our change process is not adapted to all parts of Fedora, in particular parts that need to move faster than the 6 month releases. I have in mind the Container base image, Fedora CoreOS and ELN, IMO these artefact depends more on the content (the set of packages included in them) rather then knowing which version of Fedora release they are based on. > The Container base image and Fedora CoreOS are releasing every couple weeks, ELN is just a rolling release, I think it is unfair to ask to follow a change request system that is design for release that happen every 6 months. > > I think we either need a new change request system that is light enough to allow these group to iterate and make changes every week or so, or we need to trust the people involved in these groups to make the best decisions for the Fedora they care about and to also notify anyone that would be impacted by these changes. > I think you're missing the point. When ELN was approved, the intent was to build Rawhide in a RHEL-ish configuration continuously.

particular plan defeats what ELN was communicated as because now there's a major deviation where people can't really participate and it's not much benefit for everyone else. Moreover, GCC 11 *will* land in Rawhide, so why not just push it there now?

GCC 11 still makes sense because it's *for* Fedora in the end too. > I also would like to point out that the Fedora's project mission statement is to explicitly allow such group to be empowered to make their decisions, at least this is what I understand in the following > > ``` > Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users. > ``` > -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)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

And there is *nothing* that stops the Change process for working in a rolling context other than people don't think of doing it. There's actually nothing wrong with this idea in itself, because at the crux of it is that there is a desire to have a side-tag to build gcc11 with a limited compose to regression test and further evaluate the development of GCC earlier. This is something I'd like to have available for more things, and it's a great idea. But there is basically no reason to stuff it into ELN other than it already exists as a gap in our existing process. Instead, I'd like to have that formally approved by FESCo in a way that releng would make a dedicated side tag for it and allow OSCI to be configured for mini-composes for the purpose of assisting in GCC development. Then it can be a regular part of GCC rebase processes.

On top of generic sidetag functionality, ELN has additional features like automated continuous rebuilds of Rawhide packages, regular composes and container builds[1], and people watching after them. Note that we have spent three months on ELN automation and it still has a lot of gaps in it.

On Fri, Oct 23, 2020 at 1:07 PM Clement Verna <cverna(a)fedoraproject.org&gt; wrote: > > > > On Fri, 23 Oct 2020 at 17:20, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: >> >> On 10/23/20 2:45 PM, Aleksandra Fedorova wrote: >> > Sorry, but you just need to accept the fact that some _early >> > development_ work in Fedora can happen without your decision on it. >> >> I except (and accept) that most of the development work in Fedora happens >> without my decision on it. >> >> I would like you on the other hand to accept that major changes in Fedora are >> coordinated trough the change process and ELN is part of Fedora. > > > This for me highlights the fact that our change process is not adapted to all parts of Fedora, in particular parts that need to move faster than the 6 month releases. I have in mind the Container base image, Fedora CoreOS and ELN, IMO these artefact depends more on the content (the set of packages included in them) rather then knowing which version of Fedora release they are based on. > The Container base image and Fedora CoreOS are releasing every couple weeks, ELN is just a rolling release, I think it is unfair to ask to follow a change request system that is design for release that happen every 6 months. > > I think we either need a new change request system that is light enough to allow these group to iterate and make changes every week or so, or we need to trust the people involved in these groups to make the best decisions for the Fedora they care about and to also notify anyone that would be impacted by these changes. > I think you're missing the point. When ELN was approved, the intent was to build Rawhide in a RHEL-ish configuration continuously. This particular plan defeats what ELN was communicated as because now there's a major deviation where people can't really participate and it's not much benefit for everyone else. Moreover, GCC 11 *will* land in Rawhide, so why not just push it there now? A Change proposal for GCC 11 still makes sense because it's *for* Fedora in the end too.

* Jonathan Wakely: > Dropping GCC 11 into rawhide now would mean I can't make certain > ABI-breaking changes to the C++20 library in upstream GCC, because it > would be landing on real users' machines. Which means I lose several > weeks of GCC's stage 1 development. No thanks. This is for C++20 library support only, right?

Not much software in Fedora uses the C++ standard library (even at older C++ versions), so impact on Fedora itself should be limited.

I can help you with diagnosing required ABI transitions and package rebuilds.

* Jonathan Wakely: > On 28/10/20 13:31 +0100, Florian Weimer wrote: >>* Jonathan Wakely: >> >>> Dropping GCC 11 into rawhide now would mean I can't make certain >>> ABI-breaking changes to the C++20 library in upstream GCC, because it >>> would be landing on real users' machines. Which means I lose several >>> weeks of GCC's stage 1 development. No thanks. >> >>This is for C++20 library support only, right? > > Right. > >>Not much software in Fedora uses the C++ standard library (even at older >>C++ versions), so impact on Fedora itself should be limited. > > On Fedora iteself, yes. But not necessarily on users compiling their > own code (or other third-party libraries) using the system compiler. Does GCC 10 have a stable ABI for C++20 features? It's still experimental. So I think it's a wash for rawhide users after all?

On Fri, 23 Oct 2020 at 17:20, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: > On 10/23/20 2:45 PM, Aleksandra Fedorova wrote: > > Sorry, but you just need to accept the fact that some _early > > development_ work in Fedora can happen without your decision on > > it. > > I except (and accept) that most of the development work in Fedora > happens without my decision on it. > > I would like you on the other hand to accept that major changes in > Fedora are coordinated trough the change process and ELN is part of > Fedora. This for me highlights the fact that our change process is not adapted to all parts of Fedora, in particular parts that need to move faster than the 6 month releases. I have in mind the Container base image, Fedora CoreOS and ELN, IMO these artefact depends more on the content (the set of packages included in them) rather then knowing which version of Fedora release they are based on.

The Container base image and Fedora CoreOS are releasing every couple weeks, ELN is just a rolling release, I think it is unfair to ask to follow a change request system that is design for release that happen every 6 months.

I think we either need a new change request system that is light enough to allow these group to iterate and make changes every week or so, or we need to trust the people involved in these groups to make the best decisions for the Fedora they care about and to also notify anyone that would be impacted by these changes. I also would like to point out that the Fedora's project mission statement is to explicitly allow such group to be empowered to make their decisions, at least this is what I understand in the following ``` *Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.* *```*

On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: > On 10/22/20 2:51 PM, Aleksandra Fedorova wrote: >> Hi, Vit. >> On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch&lt;vondruch(a)redhat.com&gt; wrote: >>> I was asking for ELN branch for ages and it was always denied and there >>> you have it [1]. So what is the current stance on this topic? >> You were asking for a branch to overcome the issue with building a >> package in ELN.

>> And we have a suggestion for the alternative solution >> which wouldn't require maintaining a separate eln branch forever.

>> >> For gcc we are using a temporary branch for the development of a new >> feature in Fedora. >> I would have named it "gcc11" branch rather than "eln", but it is a >> bikeshedding exercise. > This is not about naming / bikeshedding. Whatever you call it, this is a "branch > used exclusively to build in ELN". Vít wanted this, I wanted this and many other > Fedora/RHEL packagers wanted this. Yet you argued so passionately against it. > For example you said: > >> I think that not having eln-branch is very important part of the >> concept as we don't want to fork Fedora. > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o... > > But there were countless other arguments against having such branches. Have the > situation changed? Can other packages have eln branches as well? No, the situation has not changed. I'll reiterate: We don't want to fork packages from the Fedora Rawhide. We don't want to provide eln-branch as an option to overcome build failures in ELN. ELN's purpose is to provide motivation and tooling for downstream developers to work on Fedora, not to share parts of Fedora infrastructure for downstream developers to do their downstream work.

We expect downstream to have its own infrastructure and process for branched packages. And we do have it in RHEL. If you want to discuss how exactly RHEL downstream does it, I can provide more information. But I consider it to be offtopic in this mailing list, or at least in this thread. At the same time, we would like to use ELN as an experimental playground for features, when it makes sense, when it is helpful for Fedora and when these additional features don't contradict the primary purpose of the ELN buildroot. We consider the update to GCC11 to be one of such features. It is not a fork of the Rawhide into a downstream branch, it is a future Fedora feature. It is also not the only one, which we can handle through ELN. We were considering the update of the baseline of the x86 cpu's to be such a feature, but then it was discarded. The other example would be the Default Module Streams setup. If you would like to propose another Fedora feature, and you would like to work together with the ELN SIG on it - please file a ticket in the ELN tracker [1]. We are open to the ideas, and we may consider options, including branching, to make it work. [1] https://github.com/fedora-eln/eln/issues > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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

On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova <alpha(a)bookwar.info&gt; 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. > > We would like to invite everyone to join this effort. > > The work is currently tracked on Github: > https://github.com/fedora-eln/eln/issues/8 > > Once GCC11 is merged to the eln tag in koji, one would be able to use > it via, for example, mock or container environment: > quay.io/fedoraci/fedora:eln-x86_64 > > For more info on ELN please refer to ELN Docs (as soon as I update > them, which hopefully happens later today): > > https://docs.fedoraproject.org/en-US/eln/ > Why are you not just doing this in Rawhide? I feel like we've been screwed now because the whole point was that ELN branches weren't going to exist, and now we have one in the most important package!

Why are you not just doing this in Rawhide?

On Thu, Oct 22, 2020 at 9:03 AM Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org&gt; wrote: > > On 22.10.2020 14:53, Neal Gompa wrote: > > Why are you not just doing this in Rawhide? > > Finally they made the right decision. F32 was built by a completely > broken version of GCC, full of regressions. > > As a Fedora maintainer, I don't want to be a GCC alpha tester again, > even in Rawhide. Release candidate versions are okay, but trunk is not. > That would be bad, since the only reason GCC releases are even as good as they are is because they get tested with rebuilding the corpus of Fedora Rawhide software. That's why we merge them in so early in the first place.

On 10/22/20 6:53 AM, Neal Gompa wrote: > On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova <alpha(a)bookwar.info&gt; 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. >> >> We would like to invite everyone to join this effort. >> >> The work is currently tracked on Github: >> https://github.com/fedora-eln/eln/issues/8 >> >> Once GCC11 is merged to the eln tag in koji, one would be able to use >> it via, for example, mock or container environment: >> quay.io/fedoraci/fedora:eln-x86_64 >> >> For more info on ELN please refer to ELN Docs (as soon as I update >> them, which hopefully happens later today): >> >> https://docs.fedoraproject.org/en-US/eln/ >> > Why are you not just doing this in Rawhide? I feel like we've been > screwed now because the whole point was that ELN branches weren't > going to exist, and now we have one in the most important package! From a timing standpoint we're trying to get ELN up and running with gcc-11 right now.  The earliest Jakub was comfortable dropping gcc-11 snapshots into rawhide was after stage1 development closes for upstream gcc (mid-Nov) and even that probably needs to be discussed with FESCO and the wider Fedora dev community as it is potentially disrupting (regardless of how much testing and fixing I've already done in rawhide in preparation for gcc-11).  Delaying gcc-11 into ELN would throw everything downstream of that off from a scheduling standpoint. But I very much agree that GCC should be moving into rawhide earlier than has been done in the past.  In an ideal world it would have gone in just after F33 branched and updated regularly.

On Fri, Oct 23, 2020 at 10:37:29AM +0300, Panu Matilainen wrote: >> But I very much agree that GCC should be moving into rawhide earlier >> than has been done in the past.  In an ideal world it would have gone in >> just after F33 branched and updated regularly. > > Big +1 on that. > > Right after branching rawhide tends to be relatively quiet as the just > branched version gets most of the attention, so any mishaps are fairly > contained and cause minimal disruption, but there's always enough going on > that you do get plenty of testing. And when the general focus starts > shifting back to rawhide and the next release, the worst initial kinks have > already been worked out. > > That's how we try to land new rpm versions too, and it has proven to work > very well for all parties AFAICS. And whenever we miss that slot, there's > pain, suffering and lots of unnecessary stress. The thing is that GCC is a moving target at that point, while you can fix up packages to deal with GCC at certain date, in a week or two you might need to do it again, or there could be ABI changes etc. Which is why I'm suggesting at least end of GCC stage1, which still doesn't guarantee any of that, at least major new features shouldn't be making it in (unless they were posted already before that), and people start focusing on fixing bugs (some bugs are fixed continually, but a concerted effort to fix bugs starts at end of stage1).

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.

Hi, Daniel, On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé <berrange(a)redhat.com&gt; 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.

On 10/22/20 8:09 AM, Daniel P. Berrangé wrote: > 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.

On Thu, Oct 22, 2020 at 04:03:33PM +0200, Aleksandra Fedorova wrote: > 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.

I do think we need to make it easier for a Fedora package maintainer to get the gcc-11 bits so that if there's a need to debug a bad interaction between gcc-11 and a package they can.

On 10/22/20 8:27 AM, Petr Pisar wrote: > On Thu, Oct 22, 2020 at 08:10:02AM -0600, Jeff Law wrote: >> I do think we need to make it easier for a Fedora package maintainer to >> get the gcc-11 bits so that if there's a need to debug a bad interaction >> between gcc-11 and a package they can. >> > gcc-11 was built into a side tag. Each build target has a repository in Koji. > This one is > <http://kojipkgs.fedoraproject.org/repos/eln-build-side-32479/latest/$base...;. > > If you worry about ELN-Fedora compatibility, create a new side tag intheriting > from f34 and rebuilt gcc-11 there. Or build a module that anyone interested > can enable on his system. Sorry, I wasn't terribly clear. So last year when I was testing gcc-10 against Fedora one of the recurring issues we had was that if I needed input from a package maintainer on an issue flagged by gcc-10 we had no good way for the package maintainer to get gcc-10 rpms to do any investigation on their own. With the gcc-11 side tag build and eventual landing in ELN that issue should be much better.  So if I need to sync with a package maintainer on an issue, we have a way to make that happen.

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 :-(

On Thu, 22 Oct 2020 at 14:28, Aleksandra Fedorova <alpha(a)bookwar.info <mailto:alpha@bookwar.info>> 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 think this is one of the great benefits of having ELN and being able to use it to start integrating such changes. I am looking forward, seeing if that makes it easier for GCC11 to land in rawhide, I would be nice if you could share the issues that were caught during that work in ELN.

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. We would like to invite everyone to join this effort. The work is currently tracked on Github: https://github.com/fedora-eln/eln/issues/8 Once GCC11 is merged to the eln tag in koji, one would be able to use it via, for example, mock or container environment: quay.io/fedoraci/fedora:eln-x86_64 For more info on ELN please refer to ELN Docs (as soon as I update them, which hopefully happens later today): https://docs.fedoraproject.org/en-US/eln/