14:00:40 <bcotton> #startmeeting Prioritized bugs and issues
14:00:40 <zodbot> Meeting started Wed Aug 24 14:00:40 2022 UTC.
14:00:40 <zodbot> This meeting is logged and archived in a public location.
14:00:40 <zodbot> The chair is bcotton. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
14:00:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:40 <zodbot> The meeting name has been set to 'prioritized_bugs_and_issues'
14:00:40 <bcotton> #meetingname Fedora Prioritized bugs and issues
14:00:40 <zodbot> The meeting name has been set to 'fedora_prioritized_bugs_and_issues'
14:00:51 <bcotton> #topic Purpose of this meeting
14:00:51 <bcotton> #info The purpose of this process is to help with processing backlog of bugs and issues found during the development, verification and use of Fedora distribution.
14:00:51 <bcotton> #info The main goal is to raise visibility of bugs and issues to help  contributors focus on the most important issues.
14:00:51 <bcotton> #link https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/#_process_description
14:00:58 <bcotton> #topic Roll Call
14:02:55 <mattdm> hi!
14:03:01 <bcotton> ohai mattdm
14:03:03 <mattdm> just got here from my last meeting
14:03:14 <mattdm> sorry for the delay :)
14:03:25 <bcotton> it's all good
14:03:28 <bcotton> i think it may just be the two of us today
14:04:16 <bcotton> #topic Common Bugs review
14:04:16 <bcotton> #info Let's start with a check of the Common Bugs pages for supported releases and see if any should be nominated as Prioritized Bugs
14:04:17 <bcotton> #link https://ask.fedoraproject.org/c/common-issues/141/none/l/latest?order=votes
14:05:47 <bcotton> i don't see anything worth adding to the list
14:05:48 <mattdm> scanning...
14:06:35 <mattdm> yeah I agree nothing on fire
14:07:03 <bcotton> #topic Nominated bugs
14:07:03 <bcotton> #info 2 nominated bugs
14:07:03 <bcotton> #link https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&f1=flagtypes.name&f2=OP&list_id=10871664&o1=substring&query_format=advanced&v1=fedora_prioritized_bug%3F
14:07:13 <bcotton> #topic update 2.06-45 breaks windows boot manager
14:07:14 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=2115202
14:07:58 <mattdm> (bugzilla is loading...)
14:08:18 <bcotton> #info this is an accepted F37 Final blocker
14:08:27 <bcotton> so I guess we can pass on the prioritized bug part
14:08:34 <mattdm> let me amend... bugzilla is NOT loading. just kind of spinning for me
14:08:42 <mattdm> but that seems like a fine resolution
14:09:04 <bcotton> #topic "dnf update" runs out fo memory on swapless 0.5 GiB RAM machine
14:09:04 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1907030
14:09:16 <bcotton> now this is a fun one
14:10:01 <bcotton> #info This is under consideration as an F37 Beta blocker
14:10:33 <bcotton> i'm not sure I agree with Colin moving this to the distribution component just yet, but that's a separate matter
14:11:36 <bcotton> splitting the repos into smaller groups seems like a suitable resolution from a technical standpoint, but i don't think it's as practically simple as it sounds
14:12:02 <mattdm> I have memories of
14:12:03 <mattdm> `for p in {0..9} {a..z}; do yum -y upgrade "${p}*"; done`
14:13:11 <mattdm> This is sending me on a FEELING JOURNEY
14:13:25 <bcotton> haha
14:14:17 <bcotton> one might say you're.... Feeling That Way https://www.youtube.com/watch?v=vg5vziU-qIs
14:14:23 <mattdm> https://pagure.io/packaging-committee/issue/714
14:15:11 <mattdm> This came up at devconf for some reason, too. I was talking to carlwgeorge
14:15:19 <mattdm> I forget the exact context
14:15:28 <mattdm> But it might be worth another go at this
14:16:02 <bcotton> it might. but it feels bigger than the prioritized bugs process
14:16:35 <bcotton> it seems like more of a "let's change how our repos work in F38+"
14:17:11 <mattdm> Well, the file dependencies issue might be enough to address the symptom without going to that level of surgery
14:17:52 <bcotton> as in get rid of file dependencies?
14:18:00 <mattdm> I am 100% on board for Adam's "not a blocker" reasoning in https://bugzilla.redhat.com/show_bug.cgi?id=1907030#c22
14:18:36 <mattdm> bcotton: Compromise: modification to DNF to only include those in certain common paths
14:19:56 <bcotton> that sounds like "2. Make loading file list optional - we will resolve it in the next generation of software management tool - DNF5/LIBDNF5 - RFE for Fedora 38+" https://bugzilla.redhat.com/show_bug.cgi?id=1907030#c16
14:20:34 <bcotton> and you can argue that it's different, which i'd accept. but it still sounds like an RFE, which is probably not the best use of this process
14:20:42 <mattdm> that's a long way off too
14:21:29 <mattdm> I hear you on the process, but i also don't want this to get dropped or lose coordination.
14:21:47 <mattdm> Where is a better place? Maybe a Change involving interested parties?
14:22:15 <bcotton> yeah, i think this is an F38 Change proposal
14:22:30 <bcotton> the specific shape of it is TBD
14:23:15 <mattdm> "using only small repositories" isn't really an answer, because AIUI that only would help if there are no interdependencies
14:23:21 <bcotton> splitting repos somehow seems like the "Best" approach...if we can find a reasonable way to do it
14:23:28 <bcotton> right
14:23:45 <TheExorcist[m]> <mattdm> "I am 100% on board for Adam's "..." <- I think you are on it. What are the minimum requirements for installing Fedora 36+?
14:23:55 <bcotton> For every complex problem there is an answer that is clear, simple, and wrong.
14:24:38 <mattdm> I think deps are currently way too tangled for that to work. plus DNF (at least in the current state) seems exponentially slower for every repo enabled. (I don't know if that's fair, but it is common wisdom and seems truthy.)
14:25:29 <mattdm> I will note that this is ALSO a problem modularity was supposed to solve (but does not)
14:27:38 <bcotton> so this sounds like a thing that a Fedora Project Leader might need to take ownership of to coordinate a solution as an F38 Change proposal?
14:27:51 <mattdm> Colin also notes that rust deps are 20% of the info. That's... insane.
14:28:17 <mattdm> Oh good way to kill it, Ben :)
14:28:43 <bcotton> 👼
14:29:02 <mattdm> Maybe I can find someone to trick^H^H^H^H^H delegate this to :)
14:29:38 <mattdm> In seriousness, I'll talk to Carl.
14:30:44 <bcotton> proposed #agreed 1907030 is rejected as a Prioritized Bug as it requires large-scope changes to the distribution. mattdm will coordinate or delegate an effort to develop an F38 Change proposal to address the issues
14:31:01 <carlwgeorge> context was a separate idea I had a about combining fedora and updates repos to reduce the total repodata being downloaded
14:32:23 <mattdm> carlwgeorge: Would you be able to help coordinate getting to a solution here?
14:33:19 <mattdm> Probably a F38 change, involving the DNF team, packaging committee, packagers at large, and the various edition stakeholders (CoreOS and IoT, to start).
14:34:28 <mattdm> The two main avenues of exploration as I see it are:
14:34:28 <mattdm> 1. a separate repo for packages like the rust build stuff
14:34:28 <mattdm> 2. the file-list issue
14:34:43 <mattdm> (We can talk more about it if that'd be helpful.)
14:35:12 <mattdm> I care about this but realistically need someone else who cares and understands the problem to drive it
14:35:21 <carlwgeorge> perhaps, I don't want to commit just yet
14:35:25 <mattdm> and someone who can talk to all of those teams reasonably
14:36:15 <carlwgeorge> I want to pick neal's brain on his opposition to it first, and also read all the previous discussions on it
14:36:15 <mattdm> If you know of someone else who might be able to, let me know. It's kind of a short list, really :)
14:36:54 <bcotton> okay, so for now i'll #agreed my proposal and we can move on :-)
14:37:41 <mattdm> carlwgeorge: Can I ask you to get back to me after you've had that much and we'll figure out the next steps and I can possibly at that point talk you into full commitment :) — or know that I need to find someone else? That way I can avoid putting it on my backlog-of-doom right now
14:37:47 <mattdm> Ben Cotton (he/him): +1
14:38:14 <bcotton> #agreed 1907030 is rejected as a Prioritized Bug as it requires large-scope changes to the distribution. mattdm will coordinate or delegate an effort to develop an F38 Change proposal to address the issues
14:38:25 <bcotton> #topic Accepted bugs
14:38:25 <bcotton> #info 1 accepted bugs
14:38:25 <bcotton> #link https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&f1=flagtypes.name&f2=OP&list_id=10871665&o1=substring&query_format=advanced&v1=fedora_prioritized_bug%2B
14:38:31 <bcotton> #topic Get rid of multiple source path definitions
14:38:32 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=2079833
14:38:34 <carlwgeorge> mattdm: sure
14:38:44 <bcotton> speaking of long-term solutions
14:39:23 <bcotton> the immediate problem is fixed because someone packaged the upstream release that allowed the "you shouldn't have use it that way" to keep working
14:39:45 <jonathanspw> .hi
14:39:46 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org>
14:40:31 <bcotton> the question is: are we happy with that for now, or do we need to try to push the cmake maintainers to coordinate a cleanup of affected packages
14:40:46 <bcotton> (and note that i'm not sure the default assignee is still active)
14:40:50 <bcotton> welcome, jonathanspw
14:41:31 <bcotton> i'm inclined to go with the "fingers in ears and saying 'la la la'" option
14:41:32 * mattdm doesn't want to think too hard about cmake
14:43:45 <mattdm> this looks like maybe a job for a proven packager
14:43:49 <bcotton> proposed #agreed This is solved enough for our purposes and we encourage cmake maintainers to use the Changes process for future updates to prevent similar issues
14:44:12 <mattdm> +1
14:44:24 <mattdm> was writing something similar :)
14:44:59 <bcotton> #agreed This is solved enough for our purposes and we encourage cmake maintainers to use the Changes process for future updates to prevent similar issues
14:45:13 <bcotton> #topic Next meeting
14:45:13 <bcotton> #info We will meet again on 7 September at 1400 UTC in #fedora-meeting-1
14:45:14 <bcotton> #topic Open floor
14:45:27 <bcotton> Any other Prioritized-Bugs-shaped business today?
14:46:45 <TheExorcist[m]> #OpenFloor: The F36 Specs says, the minimum requirement for installing F36 is 2 GB or RAM and 20 GB of HDD/SSD. Then why do we need to consider 1 GB RAM option? I'm confused here..
14:47:15 <TheExorcist[m]> s/or/of
14:47:33 <bcotton> because a lot of devices in the IoT space, plus cloud, containers, etc don't have that kind of resources
14:48:05 <bcotton> i'm not sure we can (or should) apply the 2 GB minimum universally
14:48:46 <mattdm> If you have 2GB on the device, that doesn't necessarily mean every individual thing can itself use 2GB
14:49:00 <mattdm> Because it adds up :)
14:49:33 <mattdm> The 2GB guidance is really meant for end users looking at hardware specs, not meant to be a developer / distro guideline.
14:49:52 <TheExorcist[m]> mattdm: Well, but situation can be managed by collector.
14:50:33 <TheExorcist[m]> So does that mean, specs for future fedora releases are going to change?
14:50:35 <mattdm> Possibly! I think that's out of scope for this meeting.
14:51:16 <mattdm> The minimum specs for Fedora Linux overall, and for specific editions and spins, are always open to change as the world we're operating in changes.
14:52:38 <TheExorcist[m]> mattdm: I was doubting the re-use of old test-cases, that may need a revision, but the case turned out to be different. Well, So we have to stick with 1 GB RAM thing for now..
14:53:58 <mattdm> I think this is a discussion for #devel:fedoraproject.org , or the devel mailing list, or https://discussion.fedoraproject.org/tag/engineering
14:54:18 <bcotton> agreed
14:54:23 <bcotton> on that note, let's call this a day
14:54:25 <bcotton> #endmeeting