----- Original Message ----- > From: "Aleksandra Fedorova" <al...@bookwar.info> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > 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 <mhron...@redhat.com> wrote: > > > > On 10/23/20 11:52 AM, Aleksandra Fedorova wrote: > > > On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok <mhron...@redhat.com> wrote: > > >> > > >> On 10/22/20 6:33 PM, Aleksandra Fedorova wrote: > > >>> On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok <mhron...@redhat.com> > > >>> 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<vondr...@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.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/ > > >>>> > > >>>> 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.
So basically you are saying that ELN can bypass the Fedora change process privately without the community involvement, right? Sorry but I don't think the decision making process of 1-2 people which will impact hundreds or thousands, consists as a "community involvement". This is a great violation of expectations the ELN SIG set, a violation of promises and honestly trying to insult the people who are opposed to that (political game? seriously?) just shows that this dishonesty is not something that makes the Fedora community a welcome place. I would urge you to reconsider not also this specific decision, but also how you respond to your fellow contributors, if you indeed consider yourself part of the community. > > 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@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 > > [1] > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3Z5SMF6CPL3MK2CNYPUW4OZYMA6TZJBN/ > -- > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat _______________________________________________ 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
