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

List:       fedora-devel-list
Subject:    Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
From:       Josh Boyer <jwboyer () fedoraproject ! org>
Date:       2019-07-23 17:32:43
Message-ID: CA+5PVA45hnRSfEtKschfBdLNbnUMyR5fU=Hm_kh94v3NxNvywg () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jul 23, 2019 at 12:39 PM Kevin Fenzi <kevin@scrye.com> wrote:
>
> On 7/22/19 10:34 PM, Igor Gnatenko wrote:
> > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
> > <ignatenkobrain@fedoraproject.org> wrote:
>
> > Thinking about this even more, it should not be very hard thing to do:
> >
> > * Define new architecture in RPM/libsolv (let's call it "haswell" or
> > "x86_64modern")
> > * Define set of capabilities it should have, write appropriate check
> > in RPM/libdnf
> > * Add new architecture in Fedora Koji
> > * Once bootstrapped, create composes
> > * At some point in future, merge this arch back to x86_64 and move forward
> >
> > What do you think?
>
> Unless someone can show some kind of MASSIVE benefit, I'm not in favor.

I think too often we focus on the technical implications (performance
gain, etc) and sometimes don't consider wider aspects.  So I'm curious
what your view is.  Can you elaborate on what kind of benefit you
would view as warranting this?

> It's a ton of duplication of effort, tons more disk space, tons more cpu
> cycles wasted, a ton more mirror disk space, a ton more bandwith, etc.

So let's look at this statement, for example.  Everything listed is
machine related, except the first part on duplication of effort.
Machine related items are solvable with more machine resources.  (That
is not to be flippant, but it's far easier to solve than human
impact.)

On the effort part, what if we structured it so it wasn't immediately
2x the effort.  That would indeed be poor.  If we assume for a minute
that we have the machine resources, we can certainly come up with
workflows that facilitate something like this in a manner that doesn't
cause a large human overhead.  I'm actually thinking of other areas
that would benefit from not exactly the new architecture approach as
traditionally know, but a new target space that allows the Fedora
project to do new things.

Dismissing ideas like this because we thought too narrowly about the
single discussion starter is something I often see Fedora do, and I
honestly think it's causing the project to miss opportunities to add
value in multiple ways.

josh
_______________________________________________
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]