On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 10/22/20 6:33 PM, Aleksandra Fedorova wrote: > > On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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<vondruch@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/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. 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. > > 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? > > > 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. > You say this has nothing to do with > downstream, but it surely seems like it is driven by downstream discussions. I don't say it has nothing to do with downstream. I am saying that GCC11 is not a downstream change. > I'd be happy to be wrong here. Could you please point me to the Fedora > discussion about upgrading gcc in ELN first? 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? -- 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
