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/
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):
Hi, Vit. On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch vondruch@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.
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):
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Ondruchvondruch@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/...
But there were countless other arguments against having such branches. Have the situation changed? Can other packages have eln branches as well?
On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok mhroncok@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 Ondruchvondruch@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/...
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 6:33 PM, Aleksandra Fedorova wrote:
On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok mhroncok@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 Ondruchvondruch@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/...
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:
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?
See the earlier announcement about the z13 baseline change in ELN. Once we have GCC 11 in ELN, further baseline changes may be forthcoming. These changes can all be implemented using %{?rhel} conditionals. I do not see a need for a redhat-rpm-config eln branch as the result of these requirements.
I do not think the Fedora Change process applies to parts of %{?rhel} conditionals that are inactive in Fedora. In principle, it would make my life easier if such changes had to pass public Fesco-like review, but I feel it's too late for such a policy change for the Fedora 34 and 35 cycles.
Thanks, Florian
On Thu, Oct 22, 2020 at 1:28 PM Florian Weimer fweimer@redhat.com wrote:
- Miro Hrončok:
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?
See the earlier announcement about the z13 baseline change in ELN. Once we have GCC 11 in ELN, further baseline changes may be forthcoming. These changes can all be implemented using %{?rhel} conditionals. I do not see a need for a redhat-rpm-config eln branch as the result of these requirements.
I do not think the Fedora Change process applies to parts of %{?rhel} conditionals that are inactive in Fedora. In principle, it would make my life easier if such changes had to pass public Fesco-like review, but I feel it's too late for such a policy change for the Fedora 34 and 35 cycles.
The Fedora 34 change submission deadline isn't until January, so there's plenty of time.
On 10/22/20 7:28 PM, Florian Weimer wrote:
I do not think the Fedora Change process applies to parts of %{?rhel} conditionals that are inactive in Fedora.
Except that they apply in Fedora ELN now. And since this *will* affect Fedora contributors, I belive that it should follow Fedora processes.
ELN is not a private space for downstream only development, it is part of Fedora.
On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok mhroncok@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 mhroncok@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 Ondruchvondruch@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/...
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
On 10/23/20 11:52 AM, Aleksandra Fedorova wrote:
On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok mhroncok@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 mhroncok@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 Ondruchvondruch@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/...
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?
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 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.
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?
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.
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?
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. 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). 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.
On Fri, Oct 23, 2020 at 12:40 PM Miro Hrončok mhroncok@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 mhroncok@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 mhroncok@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 Ondruchvondruch@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/...
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:
- 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.
- 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/...
----- Original Message -----
From: "Aleksandra Fedorova" alpha@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 mhroncok@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 mhroncok@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 mhroncok@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 Ondruchvondruch@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/...
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:
- 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.
- 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-leave@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/... -- Aleksandra Fedorova bookwar _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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.
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.
I notice how you're not mentioning general Fedora packagers here at all. You're explaining what you're doing, but not why.
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)
No, I'm fine with RHEL devs doing the early integration work. I appreciate Red Hat providing resources for this work, too. Still no answer why you wanted to do it this way.
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.
Regards, Dominik
On 10/23/20 8:01 AM, Dominik 'Rathann' Mierzejewski wrote:
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.
Absolutely.
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.
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".
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.
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.
jeff
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
On Fri, Oct 23, 2020 at 9:58 PM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
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.
The question why GCC11 can not land in Rawhide right now has been answered by Jakub.
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?
I did share the details of the upcoming update in advance. Specifically for the purpose that people can join the conversation about it in the issue I linked.
If you are interested in the coordination of this update, or you can join now and provide your feedback. If you are only interested in the states of packages built with GCC11, you need to wait for until the update 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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.
On Fri, 23 Oct 2020 at 17:20, Miro Hrončok mhroncok@redhat.com 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.* *```*
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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@fedoraproject.org wrote:
On Fri, 23 Oct 2020 at 17:20, Miro Hrončok mhroncok@redhat.com 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.
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 Fri, 23 Oct 2020 at 19:55, Neal Gompa ngompa13@gmail.com wrote:
On Fri, Oct 23, 2020 at 1:07 PM Clement Verna cverna@fedoraproject.org wrote:
On Fri, 23 Oct 2020 at 17:20, Miro Hrončok mhroncok@redhat.com 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.
I agree that I missed that point because honestly it does not interest me. What I am seeing is that we have a group of people that are interested in experimenting and doing things differently in Fedora (The ELN SIG) and so far every time their trials are met with a lot of push back. I personally don't care if ELN is not what was communicated originally as long as it brings value to the people working on it, and it does not make other people live worse.
There is so much energy spent pointing fingers at each other, it is really demoralizing :(, Personally If I was in the ELN SIG I would feel unwelcome and unwanted in Fedora, and would really consider just quitting trying to do anything new in this community.
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.
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, andcontainers that enables software developers and community members to build tailored solutions for their users.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 4:05 PM Clement Verna cverna@fedoraproject.org wrote:
On Fri, 23 Oct 2020 at 19:55, Neal Gompa ngompa13@gmail.com wrote:
On Fri, Oct 23, 2020 at 1:07 PM Clement Verna cverna@fedoraproject.org wrote:
On Fri, 23 Oct 2020 at 17:20, Miro Hrončok mhroncok@redhat.com 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.
I agree that I missed that point because honestly it does not interest me. What I am seeing is that we have a group of people that are interested in experimenting and doing things differently in Fedora (The ELN SIG) and so far every time their trials are met with a lot of push back. I personally don't care if ELN is not what was communicated originally as long as it brings value to the people working on it, and it does not make other people live worse.
There is so much energy spent pointing fingers at each other, it is really demoralizing :(, Personally If I was in the ELN SIG I would feel unwelcome and unwanted in Fedora, and would really consider just quitting trying to do anything new in this community.
This is a very odd way to take this. Yes, Fedora is a great and large community. And one thing that makes us successful is that we're good at defining scope and following through on ideas and concepts to evolve the Linux platform.
But it's not a free-for-all. Using one way everyone expects you to do things as a way to do something else entirely will take people by surprise. Even more so when it's completely unprecedented.
For example, even Rawhide gating stuff[1] went through the Changes process. Setting up ELN itself[2] went through that process. Factory 2.0 and Pagure[3] went through that. And so on.
What you're advocating for is something along the lines of the openSUSE model where people just announce and do it. In my experience, that is how you paralyze people into being unable to figure out how to coordinate and scale change effort, while simultaneously making it difficult for newer folks to find a path to make their mark in the community.
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.
[1]: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages [2]: https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose [3]: https://fedoraproject.org/wiki/Changes/ArbitraryBranching
On Friday, 23 October 2020 at 22:42, Neal Gompa wrote: [...]
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.
This is very well said. +1. Thanks Neal!
Regards, Dominik
On Fri, Oct 23, 2020 at 10:43 PM Neal Gompa ngompa13@gmail.com wrote:
..skipped..
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.
Collaboration between GCC11 maintainers and ELN SIG allows us to save the resources, both technical and human, and use the already existing infrastructure pieces built for ELN to temporarily (for three weeks) test the GCC11 too.
You are suggesting now that someone goes and duplicates this work. If you know people somewhere ready to do this, let them step in and we can discuss it.
I also don't see why you think that landing GCC11 in ELN three weeks ahead on Rawhide contradicts with the idea of ELN being a development preview of future RHEL.
[1] https://docs.fedoraproject.org/en-US/eln/deliverables/
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 Saturday, 24 October 2020 at 12:28, Aleksandra Fedorova wrote: [...]
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.
Very cool. That's exactly what was missing in the original announcement. If you had included that, I'm sure there would have been a lot less misunderstanding. Please keep that in mind and make sure you include not only "what you're doing" but also "why you're doing it that way" in future announcements.
Can we assume that those features are going to be part of regular rawhide at some not-too-distant point in the future?
Regards, Dominik
On Mon, Oct 26, 2020 at 12:20 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Saturday, 24 October 2020 at 12:28, Aleksandra Fedorova wrote: [...]
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.
Very cool. That's exactly what was missing in the original announcement. If you had included that, I'm sure there would have been a lot less misunderstanding. Please keep that in mind and make sure you include not only "what you're doing" but also "why you're doing it that way" in future announcements.
As I said above, communication is not an easy task. And I may skip some parts because they seem obvious to me, or because I've just forgotten to mention. In such cases, please ask. I will try to answer and eventually document the answers in the ELN docs.
Can we assume that those features are going to be part of regular rawhide at some not-too-distant point in the future?
Which features do you mean?
Regular composes and containers builds are already available in Rawhide. Most features of ELN are about how to make a generic sidetag look more like Rawhide. So we rather bring features from Rawhide to ELN, not the other way. For example, one of the next steps is to support the rebuild of dynamic sidetags, not just mirror individual builds from Rawhide as we do now.
I think one of the future goals for ELN automation should be to make it less ELN-specific and more generic, so that, as Neal suggested, we may apply the same approach for other activities. But this needs some time and effort.
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 23/10/20 13:46 -0400, Neal Gompa wrote:
On Fri, Oct 23, 2020 at 1:07 PM Clement Verna cverna@fedoraproject.org wrote:
On Fri, 23 Oct 2020 at 17:20, Miro Hrončok mhroncok@redhat.com 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.
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.
The ELN team are willing to deal with the instability of GCC 11 while in stage 1, I don't think the rest of Fedora and rawhide users are willing, or should be expected to deal with it.
* 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.
Thanks, Florian
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.
I can help you with diagnosing required ABI transitions and package rebuilds.
I'd rather just be able to change things freely during stage 1 :-)
* 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?
Thanks, Florian
On 28/10/20 14:35 +0100, Florian Weimer wrote:
- 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?
Yes, that's true. But at least there's a "flag day" when GCC 11 arrives in rawhide, when it's pretty reasonable to expect things to change.
On 10/28/20 7:29 AM, Jonathan Wakely wrote:
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.
I can help you with diagnosing required ABI transitions and package rebuilds.
I'd rather just be able to change things freely during stage 1 :-)
The only thing on the table in the immediate term is to start dropping gcc snapshots into rawhide after stage1 development closes -- ie mid Nov. So it shouldn't impact your desire to be able to break things during gcc stage1 :-)
While I think we should seriously consider even earlier drops, that would be in the gcc-12/F36 timeframe and would require a distinct change proposal and I think it would be significantly more controversial.
Jeff
On Friday, 23 October 2020 at 19:06, Clement Verna wrote:
On Fri, 23 Oct 2020 at 17:20, Miro Hrončok mhroncok@redhat.com 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.
But it matters which Fedora version they're based on, because there are often major differences in package versions involved. Which often means API changes.
You think the Change process is not suitable, fine. Propose an additional one for the faster moving parts. I have no problem with that. What I do have a problem with is small groups of people making major changes in Fedora without discussing them with the rest of the community. This whole idea would have looked a lot better, if the initial e-mail said something like:
Listen, everyone, we have this idea to use ELN buildroot to do an automated rebuild of a subset of Fedora packages using GCC11 snapshot. It's better than doing it in COPR or in rawhide directly because X and Y. We have GCC devs on board as well as a number of RHEL devs to fix issues. What do you think?
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.
As above, send a proposal before you actually implement it. You'll certainly get constructive feedback. What I and many other people really hate is being presented with decisions already made and solutions already determined. It makes us feel left out.
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.* *```*
It is also meant to be inclusive for anyone who wants to help. We are supposed to build consensus on how we do things: https://docs.fedoraproject.org/en-US/project/#_friends
Regards, Dominik
On Friday, 23 October 2020 at 11:52, Aleksandra Fedorova wrote:
On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok mhroncok@redhat.com wrote:
On 10/22/20 6:33 PM, Aleksandra Fedorova wrote:
[...]
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 couldn't care less who brings it. We're discussing "how" it's brought in. And I don't have the slightest idea why you're accusing Miro of playing a political game, whatever that means. There's nothing political in what he wrote in my opinion.
eln-branch to handle downstream incompatibility with rawhide and eln-branch made to test Fedora features are two different types of work.
As far as I remember the rule was: "no eln branches", period. Nothing about "oh, it's fine if it's to address downstream incompatibility". Has that changed?
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.
Why do you need an ELN branch (which the ELN Change proposal said would never happen), then? Why can't you do it in rawhide directly via a Fedora Change?
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.
If it's a feature of Fedora, why are you trying to do it outside the standard Fedora process?
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 am feeling bypassed and several others have expressed similar impression in this very thread. Development of a major feature in Fedora should be done via the Change process. Major GCC updates have been done this way as long as I remember. If you want to do it another way, then I think you should discuss it with FESCo first.
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.
The feedback you received clearly indicates otherwise.
[...]
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.
Again, why are you trying to do it in a downstream branch, then. Especially when we were told there would be no downstream branches?
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.
I don't see how such conclusion could be drawn from Miro's messages. Miro is not asking why you're doing this at all, he's asking why are you doing this in this particular way that's bypassing standard Fedora process and going contrary to previous assurances. You have not provided any explanation for this divergence.
[...]
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?
All we're asking is that you do this in rawhide, via the Change process, as usual. Or, if you have a good reason to follow a different process, go to FESCo and explain before turning things upside down.
From where I stand, this looks like "The ELN SIG is doing a GCC11 update for Fedora in eln branch which they previously said would never be created."
This feels... wrong.
Regards, Dominik
Dne 22. 10. 20 v 18:33 Aleksandra Fedorova napsal(a):
On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok mhroncok@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 Ondruchvondruch@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.
To reiterate, I was asking branch to cut of some dependency chains, to stop ELN rebuilding (and failing rebuilding) Ruby on Rails, which won't go into RHEL. I was asking branch to keep Fedora free to innovate.
When I was asking branch, I was also suggesting to do "git rebase" from Fedora and I was willing to fix the conflict in case there are some.
And we have a suggestion for the alternative solution which wouldn't require maintaining a separate eln branch forever.
But that is not acceptable. I am not provided any options, only the right choices.
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/...
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.
I might be exception, as a downstream developer, I am highly motivated to work on Fedora and I am dedicated to make Fedora successful. But at the same time, I am denied to be provided with the tools which I need to make the job done. Surprisingly, others are free to use the same tools I am asking.
Anyway, I'll deal with it in CentOS streams or wherever else it will be necessary.
Vít
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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@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.
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):
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!
-- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, Oct 22, 2020 at 2:54 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova 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.
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):
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!
"We're screwed" is a bit harsh, but beyond that, I second to what Neal said.
Historically, new gcc releases have landed in rawhide right before a mass rebuild and then there's often been fallout in the mass rebuild due to the new compiler. And then afterwards there's a lot of crunch to get all of the fallout from the new compiler fixed quickly before the Beta release.
I think it would be much smoother to introduce new gcc releases earlier in the cycle (as in, now would be a good time) to give packagers time to fix things up before the mass rebuild starts.
On 10/22/20 7:02 AM, Kalev Lember wrote:
On Thu, Oct 22, 2020 at 2:54 PM Neal Gompa <ngompa13@gmail.com mailto:ngompa13@gmail.com> wrote:
On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova <alpha@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. > > 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 <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 <http://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/ <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!"We're screwed" is a bit harsh, but beyond that, I second to what Neal said.
Historically, new gcc releases have landed in rawhide right before a mass rebuild and then there's often been fallout in the mass rebuild due to the new compiler. And then afterwards there's a lot of crunch to get all of the fallout from the new compiler fixed quickly before the Beta release.
I think it would be much smoother to introduce new gcc releases earlier in the cycle (as in, now would be a good time) to give packagers time to fix things up before the mass rebuild starts.
I'm very much trying to get things moving in this direction. The current model of waiting until just before the mass rebuild for even numbered Fedora releases is far from ideal. It's hard on the Fedora maintainer community as a whole and it's hard on the GCC community. We'd both be better served with earlier drops of the development versions of gcc into rawhide, IMHO.
While we may not get to the state that glibc is in (dropping in development snapshots weekly), I do think we should be looking at a drop of a gcc-11 snapshot into rawhide roughly at the same time that gcc-11's stage1 development window closes (mid-Nov) with semi-regular updates from that point.
Jeff
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.
On Thu, Oct 22, 2020 at 9:03 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org 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 Thu, Oct 22, 2020 at 6:06 AM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Oct 22, 2020 at 9:03 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org 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.
And now we're merging it in earlier for a subset of the distribution. This is a net-positive, right? If your position is that earlier is better, we're doing it earlier, and this is better. If your position is that it doesn't go far enough, consider the contrary feedback from some people here where some maintainers are concerned about potential make-work for themselves. This seems like a good compromise position to me.
On 10/22/20 6:53 AM, Neal Gompa wrote:
On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova 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.
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):
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.
Jeff
On 10/22/20 5:06 PM, Jeff Law wrote:
On 10/22/20 6:53 AM, Neal Gompa wrote:
On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova 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.
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):
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.
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.
- Panu -
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).
Jakub
On 10/23/20 10:52 AM, Jakub Jelinek wrote:
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).
Oh, I didn't mean throwing a random development snapshot into rawhide, that's not what we do with rpm either. We start with an alpha which based on the above means roughly similar things as your stage1, and then work through beta and rc(s) to final. Of course it requires aligning the release cycles to Fedora cycles to a large degree, but at least for us it has been well worth it.
- Panu -
* Jakub Jelinek:
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).
And ELN is different here because it has a rebuild number in the dist tag, so it is much easier to do rebuilds (bump the rebuild number, do the required builds, done).
We have walked back ABI versions in Fedora rawhide in the past and know how to do it, but it requires per-package dist-git upgrades for fresh NVRs.
Thanks, Florian
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 :-(
Now rawhide will be the latest stream, except for when it is not the latest stream :-(
Regards, Daniel
Hi, Daniel,
On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote:
Hi, all,
this is the informational message, no action required.
Upon agreement between gcc maintainers and ELN SIG we would like to switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
Though ELN is defined as the buildroot where Fedora Rawhide code is rebuilt into EL-like environment, in the ELN proposal we also mentioned that ELN can be used to test certain buildroot-related features on the side so it doesn't block Fedora Rawhide development.
We think that GCC11 is one such feature, where we can benefit from testing it first on a small subset of the Fedora content in a separate environment.
I'm not very enthusiastic about this change.
Fedora maintainers can largely ignore ELN right now, because if stuff works in rawhide, it will generally work in ELN, and someone else is taking care of ELN builds.
New GCC releases almost always trigger new compile warnings or bugs in code. So by pushing GCC 11 into ELN, it feels like we're making it much more likely that ELN builds will fail, and now Fedora maintainers have to debug ELN specific problems that won't reproduce in rawhide branches :-(
Expectations for Fedora maintainers does not change. ELN is a development playground. Think about sidetag, with slightly better automation around it.
We provide ELN as the opportunity, option to play with early releases of the GCC11 on the side. We are not requiring Fedora maintainers to participate, we are inviting people who may be interested in this work.
Now rawhide will be the latest stream, except for when it is not the latest stream :-(
Fedora Rawhide is the latest stream of Fedora.
This doesn't contradict to the fact that certain "heavy" changes can be tested in the sidetag or copr repositories before landing in Rawhide. This is the usual practice for many subprojects, from desktop to Python. We are not moving the usual gcc11-related work from Rawhide into ELN, we are adding the preliminary step to it.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
-- Aleksandra Fedorova bookwar
On Thu, Oct 22, 2020 at 04:03:33PM +0200, Aleksandra Fedorova wrote:
Hi, Daniel,
On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote:
Hi, all,
this is the informational message, no action required.
Upon agreement between gcc maintainers and ELN SIG we would like to switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
Though ELN is defined as the buildroot where Fedora Rawhide code is rebuilt into EL-like environment, in the ELN proposal we also mentioned that ELN can be used to test certain buildroot-related features on the side so it doesn't block Fedora Rawhide development.
We think that GCC11 is one such feature, where we can benefit from testing it first on a small subset of the Fedora content in a separate environment.
I'm not very enthusiastic about this change.
Fedora maintainers can largely ignore ELN right now, because if stuff works in rawhide, it will generally work in ELN, and someone else is taking care of ELN builds.
New GCC releases almost always trigger new compile warnings or bugs in code. So by pushing GCC 11 into ELN, it feels like we're making it much more likely that ELN builds will fail, and now Fedora maintainers have to debug ELN specific problems that won't reproduce in rawhide branches :-(
Expectations for Fedora maintainers does not change. ELN is a development playground. Think about sidetag, with slightly better automation around it.
We provide ELN as the opportunity, option to play with early releases of the GCC11 on the side. We are not requiring Fedora maintainers to participate, we are inviting people who may be interested in this work.
As Fedora maintainer I've been sent details of ELN failures / bugs, and asked to deal with fixes for ELN branches, so there's clearly an expectation placed on Fedora maintainers to be engaged in ELN.
Regards, Daniel
On 10/22/20 8:09 AM, Daniel P. Berrangé wrote:
On Thu, Oct 22, 2020 at 04:03:33PM +0200, Aleksandra Fedorova wrote:
Hi, Daniel,
On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote:
Hi, all,
this is the informational message, no action required.
Upon agreement between gcc maintainers and ELN SIG we would like to switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
Though ELN is defined as the buildroot where Fedora Rawhide code is rebuilt into EL-like environment, in the ELN proposal we also mentioned that ELN can be used to test certain buildroot-related features on the side so it doesn't block Fedora Rawhide development.
We think that GCC11 is one such feature, where we can benefit from testing it first on a small subset of the Fedora content in a separate environment.
I'm not very enthusiastic about this change.
Fedora maintainers can largely ignore ELN right now, because if stuff works in rawhide, it will generally work in ELN, and someone else is taking care of ELN builds.
New GCC releases almost always trigger new compile warnings or bugs in code. So by pushing GCC 11 into ELN, it feels like we're making it much more likely that ELN builds will fail, and now Fedora maintainers have to debug ELN specific problems that won't reproduce in rawhide branches :-(
Expectations for Fedora maintainers does not change. ELN is a development playground. Think about sidetag, with slightly better automation around it.
We provide ELN as the opportunity, option to play with early releases of the GCC11 on the side. We are not requiring Fedora maintainers to participate, we are inviting people who may be interested in this work.
As Fedora maintainer I've been sent details of ELN failures / bugs, and asked to deal with fixes for ELN branches, so there's clearly an expectation placed on Fedora maintainers to be engaged in ELN.
And that's unfortunate. I've tried to signal to the ELN/Bakery folks that they should be contacting me first as any build failure related to teh compiler change I've probably already seen in one form or another. But it doesn't seem to have sunk in.
jeff
On Thu, Oct 22, 2020 at 7:15 AM Jeff Law law@redhat.com wrote:
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.
I don't believe anybody has yet been asked to fix gcc-11 build failures. I take his note to be about earlier build failures that occurred with gcc 10, but not because of gcc 10.
Hi, Jeff,
On Thu, Oct 22, 2020 at 4:14 PM Jeff Law law@redhat.com wrote:
On 10/22/20 8:09 AM, Daniel P. Berrangé wrote:
On Thu, Oct 22, 2020 at 04:03:33PM +0200, Aleksandra Fedorova wrote:
Hi, Daniel,
On Thu, Oct 22, 2020 at 3:01 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Thu, Oct 22, 2020 at 02:27:13PM +0200, Aleksandra Fedorova wrote:
Hi, all,
this is the informational message, no action required.
Upon agreement between gcc maintainers and ELN SIG we would like to switch ELN buildroot to use GCC11 ahead of Fedora Rawhide.
Though ELN is defined as the buildroot where Fedora Rawhide code is rebuilt into EL-like environment, in the ELN proposal we also mentioned that ELN can be used to test certain buildroot-related features on the side so it doesn't block Fedora Rawhide development.
We think that GCC11 is one such feature, where we can benefit from testing it first on a small subset of the Fedora content in a separate environment.
I'm not very enthusiastic about this change.
Fedora maintainers can largely ignore ELN right now, because if stuff works in rawhide, it will generally work in ELN, and someone else is taking care of ELN builds.
New GCC releases almost always trigger new compile warnings or bugs in code. So by pushing GCC 11 into ELN, it feels like we're making it much more likely that ELN builds will fail, and now Fedora maintainers have to debug ELN specific problems that won't reproduce in rawhide branches :-(
Expectations for Fedora maintainers does not change. ELN is a development playground. Think about sidetag, with slightly better automation around it.
We provide ELN as the opportunity, option to play with early releases of the GCC11 on the side. We are not requiring Fedora maintainers to participate, we are inviting people who may be interested in this work.
As Fedora maintainer I've been sent details of ELN failures / bugs, and asked to deal with fixes for ELN branches, so there's clearly an expectation placed on Fedora maintainers to be engaged in ELN.
And that's unfortunate. I've tried to signal to the ELN/Bakery folks that they should be contacting me first as any build failure related to teh compiler change I've probably already seen in one form or another. But it doesn't seem to have sunk in.
We haven't merged gcc11 into ELN yet, and there are no builds or tasks filed about it to Fedora maintainers. So I am not sure which issues Daniel is referring to.
Of course if a package needs an adjustment of a spec file to be built in ELN buildroot, members of the ELN SIG might reach out and ask for help, or suggest a pull request. And yes, the expectation is that one member of the community can reach out to another for the specific issue. I honestly believe that this is how open source collaboration works.
On Thu, Oct 22, 2020 at 7:10 AM Daniel P. Berrangé berrange@redhat.com wrote:
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.
That is not accurate. You have been asked to fix ELN build failures as a RHEL maintainer, and to do the fix in Fedora's ELN so both Fedora and RHEL get a benefit instead of just RHEL.
On 10/22/20 7:00 AM, Daniel P. Berrangé 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 :-(
True, but the GCC team (me in particular) have already been building rawhide with gcc-11 snapshots and fixing these issues.
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.
jeff
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/$basearch.
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.
-- Petr
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/$basearch.
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.
Of course, dropping gcc-11 into rawhide earlier helps this issue too :-)
Jeff
On Thu, Oct 22, 2020 at 09:20:28AM -0600, Jeff Law wrote:
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/$basearch.
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.
I see. This year it's indeed more accessible. E.g. I've just installed it from the side tag repository to my Rawhide and verifired that perl builds fine with GCC 11 :)
-- Petr
On 10/22/20 9:28 AM, Petr Pisar wrote:
On Thu, Oct 22, 2020 at 09:20:28AM -0600, Jeff Law wrote:
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/$basearch.
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.
I see. This year it's indeed more accessible. E.g. I've just installed it from the side tag repository to my Rawhide and verifired that perl builds fine with GCC 11 :)
:-)
I already verified that, repeatedly. On Sept 7th, Sept 20th, Oct 1st and Oct 15th. I figure the next build of perl with gcc-11 in my tester should land in about a week ;-)
Jeff
Daniel P. Berrangé wrote:
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 :-(
I am not going to do that for my packages. The FTBFS policy does not apply to ELN, and hence any and all FTBFS bugs filed against my packages on ELN will be summarily closed as NOTABUG or WONTFIX.
Kevin Kofler
On Thu, 22 Oct 2020 at 14:28, Aleksandra Fedorova 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.
Thanks for driving this effort
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/
-- Aleksandra Fedorova bookwar at #fedora-devel and #fedora-ci _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 5:55 AM, Clement Verna wrote:
On Thu, 22 Oct 2020 at 14:28, Aleksandra Fedorova <alpha@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.
We use the experiences found during Fedora builds to populate some of the upstream GCC release documentation. ie, what kinds of issues are we seeing in real world code. For example:
https://gcc.gnu.org/gcc-10/porting_to.html
There's a document for gcc-11 which has bullet items for things we've seen in in our Fedora testing (and looking at it, there's a couple things that need to be added :-). But we haven't dropped in examples, it's just the initial bullet list.
Hi!
On Thursday, 22 October 2020 at 14:27, 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.
Was this discussed publicly anywhere? How is using ELN buildroot better than doing this in rawhide directly or in COPR?
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.
Is the size of the package set the only concern? The a side-tag and limited rebuild of rawhide would achieve the same.
We would like to invite everyone to join this effort.
How? https://docs.fedoraproject.org/en-US/eln/sig/#_how_to_join says "TBA".
The work is currently tracked on Github: https://github.com/fedora-eln/eln/issues/8
Not much there yet. Why are we using non-free services for Fedora work again?
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
https://docs.fedoraproject.org/en-US/eln/buildroot/#building still says mock configuration is unsupported.
For more info on ELN please refer to ELN Docs (as soon as I update them, which hopefully happens later today):
Please do.
Regards, Dominik
On Thu, Oct 22, 2020 at 2:27 PM Aleksandra Fedorova 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.
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):
Other issues aside, it would have been nice to mention that you're running a mass rebuild of ELN with GCC 11, and indeed, running it right now. I only noticed because a koji build I submitted has been stuck as idle in the task queue for almost an hour already, so I'm not going to wait for that to finish today.
Fabio
Hi, all,
On Thu, Oct 22, 2020 at 2:27 PM Aleksandra Fedorova 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.
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/
-- Aleksandra Fedorova bookwar at #fedora-devel and #fedora-ci
Small update on the topic:
GCC11 has not landed in the ELN buildroot yet.
After we tried the first mass rebuild of ELN packages in a sidetag, several issues were found by gcc maintainers. Jeff has more info on that, but afaiu one issue is related to glib2 and waits for the upstream fix.
Once the issue is fixed we may try new ELN mass-rebuild in the sidetag, before doing any real updates in the buildroot itself. Exact timing is yet to be defined.
We will be running this mass rebuild with the lowest priority, so that it won't get in the way of regular Fedora builds. (We had a misconfiguration in the rebuild script, which caused the queue on the build system before. This issue is now fixed)
-
Aleksandra Fedorova -
Brendan Conoboy -
Charalampos Stratakis -
Clement Verna -
Daniel P. Berrangé -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Florian Weimer -
Jakub Jelinek -
Jeff Law -
Jonathan Wakely -
Kalev Lember -
Kevin Kofler -
Miro Hrončok -
Neal Gompa -
Panu Matilainen -
Petr Pisar -
Vitaly Zaitsev -
Vít Ondruch