On Tue, Jul 23, 2019 at 2:37 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote: > > > On 7/22/19 10:34 PM, Igor Gnatenko wrote: > > > > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko > > > > <ignatenkobrain@xxxxxxxxxxxxxxxxx> 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. Agreed. I'd like to frame the discussion less around "adding another arch" and more around "adding a new thing", but you mostly correct. I would suggest that there is this nebulous thing called "the cloud" that mitigates a small part of that, but I also fully understand using that magical machine resource presents its own challenges. > 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... Honestly, I'm less concerned about this. Why? Because anything new like this does not immediately require the full weight of a mirror system. The level of interest is likely to be small enough at the start that we can and should approach it in a measured way. > > 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. This makes the assumption that there is no influx of actual humans. Given history, maybe that's a fair assumption. I think for anything new to work, we'd need at least some way to add actual human participants. Either by freeing up existing people, or bringing new, interested people in. > 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. It didn't happen, but I'm seeing different approaches already being taken to address similar issues. The current discussion around dropping a number of apps, for example. All of these things require a cost/benefit analysis for sure. That is very hard, but it's also very healthy. Just doing the same thing forever just gets you the same thing forever, right? I haven't been a super-active Fedora participant very recently, but I'm encouraged that the project is starting to look at things in new ways and evaluating what is actually a valuable thing to do. I find it very exciting. 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
