On Fri, Jan 10, 2020 at 8:37 AM Chris Adams <linux@xxxxxxxxxxx> wrote: > > Once upon a time, Aleksandra Fedorova <alpha@xxxxxxxxxxxx> said: > > The rejected change > > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update > > is explicitly referenced from the current one. So yes, it is the > > architecture update we are looking for. > > > > And I would suggest to avoid calling things weird and crazy just > > because you are not interested in them. > > The premise of the new change request is to ignore all the issues that > led to the original change request being rejected, and just assume that > the original will be accepted in the near future. I don't believe that is fair or even true. The premise of the new change is to allow alternative experimentation within Fedora proper without impacting the mainline distribution. There is no assumption that the results will magically replace Fedora in the near future. > AVX2 is not a reasonable requirement as a replacement for the current > Fedora x86_64, as there are CPUs still being made today that don't > support that. If you want to split x86_64 (along the lines of i386 vs. > i686), then building a shadow copy of the entire distribution is not a > good way forward - you need to do all the actual work required to make a > second x86_64 sub-architecture in the main x86_64 distribution. Come up > with a name, make the changes to the required packages, etc. I think we're focusing entirely too much on the initial interest for this alternative buildroot and being very myopic about it. Let's take a step back. > Otherwise, what is the point of the shadow architecture? What is the > end goal? Build it in perpetuity and just try to get people to run your > packages instead of the main distribution? If we look at the additional possibilities this offers outside of CPU tuning, I find it rather intriguing. Having infrastructure that allows for alternative buildroots to be created and leverage mainline Fedora activities allows for all kinds of experimentation. Perhaps it's not CPU tuning, but compiler optimization tuning. Perhaps it's building the distro with a different compiler in general. Fedora is very good at producing a singular distro, and it has been very poor at providing a way to deviate at scale from that singular distro. Copr is good for small scale, but attempting to build the whole distro there is overly arduous to the point where people don't even try. The part of this proposal that interest me is being able to easily piggyback on day to day Fedora activities to accomplish that scale. Koji-shadow is the only way to do this today, and it requires people to duplicate everything in the infrastructure themselves. It's also extremely invasive to merge back into Fedora proper. If Fedora had a way to provide that without requiring the investment overhead, I'd be really curious to see what kind of innovative things could come from it. josh _______________________________________________ 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
