On Wed, May 13, 2020 at 6:56 AM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > I have several reasons against ELN, which I have already stated for past > versions of your proposal (Should I really have repeated those at every > single revised version that you came up with to bypass the repeated > rejection?): > * Having a buildroot that drops support for some subarchitectures is a step > towards dropping those subarchitectures for everyone, which is exactly > what we do not want. There is absolutely no reason to test dropping > subarchitectures anywhere if we are not going to deploy it ever. FWIW, we do not currently have that in place (and may never). That said, I disagree with your ex post facto statement that we would never drop any subarchitectures. We certainly wouldn't drop them without sufficient information to justify it, which is why we would need a place to learn that information. That said, the AVX2 proposal is currently on hold and is (IMHO) unlikely to be implemented for RHEL 9. > * Having a buildroot called "EL Next" means that Fedora gets in the business > of composing the development version of RHEL in addition to the > development version of Fedora. I do not see how this is the job of Fedora > and Fedora maintainers. RHEL should be developed on RHEL infrastructure, > by RHEL maintainers only. That sounds like the exact opposite of open source, to me. The entire point of this exercise is to do *less* work out of the public eye. The set of people who would be doing this work behind the firewall are now going to be instructed to work in Rawhide (and, by extension, ELN) to prepare for future versions of RHEL. This will also give the community at large more opportunity to influence the eventual RHEL 9 (and onwards) content and design. So, new issues that are discovered while building for a RHEL prototype will be far more visible and can be addressed earlier, either by the community maintainer or the RHEL maintainer working in the Fedora environment. > But apparently you do not consider those "convincing". It is less that I don't find them convincing; I find them to be the product of insufficient explanation on my part that has led to incorrect assumptions. I'd appreciate it if you would be so kind as to default to assuming we're all on the same side (the success of Fedora and Open Source in general) and request clarification rather than assuming malicious intent. > I also think that there needs to be a limit to how many times a rejected > change gets resubmitted. It is just not acceptable to retry and retry until > the vote ends up the way you want it to. I disagree with this, mainly because FESCo rarely rejects a Change *outright*. It's usually rejected for specific reasons. (E.g. it doesn't have a contingency plan or the proposed design would cause harm/regressions to a large subset of the Fedora community that outweighs the benefit). Any such Changes are welcome to be resubmitted as many times as necessary *provided that they have materially changed the sections resulting in the earlier rejection*. _______________________________________________ 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
