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

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
-- 
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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Friday, 23 October 2020 at 19:06, Clement Verna wrote:
> On Fri, 23 Oct 2020 at 17:20, Miro Hrončok  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
-- 
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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Neal Gompa

On Fri, Oct 23, 2020 at 4:05 PM Clement Verna  wrote:
>
>
>
> On Fri, 23 Oct 2020 at 19:55, Neal Gompa  wrote:
>>
>> On Fri, Oct 23, 2020 at 1:07 PM Clement Verna  
>> wrote:
>> >
>> >
>> >
>> > On Fri, 23 Oct 2020 at 17:20, Miro Hrončok  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

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List

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

2020-10-23 Thread Clement Verna

On Fri, 23 Oct 2020 at 19:55, Neal Gompa  wrote:

> On Fri, Oct 23, 2020 at 1:07 PM Clement Verna 
> wrote:
> >
> >
> >
> > On Fri, 23 Oct 2020 at 17:20, Miro Hrončok  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, and
> containers 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-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

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
-- 
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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Jeff Law


On 10/23/20 5:55 AM, Clement Verna wrote:
>
>
> On Thu, 22 Oct 2020 at 14:28, 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 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.

https://gcc.gnu.org/gcc-11/porting_to.html


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Jeff Law


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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Neal Gompa

