[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:       Peter Robinson <pbrobinson () gmail ! com>
Date:       2019-07-24 8:34:22
Message-ID: CALeDE9PKbJDxCMv-sYDBowWhuB+1bHxah2GvbnfWoHDRAEGH6w () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jul 23, 2019 at 7:37 PM Adam Williamson
<adamwill@fedoraproject.org> wrote:
>
> On Tue, 2019-07-23 at 13:32 -0400, Josh Boyer wrote:
> > 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.)
>
> Well, sort of - except that, life being life, machines inevitably go
> wrong. Fans give out and they choke. Builds mysteriously fail because
> of some test flake or a neutrino hitting the CPU at just the wrong
> moment or something. Disks go wonky. And all of these things get fixed
> by...people. Adding an arch adds another arch worth of all those things
> happening and needing to be fixed by someone.
>
> Also, we can't really solve the machine resources of mirrors. Well, I
> mean, I guess we *could*, but I doubt anyone in RH is going to sign off
> on us buying a ton of expensive storage hardware and shipping it off to
> random universities around the world...
>
> > 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.
>
> I agree that this would be possible, but it comes with the caveat that
> the people who would likely get stuck with improving the workflows are
> the same people currently being overworked by the bad workflows.

Completely agree here, but I've seen no concrete proposals from the
leadership as to how they intend to fix this. There's proposals from
the CPE team to jettison things, which makes sense for them but it's
completely undefined what the wider impact on other teams or the wider
community will be there, I suspect it just moves the bottleneck.

> The 'don't do a release for a year' proposal (or whatever variations of
> it were discussed) was supposed to help with that kinda thing,
> but...that didn't happen. So, we're all still on the treadmills.

Part of that was because the proposal was just "stop releasing to fix
stuff" but there wasn't any form of proposal of what was going to be
fixed or how, there was just wide ranging hand wavy "stuff".
_______________________________________________
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]