[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: [ELN] gcc is going to be updated to gcc11 in the ELN buildroot ahead of Rawhide
From:       Neal Gompa <ngompa13 () gmail ! com>
Date:       2020-10-23 20:42:03
Message-ID: CAEg-Je_Z3v9F4nqLnfAJjLx_JoRE6X5ePR6MTPDgCJWGX5pH_A () mail ! gmail ! com
[Download RAW message or body]

On Fri, Oct 23, 2020 at 4:05 PM Clement Verna <cverna@fedoraproject.org> wrote:
> 
> 
> 
> On Fri, 23 Oct 2020 at 19:55, Neal Gompa <ngompa13@gmail.com> wrote:
> > 
> > On Fri, Oct 23, 2020 at 1:07 PM Clement Verna <cverna@fedoraproject.org> wrote:
> > > 
> > > 
> > > 
> > > On Fri, 23 Oct 2020 at 17:20, Miro Hrončok <mhroncok@redhat.com> wrote:
> > > > 
> > > > On 10/23/20 2:45 PM, Aleksandra Fedorova wrote:
> > > > > Sorry, but you just need to accept the fact that some _early
> > > > > development_ work in Fedora can happen without your decision on it.
> > > > 
> > > > I except (and accept) that most of the development work in Fedora happens
> > > > without my decision on it.
> > > > 
> > > > I would like you on the other hand to accept that major changes in Fedora are
> > > > coordinated trough the change process and ELN is part of Fedora.
> > > 
> > > 
> > > This for me highlights the fact that our change process is not adapted to all \
> > > parts of Fedora, in particular parts that need to move faster than the 6 month \
> > > releases. I have in mind the Container base image, Fedora CoreOS and ELN, IMO \
> > > these artefact depends more on the content (the set of packages included in \
> > > them) rather then knowing which version of Fedora release they are based on. \
> > > The Container base image and Fedora CoreOS are releasing every couple weeks, \
> > > ELN is just a rolling release, I think it is unfair to ask to follow a change \
> > > request system that is design for release that happen every 6 months. 
> > > I think we either need a new change request system that is light enough to \
> > > allow these group to iterate and make changes every week or so, or we need to \
> > > trust the people involved in these groups to make the best decisions for the \
> > > Fedora they care about and to also notify anyone that would be impacted by \
> > > these changes. 
> > 
> > I think you're missing the point. When ELN was approved, the intent
> > was to build Rawhide in a RHEL-ish configuration continuously.
> 
> 
> I agree that I missed that point because honestly it does not interest me. What I \
> am seeing is that we have a group of people that are interested in experimenting \
> and doing things differently in Fedora (The ELN SIG) and so far every time their \
> trials are met with a lot of push back. I personally don't care if ELN is not what \
> was communicated originally as long as it brings value to the people working on it, \
> and it does not make other people live worse. 
> There is so much energy spent pointing fingers at each other, it is really \
> demoralizing :(, Personally If I was in the ELN SIG I would feel unwelcome and \
> unwanted in Fedora, and would really consider just quitting trying to do anything \
> new in this community. 

This is a very odd way to take this. Yes, Fedora is a great and large
community. And one thing that makes us successful is that we're good
at defining scope and following through on ideas and concepts to
evolve the Linux platform.

But it's not a free-for-all. Using one way everyone expects you to do
things as a way to do something else entirely will take people by
surprise. Even more so when it's completely unprecedented.

For example, even Rawhide gating stuff[1] went through the Changes
process. Setting up ELN itself[2] went through that process. Factory
2.0 and Pagure[3] went through that. And so on.

What you're advocating for is something along the lines of the
openSUSE model where people just announce and do it. In my experience,
that is how you paralyze people into being unable to figure out how to
coordinate and scale change effort, while simultaneously making it
difficult for newer folks to find a path to make their mark in the
community.

And there is *nothing* that stops the Change process for working in a
rolling context other than people don't think of doing it.

There's actually nothing wrong with this idea in itself, because at
the crux of it is that there is a desire to have a side-tag to build
gcc11 with a limited compose to regression test and further evaluate
the development of GCC earlier. This is something I'd like to have
available for more things, and it's a great idea. But there is
basically no reason to stuff it into ELN other than it already exists
as a gap in our existing process. Instead, I'd like to have that
formally approved by FESCo in a way that releng would make a dedicated
side tag for it and allow OSCI to be configured for mini-composes for
the purpose of assisting in GCC development. Then it can be a regular
part of GCC rebase processes.



[1]: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
[2]: https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
[3]: https://fedoraproject.org/wiki/Changes/ArbitraryBranching



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



[prev in list] [next in list] [prev in thread] [next in thread]