On Fri, Oct 23, 2020 at 1:07 PM Clement Verna  wrote:
>
>
>
> On Fri, 23 Oct 2020 at 17:20, Miro Hrončok  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.
> ```
>




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Clement Verna

On Fri, 23 Oct 2020 at 17:20, Miro Hrončok  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-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Miro Hrončok


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.


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

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

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
-- 
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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

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):
> 
> https://docs.fedoraproject.org/en-US/eln/

Please do.

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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Charalampos Stratakis



- Original Message -
> From: "Aleksandra Fedorova" 
> To: "Development discussions related to Fedora" 
> 
> 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  wrote:
> >
> > On 10/23/20 11:52 AM, Aleksandra Fedorova wrote:
> > > On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok  wrote:
> > >>
> > >> On 10/22/20 6:33 PM, Aleksandra Fedorova wrote:
> > >>> On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok 
> > >>> 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
> > > wrote:
> > >> I was asking for ELN branch for ages and it was always denied and
> > >> there
> > >> you have it [1]. So what is the current stance on this topic?
> > > You were asking for a branch to overcome the issue with building a
> > > package in ELN. And we have a suggestion for the alternative solution
> > > which wouldn't require maintaining a separate eln branch forever.
> > >
> > > For gcc we are using a temporary branch for the development of a new
> > > feature in Fedora.
> > > I would have named it "gcc11" branch rather than "eln", but it is a
> > > bikeshedding exercise.
> > 
> >  This is not about naming / bikeshedding. Whatever you call it, this is
> >  a "branch
> >  used exclusively to build in ELN". Vít wanted this, I wanted this and
> >  many other
> >  Fedora/RHEL packagers wanted this. Yet you argued so passionately
> >  against it.
> >  For example you said:
> > 
> > > I think that not having eln-branch is very important part of the
> > > concept as we don't want to fork Fedora.
> > 
> >  https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/
> > 
> >  But there were countless other arguments against having such branches.
> >  Have the
> >  situation changed? Can other packages have eln branches as well?
> > >>>
> > >>> No, the situation has not changed.
> > >>
> > >> Glad to hear that, because that eln branch in gcc was a big surprise for
> > >> all of
> > >> us who have been told this is not an option.
> > >>
> > >>> I'll reiterate:
> > >>>
> > >>> We don't want to fork packages from the Fedora Rawhide. We don't want
> > >>> to provide eln-branch as an option to overcome build failures in ELN.
> > >>> ELN's purpose is to provide motivation and tooling for downstream
> > >>> developers to work on Fedora, not to share parts of Fedora
> > >>> infrastructure for downstream developers to do their downstream work.
> > >>
> > >>   From where I stand, this gcc eln branch / update in ELN seem to be
> > >>   primarily
> > >> motivated by downstream. But I agree that I might miss all the important
> > >> information to make that claim, so I'll try to not be biased.
> > >
> > > It would be nice if we could stop playing political games and start
> > > looking at the content of the work, rather than discussing who brings
> > > it.
> >
> > I am not playing any political games. I express my opinion that this is not
> > how
> > I expect changes to land in Fedora. There's nothing political about that.
> > What
> > do you actually mean by political in this context?
> >
> > > eln-branch to handle downstream incompatibility with rawhide and
> > > eln-branch made to test Fedora features are two different types of
> > > work.
> >
> > You said "no ELN branches". Is that no longer true?
> 
> You can keep taking my words out of context, I can only keep bringing
> the context back as the answer.
> 
> > >>> We expect downstream to have its own infrastructure and process for
> > >>> branched packages. And we do have it in RHEL. If you want to discuss
> > >>> how exactly RHEL downstream does it, I can provide more information.
> > >>> But I consider it to be offtopic in this mailing list, or at least in
> > >>> this thread.
> > >>
> > >> I thought I have a decent idea about how this is done. For example that
> > >> there
> > >> will be no eln branches and this will be done "somewhere else later". At
> > >> least
> > >> that is what we've been told when ELN was introduced. So I seem to have
> > >> the
> > >> wrong idea. Could you please summarize this? What kind of downstream
> > >> changes
> > >> will happen in ELN branches and what kind of downstream changes will
> > >> happen
> > >> "somewhere else later"?
> > >
> > > Again, you are mixing up changes made in downstream and changes in
> > > Fedora sponsored by downstream.
> >
> > I don't understand how is that difference relevant. You've made arguments,
> > you've set up expectations, now you broke them with some new "this is
> > actually
> > Fedora change, so it is possible to have eln branch" narrative. I am
> > completely
> > fine if we have a discussion about this and we agree that

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

2020-10-23 Thread Aleksandra Fedorova

On Fri, Oct 23, 2020 at 12:40 PM Miro Hrončok  wrote:
>
> On 10/23/20 11:52 AM, Aleksandra Fedorova wrote:
> > On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok  wrote:
> >>
> >> On 10/22/20 6:33 PM, Aleksandra Fedorova wrote:
> >>> On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok  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  wrote:
> >> I was asking for ELN branch for ages and it was always denied and there
> >> you have it [1]. So what is the current stance on this topic?
> > You were asking for a branch to overcome the issue with building a
> > package in ELN. And we have a suggestion for the alternative solution
> > which wouldn't require maintaining a separate eln branch forever.
> >
> > For gcc we are using a temporary branch for the development of a new
> > feature in Fedora.
> > I would have named it "gcc11" branch rather than "eln", but it is a
> > bikeshedding exercise.
> 
>  This is not about naming / bikeshedding. Whatever you call it, this is a 
>  "branch
>  used exclusively to build in ELN". Vít wanted this, I wanted this and 
>  many other
>  Fedora/RHEL packagers wanted this. Yet you argued so passionately 
>  against it.
>  For example you said:
> 
> > I think that not having eln-branch is very important part of the
> > concept as we don't want to fork Fedora.
> 
>  https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/
> 
>  But there were countless other arguments against having such branches. 
>  Have the
>  situation changed? Can other packages have eln branches as well?
> >>>
> >>> No, the situation has not changed.
> >>
> >> Glad to hear that, because that eln branch in gcc was a big surprise for 
> >> all of
> >> us who have been told this is not an option.
> >>
> >>> I'll reiterate:
> >>>
> >>> We don't want to fork packages from the Fedora Rawhide. We don't want
> >>> to provide eln-branch as an option to overcome build failures in ELN.
> >>> ELN's purpose is to provide motivation and tooling for downstream
> >>> developers to work on Fedora, not to share parts of Fedora
> >>> infrastructure for downstream developers to do their downstream work.
> >>
> >>   From where I stand, this gcc eln branch / update in ELN seem to be 
> >> primarily
> >> motivated by downstream. But I agree that I might miss all the important
> >> information to make that claim, so I'll try to not be biased.
> >
> > It would be nice if we could stop playing political games and start
> > looking at the content of the work, rather than discussing who brings
> > it.
>
> I am not playing any political games. I express my opinion that this is not 
> how
> I expect changes to land in Fedora. There's nothing political about that. What
> do you actually mean by political in this context?
>
> > eln-branch to handle downstream incompatibility with rawhide and
> > eln-branch made to test Fedora features are two different types of
> > work.
>
> You said "no ELN branches". Is that no longer true?

You can keep taking my words out of context, I can only keep bringing
the context back as the answer.

> >>> We expect downstream to have its own infrastructure and process for
> >>> branched packages. And we do have it in RHEL. If you want to discuss
> >>> how exactly RHEL downstream does it, I can provide more information.
> >>> But I consider it to be offtopic in this mailing list, or at least in
> >>> this thread.
> >>
> >> I thought I have a decent idea about how this is done. For example that 
> >> there
> >> will be no eln branches and this will be done "somewhere else later". At 
> >> least
> >> that is what we've been told when ELN was introduced. So I seem to have the
> >> wrong idea. Could you please summarize this? What kind of downstream 
> >> changes
> >> will happen in ELN branches and what kind of downstream changes will happen
> >> "somewhere else later"?
> >
> > Again, you are mixing up changes made in downstream and changes in
> > Fedora sponsored by downstream.
>
> I don't understand how is that difference relevant. You've made arguments,
> you've set up expectations, now you broke them with some new "this is actually
> Fedora change, so it is possible to have eln branch" narrative. I am 
> completely
> fine if we have a discussion about this and we agree that this is a supported
> way of doing things. Yet you've done two things:
>
>   1) you were absolutely and unconditionally against ELN branches

I could have asked you to provide the proof for the "absolutely and
unconditionally" part. But I am not going to.

In my vision of a constructive discussion, when i say "By saying this
I meant this" you are supposed to say "ok, now i understand it better,
but it wasn't clear before" and we could move on.

Note that the "move on" may include the step like "with

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

2020-10-23 Thread Clement Verna

On Thu, 22 Oct 2020 at 14:28, 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 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-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Friday, 23 October 2020 at 11:52, Aleksandra Fedorova wrote:
> On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok  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

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

2020-10-23 Thread Miro Hrončok

On 10/23/20 11:52 AM, Aleksandra Fedorova wrote:

On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok wrote:

On 10/22/20 6:33 PM, Aleksandra Fedorova wrote:

On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok 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 wrote:

I was asking for ELN branch for ages and it was always denied and there
you have it [1]. So what is the current stance on this topic?

You were asking for a branch to overcome the issue with building a
package in ELN. And we have a suggestion for the alternative solution
which wouldn't require maintaining a separate eln branch forever.

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

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

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

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

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

No, the situation has not changed.

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

I'll reiterate:

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

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

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

I am not playing any political games. I express my opinion that this is not how
I expect changes to land in Fedora. There's nothing political about that. What
do you actually mean by political in this context?

eln-branch to handle downstream incompatibility with rawhide and
eln-branch made to test Fedora features are two different types of
work.

You said "no ELN branches". Is that no longer true?

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

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

2020-10-23 Thread Vít Ondruch

Dne 22. 10. 20 v 18:33 Aleksandra Fedorova napsal(a):

On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok 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 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.

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

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

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

No, the situation has not changed.

I'll reiterate:

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 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-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Aleksandra Fedorova

On Thu, Oct 22, 2020 at 7:12 PM Miro Hrončok  wrote:
>
> On 10/22/20 6:33 PM, Aleksandra Fedorova wrote:
> > On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok  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  wrote:
>  I was asking for ELN branch for ages and it was always denied and there
>  you have it [1]. So what is the current stance on this topic?
> >>> You were asking for a branch to overcome the issue with building a
> >>> package in ELN. And we have a suggestion for the alternative solution
> >>> which wouldn't require maintaining a separate eln branch forever.
> >>>
> >>> For gcc we are using a temporary branch for the development of a new
> >>> feature in Fedora.
> >>> I would have named it "gcc11" branch rather than "eln", but it is a
> >>> bikeshedding exercise.
> >>
> >> This is not about naming / bikeshedding. Whatever you call it, this is a 
> >> "branch
> >> used exclusively to build in ELN". Vít wanted this, I wanted this and many 
> >> other
> >> Fedora/RHEL packagers wanted this. Yet you argued so passionately against 
> >> it.
> >> For example you said:
> >>
> >>> I think that not having eln-branch is very important part of the
> >>> concept as we don't want to fork Fedora.
> >>
> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/
> >>
> >> But there were countless other arguments against having such branches. 
> >> Have the
> >> situation changed? Can other packages have eln branches as well?
> >
> > No, the situation has not changed.
>
> Glad to hear that, because that eln branch in gcc was a big surprise for all 
> of
> us who have been told this is not an option.
>
> > I'll reiterate:
> >
> > We don't want to fork packages from the Fedora Rawhide. We don't want
> > to provide eln-branch as an option to overcome build failures in ELN.
> > ELN's purpose is to provide motivation and tooling for downstream
> > developers to work on Fedora, not to share parts of Fedora
> > infrastructure for downstream developers to do their downstream work.
>
>  From where I stand, this gcc eln branch / update in ELN seem to be primarily
> motivated by downstream. But I agree that I might miss all the important
> information to make that claim, so I'll try to not be biased.

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

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

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

2020-10-23 Thread Panu Matilainen


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 -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Jakub Jelinek

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-23 Thread Miro Hrončok


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.

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

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

2020-10-23 Thread Panu Matilainen


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  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/


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 -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Neal Gompa

On Thu, Oct 22, 2020 at 1:28 PM Florian Weimer  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.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Florian Weimer

* 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
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Miro Hrončok

On 10/22/20 6:33 PM, Aleksandra Fedorova wrote:

On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok 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 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?

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.

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

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

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

No, the situation has not changed.

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

I'll reiterate:

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.

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?

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

On Thu, Oct 22, 2020 at 3:05 PM Miro Hrončok  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  wrote:
> >> I was asking for ELN branch for ages and it was always denied and there
> >> you have it [1]. So what is the current stance on this topic?
> > You were asking for a branch to overcome the issue with building a
> > package in ELN. And we have a suggestion for the alternative solution
> > which wouldn't require maintaining a separate eln branch forever.
> >
> > For gcc we are using a temporary branch for the development of a new
> > feature in Fedora.
> > I would have named it "gcc11" branch rather than "eln", but it is a
> > bikeshedding exercise.
>
> This is not about naming / bikeshedding. Whatever you call it, this is a 
> "branch
> used exclusively to build in ELN". Vít wanted this, I wanted this and many 
> other
> Fedora/RHEL packagers wanted this. Yet you argued so passionately against it.
> For example you said:
>
> > I think that not having eln-branch is very important part of the
> > concept as we don't want to fork Fedora.
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WRJNM7I5TFQ5TEBOUKKH757K5ME3I47F/
>
> But there were countless other arguments against having such branches. Have 
> the
> situation changed? Can other packages have eln branches as well?

No, the situation has not changed.

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-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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


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
>>> .
>>>
>>> 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Petr Pisar

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
> > .
> >
> > 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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

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
> .
>
> 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Kevin Kofler

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Petr Pisar

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
.

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

Hi, Jeff,

On Thu, Oct 22, 2020 at 4:14 PM Jeff Law  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é  
> >> 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.

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Brendan Conoboy

On Thu, Oct 22, 2020 at 7:15 AM Jeff Law  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.

-- 
Brendan Conoboy / Linux Project Lead / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Brendan Conoboy

On Thu, Oct 22, 2020 at 7:10 AM Daniel P. Berrangé  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.

-- 
Brendan Conoboy / Linux Project Lead / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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


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é  
>> 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Brendan Conoboy

On Thu, Oct 22, 2020 at 6:06 AM Neal Gompa  wrote:

> On Thu, Oct 22, 2020 at 9:03 AM Vitaly Zaitsev via devel
>  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.

-- 
Brendan Conoboy / Linux Project Lead / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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


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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Daniel P . Berrangé

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é  
> 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
-- 
|: 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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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


On 10/22/20 6:53 AM, Neal Gompa wrote:
> On Thu, Oct 22, 2020 at 8:27 AM 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.
>>
>> 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/
>>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

Hi, Daniel,

On Thu, Oct 22, 2020 at 3:01 PM 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 :-(

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-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

--
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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


On 10/22/20 7:02 AM, Kalev Lember wrote:
> On Thu, Oct 22, 2020 at 2:54 PM Neal Gompa  > wrote:
>
> On Thu, Oct 22, 2020 at 8:27 AM Aleksandra Fedorova
> mailto:al...@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/
> 
> >
>
> 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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Neal Gompa

On Thu, Oct 22, 2020 at 9:03 AM Vitaly Zaitsev via devel
 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Miro Hrončok

On 10/22/20 2:51 PM, Aleksandra Fedorova wrote:

Hi, Vit.
On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch 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?

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.

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

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

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

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

2020-10-22 Thread Vitaly Zaitsev via devel


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.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Kalev Lember

On Thu, Oct 22, 2020 at 2:54 PM Neal Gompa  wrote:

> On Thu, Oct 22, 2020 at 8:27 AM 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.
> >
> > 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/
> >
>
> 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.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Daniel P . Berrangé

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
-- 
|: 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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Neal Gompa

On Thu, Oct 22, 2020 at 8:27 AM 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.
>
> 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/
>

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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

Hi, Vit.
On Thu, Oct 22, 2020 at 2:37 PM Vít Ondruch  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):
> >
> > https://docs.fedoraproject.org/en-US/eln/
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

2020-10-22 Thread Vít Ondruch

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):

https://docs.fedoraproject.org/en-US/eln/


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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