On Fri, Oct 23, 2020 at 4:05 PM Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote: > > > > On Fri, 23 Oct 2020 at 19:55, Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> >> On Fri, Oct 23, 2020 at 1:07 PM Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote: >> > >> > >> > >> > On Fri, 23 Oct 2020 at 17:20, Miro Hrončok <mhroncok@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
