16:00:23 <pwhalen> #startmeeting Fedora IoT Working Group Meeting
16:00:23 <pwhalen> #chair pwhalen pbrobinson coremodule idiez saypaul djachimo
16:00:23 <zodbot> Meeting started Wed Jan 10 16:00:23 2024 UTC.
16:00:23 <zodbot> This meeting is logged and archived in a public location.
16:00:23 <zodbot> The chair is pwhalen. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:23 <zodbot> The meeting name has been set to 'fedora_iot_working_group_meeting'
16:00:23 <zodbot> Current chairs: coremodule djachimo idiez pbrobinson pwhalen saypaul
16:00:23 <pwhalen> #topic roll call
16:00:36 <pwhalen> Good morning folks, who's here today?
16:00:45 * coremodule is here, good morning pwhalen.
16:00:52 * djachimo is present and ready for duty
16:00:52 * pbrobinson o/ at least to some degree
16:01:33 <pwhalen> Nice, lets get to it!
16:01:49 <pwhalen> #topic 1) ==== Working Group ====
16:02:25 <pwhalen> I don't think I have anything here
16:02:29 <coremodule> I do!
16:02:33 <pbrobinson> should we discuss meeting location?
16:02:35 <pwhalen> coremodule: we could discuss the .. :)
16:02:52 <pwhalen> Oh, that too. Let's let coremodule go first
16:03:01 <coremodule> I would like to pen an official document that details how we pick which IoT compose will end up as a milestone.
16:04:26 <coremodule> I'll write the doc and send it to the email, but I'm not sure I know the process that we follow to pick the release. In the past I know we've used the Friday compose and the Monday compose (both following the Go/No Go meeting), so I'd like to start conversation that sets some of these in stone so people have a better idea of how we pick the IoT release milestones.
16:05:06 <pbrobinson> so the Mon compose is basically to move it to stable branch from devel
16:05:38 <pbrobinson> pwhalen and I are investigating an infra solution to that, but it wouldn't solve what is on the images
16:05:38 <pwhalen> Typically we pick the most recent compose for testing and to sign off on it
16:05:44 <pwhalen> this is what I did I guess.
16:06:00 <coremodule> pbrobinson, Okay, that makes sense to me.
16:06:16 <pbrobinson> yes, because once we're in freeze basically nothing changes unless we tag something into the iot override to fix/test a problem
16:07:07 <pbrobinson> nothing changes that is unless QE pushes things stable, the nightly build obviously pulls those in
16:07:16 <pwhalen> then once we sign off, we need another compose which is used for the actual release
16:07:41 <pwhalen> often this is to change stream, ie from devel to stable
16:08:15 <coremodule> Can I write that we'll plan to test the Friday compose following the Go/NoGo and release the Monday compose as the milestone?
16:08:50 <coremodule> Or that we'll be one compose behind because of the devel>stable push, regardless of which we choose, but we'll make sure that nothing changes between the two
16:09:14 <pbrobinson> coremodule: we'd want to be testing the go/no-go release
16:10:01 <coremodule> That's where I get lost, how do we pick which is the go/no-go release?
16:10:43 <pwhalen> As I said, typically we pick the most recent compose for testing and to sign off on it
16:10:55 <pbrobinson> we run a compose that has all the latest pushed bits, plus anything that is explicitly pulled in by the mainline compose requests
16:11:15 <pbrobinson> and we usually do that shortly after the compose request for mainline
16:11:51 <coremodule> Okay. We can move on, I
16:11:59 <pbrobinson> so it depends on when that request happens as to when the compose does, it might be the daily  compose on that day or we may have a .1 if it needs tagged packages
16:12:17 <pbrobinson> coremodule: well I'm putting things here that you can put in the doc
16:13:01 <pbrobinson> so I think that's all, coremodule are you going to contribute that to the IoT docs?
16:13:11 <coremodule> pbrobinson, yeah, I'm realizing I think I have a fundamental misunderstanding of how we do this, and I'm probably not the best one to write the doc without some 1x1 instruction.
16:14:07 <pbrobinson> coremodule: how about you do a draft and we can review it in a PR and contribute/provide feedback, that will help your as well as our learning :)
16:14:07 <pwhalen> coremodule: sorry, I'm not following
16:14:13 <coremodule> I guess my question is, how are we ensuring that the release we want to be the milestone is actually tested? So for F39 for example, I tested the Friday image, we shipped the Monday image. Can I consider the Monday image tested since nothing should have changed between the two?
16:15:12 <pwhalen> I would test both. Sorry, I dont know where the Friday stuff is coming from.
16:15:15 <pbrobinson> coremodule: yes, that's the way we've handled it and because everything is locked nothing has ever changed to date, and it's at times not necessarily a Mon, it's some point between sign off and Mon
16:16:11 <coremodule> Okay, got it. I will start a draft and go from there. Thanks for the input here.
16:16:24 <pwhalen> We test the last completed compose for the go/nogo meeting. Once we sign off on that, we need to do another official compose, often moving streams. That also needs to be tested to ensure I didnt mess something up
16:17:34 <pwhalen> definitely open to improvements on how we do this
16:18:00 <coremodule> pwhalen, Okay. I get the changing streams part, I have *not* been testing the compose after because... Well, I didn't know how we did this. Which is why I'm bringing it up. I'll open a ticket and start a draft and we can go from there.
16:18:02 <pwhalen> We do need a second compose after sign off though, and that also needs testing
16:19:11 <pwhalen> ok, sound good. Thanks for working on it. And definitely if you see how we can improve it let us know.
16:19:45 <coremodule> I think the process is fine and probably the best we can do with the way things are, I just want to get it documented.
16:19:52 <coremodule> Cool, sounds good.,
16:20:42 <pwhalen> ok. As pbrobinson mentioned we've recently discussed a possibility to avoid the second compose so we can sign off on the actual release, so that should get better
16:21:25 <coremodule> That'd be good. Thanks for humoring me here.
16:22:06 <pwhalen> #topic 2) ==== Fedora 39 - Stable ====
16:22:06 <pwhalen> #info OpenQA testing - https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=39&build=Fedora-IoT-39-20240105.0&groupid=1&groupid=5
16:22:45 <pwhalen> some of those failures should be fine when run again
16:23:10 <pwhalen> I'll do that now
16:23:27 <pwhalen> Any reported issues?
16:23:48 <coremodule> Nothing from me
16:25:08 <pwhalen> Someone reported issues with Zezere , looks to be ipv6 related again, perhaps
16:25:10 <pbrobinson> mor me
16:25:24 <djachimo> nothing from I
16:25:57 <pwhalen> #topic 3) ==== Fedora 40 - Rawhide ====
16:25:58 <pwhalen> #info OpenQA testing - https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=40&build=Fedora-IoT-40-20240105.0&groupid=1&groupid=5
16:26:27 <pwhalen> openqa testing isn't happening due to ..
16:26:57 <pwhalen> #link https://github.com/osbuild/images/issues/309
16:27:46 <pbrobinson> pwhalen: link the proposed features?
16:27:57 <pwhalen> Wil do after this bug
16:28:14 <coremodule> I ran a rawhide compose through a small battery of tests late last week on RPi 4 hardware, no issues found.
16:29:05 <pwhalen> nice, thanks coremodule. I've done some spot checking but I think its been a whil e
16:30:25 <pwhalen> We have a couple changes for F40
16:30:53 <pwhalen> #info Fedora IoT Unified Core - https://fedoraproject.org/wiki/Changes/Fedora_IoT_Unified_Core
16:31:47 <pwhalen> We're already building with unified core now, so its mostly for marketing and letting others know
16:32:47 <pwhalen> I am also going to do one for adding the simplified installer iso to our deliverables
16:32:56 <pwhalen> non release blocking
16:33:43 <pwhalen> using this  - https://fedoraproject.org/wiki/Changes/IoTSimplifiedInstaller
16:34:56 <pwhalen> er, simplified provisioning
16:36:02 <pwhalen> Anything else for f40?
16:36:36 <pwhalen> #topic 5) ==== General Bugs ====
16:36:51 <pwhalen> Any general issues not yet covered?
16:37:40 <pwhalen> #topic 6) ==== Open Floor ====
16:37:56 <pwhalen> Should we move the meeting over to matrix?
16:38:16 <pwhalen> I'm trying to use it more, seems like the IRC is becoming less used overall
16:38:44 <djachimo> I haven't touched it personally
16:38:50 <coremodule> Just before the break, the QA group moved it's meeting over to Matrix, not that we should jump ship because of that, but just some input to consider.
16:39:11 <pwhalen> djachimo: I think you'll like it more than IRC
16:39:31 <pbrobinson> I setup and got a client and other pieces up and running late last year
16:39:39 <djachimo> I think I'd like carrier pigeon more than IRC
16:39:42 <pwhalen> coremodule: right, seems like more people have made the change too
16:39:52 <pwhalen> djachimo: heh
16:40:12 <pwhalen> is anyone opposed?
16:41:15 <pwhalen> #info Fedora IoT meeting to move over to Matrix, details to follow on the mailing list.
16:41:28 <pwhalen> Anything else for today?
16:41:32 <pbrobinson> not from me
16:41:49 <pwhalen> #endmeeting