Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/23/20 11:52 AM, Aleksandra Fedorova wrote:
On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:

On 10/22/20 6:33 PM, Aleksandra Fedorova wrote:
On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:

On 10/22/20 2:51 PM, Aleksandra Fedorova wrote:
Hi, Vit.
On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch<vondruch@xxxxxxxxxx>  wrote:
I was asking for ELN branch for ages and it was always denied and there
you have it [1]. So what is the current stance on this topic?
You were asking for a branch to overcome the issue with building a
package in ELN. And we have a suggestion for the alternative solution
which wouldn't require maintaining a separate eln branch forever.

For gcc we are using a temporary branch for the development of a new
feature in Fedora.
I would have named it "gcc11" branch rather than "eln", but it is a
bikeshedding exercise.

This is not about naming / bikeshedding. Whatever you call it, this is a "branch
used exclusively to build in ELN". Vít wanted this, I wanted this and many other
Fedora/RHEL packagers wanted this. Yet you argued so passionately against it.
For example you said:

I think that not having eln-branch is very important part of the
concept as we don't want to fork Fedora.

https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/

But there were countless other arguments against having such branches. Have the
situation changed? Can other packages have eln branches as well?

No, the situation has not changed.

Glad to hear that, because that eln branch in gcc was a big surprise for all of
us who have been told this is not an option.

I'll reiterate:

We don't want to fork packages from the Fedora Rawhide. We don't want
to provide eln-branch as an option to overcome build failures in ELN.
ELN's purpose is to provide motivation and tooling for downstream
developers to work on Fedora, not to share parts of Fedora
infrastructure for downstream developers to do their downstream work.

  From where I stand, this gcc eln branch / update in ELN seem to be primarily
motivated by downstream. But I agree that I might miss all the important
information to make that claim, so I'll try to not be biased.

It would be nice if we could stop playing political games and start
looking at the content of the work, rather than discussing who brings
it.

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.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux