On Thu, Jan 16, 2020 at 8:01 AM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > Hi, Chris, > > On Fri, Jan 10, 2020 at 4:29 PM Chris Adams <linux@xxxxxxxxxxx> wrote: > > > > Once upon a time, Aleksandra Fedorova <alpha@xxxxxxxxxxxx> said: > > > Similarly to what Josh said, we want to setup an environment for experiments. > > > It doesn't mean that things we experiment on are going to be merged in > > > Fedora. And it definitely doesn't mean that whatever we did in the > > > experimental environment can bypass the approval process. > > > > > > It is not a backdoor for rejected change, it is a way to safely > > > iterate on the rejected change to see if we can come up with a version > > > of it, which won't be rejected. > > > > So... I guess my objections are all based on the proposal as written, > > which doesn't sound to me like what you are describing. What the > > proposal says is all about rebuilding Fedora with the rejected baseline > > change, and showing that it is better to get the community to accept the > > original change. It also uses the term "older machines" (which is still > > misleading). > > I have adjusted the description of the change in a way that I think > clarifies this part. Please check if it is better now. > > Also I've posted some context in a separate thread [1]. > > I think the current change is important to Fedora also as a showcase > that we, as a project, care not only about the internal distribution > matters but in some large developments in the "outside world". > That we can also provide a venue for, for example, hardware vendors to > show their newest work. > > The rejection is a valuable feedback here, it highlights that it is > not enough to just push a new hardware spec to the market to get it > adopted. But we can also try to find a way how actually it _can_ be > done better. > I'll be honest: for me, not changing the architecture value that RPM uses for this is a hard blocker for me. The current proposal for distinguishing packages is unnecessarily confusing and makes it difficult to segment in Koji. If I hand-wave away all the other issues with this proposal (including that I'm still uncertain of the true purpose of this Change), the fact that RPMs with a new baseline will pretend to be the same architecture as another in a manner that we cannot codify a control for compatibility in RPM itself is simply unacceptable. This proposal simply illustrates one of the biggest problems with the way architectures are currently handled: we don't really leverage sub-arches or anything of the sort, so it's quite difficult to discern this minutiae otherwise. Without changing the architecture value, we also cannot implement a meaningful way for RPM to block the installation of these packages on computers that don't meet the CPU requirements. If we really want to do this, my ask is that you get RPM upstream to give you a new architecture label and have the hardware detection in place to keep people from breaking their systems with these packages. -- 真実はいつも一つ！/ 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
