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]

 



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.

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"?

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?

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.

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. There was no community involvement here, whatsoever. You say this has nothing to do with downstream, but it surely seems like it is driven by downstream discussions.

I'd be happy to be wrong here. Could you please point me to the Fedora discussion about upgrading gcc in ELN first?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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