15:02:13 <mboddu> #startmeeting RELENG (2020-10-27)
15:02:13 <zodbot> Meeting started Tue Oct 27 15:02:13 2020 UTC.
15:02:13 <zodbot> This meeting is logged and archived in a public location.
15:02:13 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:13 <zodbot> The meeting name has been set to 'releng_(2020-10-27)'
15:02:13 <mboddu> #meetingname releng
15:02:13 <zodbot> The meeting name has been set to 'releng'
15:02:13 <mboddu> #chair nirik sharkcz pbrobinson pingou mboddu dustymabe ksinny jednorozec
15:02:13 <mboddu> #topic init process
15:02:13 <zodbot> Current chairs: dustymabe jednorozec ksinny mboddu nirik pbrobinson pingou sharkcz
15:02:19 <nirik> morning
15:02:29 <jednorozec> afternoon
15:02:36 <sharkcz> hi all
15:03:38 <mboddu> So, I have to cut short this meeting to 30 min as I have another meeting to attend
15:03:41 <mboddu> Lets get started
15:07:34 * nirik waits for it. ;)
15:09:11 <pingou> ó/
15:09:36 <mboddu> Sorry, my network got crashed while the system is being updated
15:09:38 * mboddu joined in another laptop
15:09:40 <mboddu> I dont know how much you guys have seen, but this meeting will be short due to another meeting in 20 min
15:09:43 <mboddu> pingou: Problems with rawhide :D
15:10:04 <pingou> on the top of iot?
15:10:31 <mboddu> iot?
15:10:49 <nirik> which rawhide problem? ;)
15:11:16 * pingou marks problems has solved
15:11:21 <pingou> there :)
15:11:56 <mboddu> Okay... :)
15:12:00 <mboddu> #topic #9821 Consider issues with a point release
15:12:09 <mboddu> #link https://pagure.io/releng/issue/9821
15:12:17 <mboddu> So...
15:12:44 <nirik> yeah, there seems to be 2 ways to do this...
15:12:45 <mboddu> We could a RC 1.3 and just do the sync as a normal release
15:12:52 <nirik> and they each cause problems
15:13:08 <mboddu> nirik: Go for it
15:13:55 <nirik> if we call it f34, it means we have to do branching/koji tags/etc... all really quickly.
15:14:18 <nirik> if we call it just f33 it's going to confuse people since we already released 33.
15:14:47 <nirik> 33.1 will break fedfind and bodhi and such...
15:15:18 <mboddu> Why would it confuse people? We release another rc and no one will notice it and just tell people we updated the images
15:15:19 <nirik> not sure what is best here.
15:15:28 <mboddu> No changes to links and everything works as well
15:15:32 <mboddu> as usual*
15:15:34 <nirik> if we are only doing images
15:16:04 <nirik> pxe will still be broken in that case.
15:16:20 <mboddu> How does pxe work?
15:16:57 <nirik> dhcp gives you a server and you download a kernel and initramfs from it, you boot and pull the installer image over to install.
15:18:17 <mboddu> Where does it pull the content from?
15:18:19 <nirik> so if we want that fixed also we should just sync the entire new compose over the old one... (with hardlinks)
15:18:33 <mboddu> Yes, which is what I am suggesting
15:18:40 <nirik> admin gets the vmlinuz/initramfs from us and puts it on their server.
15:19:17 <nirik> https://dl.fedoraproject.org/pub/fedora/linux/releases/33/Everything/x86_64/os/images/pxeboot/
15:19:42 <nirik> but perhaps we decide thats not a big deal... I guess we need to decide the scope here.
15:20:00 <nirik> perhaps it's just x86_64 bootable images?
15:20:07 <mboddu> Yes, they are getting it from our mirrors, so I am suggesting full sync of the compose
15:20:45 <nirik> right, thats going to cause confusion, but might be the way to go
15:21:08 <mboddu> I feel like syncing bit and pieces might cause more confusion than everything
15:21:43 <mboddu> We just say, "Hey, we did a new compose for f33 which fixes the bootloader issue and they are just available at normal f33 downlodable locations"
15:21:48 <nirik> well, alternately if we just make x86_64 bootable media and pxe stuff we could put it in a 33.1/ dir, but that would break fedfind and similar.
15:21:48 <mboddu> But better worded :D
15:21:52 <sharkcz> can we limit the rc 1.3 to x86_64 only? I would like to avoid dropping some of the other (non-blocking) artifacts
15:22:03 <sharkcz> in case something fails
15:22:17 <nirik> the problem is the same as when an upstream re-releases something...
15:22:38 <mboddu> sharkcz: We already locked f33 tag, so nothing will be coming into it, we will just add shim to it and run a compose
15:22:47 <nirik> "I have this bug in f33!" "which f33?" "my f33 checksums no longer match but gpg says the checksum file is right"
15:23:12 <mboddu> Yeah, we need to be very vocal about it
15:23:13 <nirik> its really bad release engineering to release the same thing twice.
15:24:21 <mboddu> "Which f33?" issue will arise if we sync full compose or few images, to avoid that, we need to put it in a different dir and call it .1 release
15:24:30 <nirik> yep.
15:24:53 <nirik> so, perhaps I could add a list of questions to the ticket and we can try and see if we can get answers
15:25:01 <nirik> and that might help us decide which way to go?
15:25:08 <mboddu> And admins should know which images to pull for pxeboot and fedfind..., dont know?
15:25:18 <mboddu> +1
15:25:43 <pingou> hm, where is bodhi involved in the compose/release?
15:26:19 <nirik> well, thats another point of confusion...
15:26:30 <nirik> "hey shim says it's in updates, but it's in the base repo"
15:26:46 <nirik> and if we do a 33.1... "where is 33.1 in bodhi?"
15:27:37 * mboddu is back on multi monitor
15:27:39 <mboddu> Yeah, we could just tag it into f33?
15:27:47 <pingou> I'm more tempted by 33.1, but I don't quite understand why we care about bodhi for this
15:28:31 <mboddu> More like, base repo will have new shim where as according to bodhi, it will be in updates repo
15:29:31 <mboddu> Or just use https://dl.fedoraproject.org/pub/alt/unofficial/releases/ ?
15:29:32 <pingou> I like that problem more than the: checksums for F33 no longer match
15:30:54 <nirik> mboddu: which just looks bad...
15:31:17 <nirik> "In order to boot your computer with secure boot, please use this unofficial image..."
15:31:22 <mboddu> checksums matching is more like a problem if the users are in the dark, they downloaded 1.2 when we synced 1.3 their checksums will not match, but they can download 1.3 and match them again
15:31:38 <mboddu> nirik: Right
15:31:51 <mboddu> I understand, but throwing out the options
15:32:09 <nirik> yeah, we are gonna need to pick the 'least bad'
15:32:53 <pingou> +1
15:33:02 <sharkcz> +1
15:33:04 <mboddu> I feel like, run rc 1.3 and sync it to current releases/33 dirs
15:33:16 <pingou> mboddu: or they have the checksum from a previous download (for some reasons)
15:33:23 <mboddu> Seems like the least problamatic
15:33:41 <mboddu> pingou: Yeah, that too ;)
15:34:17 <pingou> for the new shim in base vs updates, how often do people check the content of the repo themselves?
15:34:19 <pingou> :)
15:35:32 <mboddu> Not much, but if they do, they will be confused
15:35:48 <pingou> so same for the checksums
15:36:05 <pingou> while checksums are more end-users and repo more power-users
15:36:36 <pingou> I do like nirik's idea to ask questions on the ticket and see from the response which way we go
15:37:18 <pingou> (we don't have the fix yet anyway right? so we don't need to answer it now, right?)
15:37:39 <nirik> yes, there is not a fix yet
15:37:50 <nirik> but we might also have to do arm images for another thing
15:38:11 <pingou> 2020 is soo much fun!!
15:38:53 <nirik> you bet
15:39:53 <mboddu> It is
15:39:57 <mboddu> Anyway, I need to run
15:40:24 <mboddu> Thanks nirik for offering to updating the ticket
15:40:29 <mboddu> I will comment on the ticket as well
15:40:38 <mboddu> Thanks everyone for joining
15:40:47 <mboddu> And sorry for all my rawhide problems
15:40:50 <pingou> thanks for chairing :)
15:40:58 <mboddu> Now its crashing both chromium and FF
15:41:12 <pingou> "this is probably fine"
15:41:18 <nirik> firefox is known.
15:41:23 <nirik> downgrade to -3
15:41:32 <mboddu> Yeah, I will try downgrading both
15:41:56 <nirik> or -2
15:41:58 <mboddu> #endmeeting