15:01:03 <mboddu> #startmeeting RELENG (2020-09-29)
15:01:03 <zodbot> Meeting started Tue Sep 29 15:01:03 2020 UTC.
15:01:03 <zodbot> This meeting is logged and archived in a public location.
15:01:03 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:03 <zodbot> The meeting name has been set to 'releng_(2020-09-29)'
15:01:03 <mboddu> #meetingname releng
15:01:03 <zodbot> The meeting name has been set to 'releng'
15:01:03 <mboddu> #chair nirik sharkcz pbrobinson pingou mboddu dustymabe ksinny jednorozec
15:01:03 <zodbot> Current chairs: dustymabe jednorozec ksinny mboddu nirik pbrobinson pingou sharkcz
15:01:03 <mboddu> #topic init process
15:01:17 <nirik> morning
15:01:58 <Southern_Gentlem> congrats on another release
15:02:05 <pingou> ó/
15:02:09 <pingou> mboddu++
15:02:20 <mboddu> #topic Fedora 33 Beta
15:02:38 <mboddu> #info Fedora 33 Beta is out today
15:03:12 <mboddu> #info Fodora 33 Final freeze starts in a week on 2020-10-06
15:03:45 <pingou> Fodora? :)
15:03:47 <mboddu> Who says naming is hard, I came up with a new project/product name - Fodora :D
15:03:56 <mboddu> #undo
15:03:56 <zodbot> Removing item from minutes: INFO by mboddu at 15:03:12 : Fodora 33 Final freeze starts in a week on 2020-10-06
15:04:02 <mboddu> #info Fedora 33 Final freeze starts in a week on 2020-10-06
15:05:30 <sharkcz> hi all
15:05:37 <nirik> morning sharkcz
15:07:00 * mboddu waves at sharkcz
15:07:18 <sharkcz> and /me waves back :-)
15:07:27 <mboddu> Okay, moving on
15:07:31 <mboddu> #topic #9773 Add RAWHIDEFTBFS and RAWHIDEFTI aliases to trackers
15:07:37 <mboddu> #link https://pagure.io/releng/issue/9773
15:07:48 <mboddu> So, aliases in bz...
15:07:51 * mboddu googles it :D
15:07:59 <nirik> sounds fine to me.
15:08:43 <nirik> we can action bcotton to do it. ;)
15:10:13 <mboddu> Okay, I have no idea how to do it
15:10:31 <nirik> it's just a field in bugzilla IIRC
15:11:04 <sharkcz> yup, and you can have multiple aliases set IIRC
15:11:12 <pingou> we talked a while back about stopping to use rawhide for F-XX instead
15:11:20 <pingou> (like on mirrors & build target)
15:11:44 <nirik> yes. we should try and push that forward again.
15:12:04 <nirik> then the FNN ones can be the alias. :)
15:12:17 <pingou> wouldn't that alias be a step backward in that regard?
15:12:50 <nirik> I don't think so... I guess we could drop it until branch appears...
15:13:25 <mboddu> pingou: Nope, people would like to know for what release the package failed to build rather than looking at the timeline and figuring out what rawhide was pointing to then
15:13:28 <pingou> don't we already have the FXXFTBFS and FXXFTI aliases?
15:13:40 <nirik> yes.
15:13:56 <pingou> I'm confused
15:14:04 <nirik> but this is so ELN doesn't have to change that every few months. they can alawys look for the RAWHIDE one
15:14:31 <pingou> (honestly I don't mind either way, I was merely asking for consistency reasons)
15:14:54 <nirik> right now: Oh, I have an eln bug to file, let me look up what 'rawhide' is... ok, it's f34, so I need the F34Blocker bug
15:15:18 <nirik> after this: Oh, I have an eln bug to file, let me file against RAWHIDE bug
15:15:34 <nirik> ie, saves them a lookup... for soemthing that we still don't have a good answer how to get.
15:15:58 <pingou> ah ok, in addition to the product version field
15:16:08 <mboddu> Yes
15:16:26 <mboddu> pingou: It makes eln bug reporters to find the rawhide ftbfs, fti bugs easily
15:16:53 <pingou> anyway, let's move on, we spent too long on this
15:16:55 <mboddu> When we branch, we will change the alias, thats it right?
15:16:58 <mboddu> Yup
15:17:00 <nirik> you are right tho that once we ever land the 'make rawhide named rawhide' change we can only have the rawhide aliases on the bugs.
15:17:10 <nirik> mboddu: currently yes.
15:17:40 <mboddu> #info mboddu will work with bcotton and figure out how to add alias to the f34 ftbfs, fti bz's
15:18:10 <nirik> it's just a 'click on alias and add it' in the interface. ;)
15:18:11 <mboddu> #info When we branch, we will change the alias to point to f35 ftbfs, fti bz's
15:19:00 <nirik> when we branch we will have to move the rawhide alias to the new bug and add a f35 one to that new bug, yeah.
15:20:05 <mboddu> Okay
15:20:06 <mboddu> Moving on
15:20:56 <mboddu> #topic #9266 prune EOL content from OSTree repos
15:21:00 <mboddu> #link https://pagure.io/releng/issue/9266
15:21:36 <mboddu> nirik: Last time I remember, you are looking into this? Or at least worked with Dusty to come up with a way to handle this
15:22:02 <nirik> I thought we had it pretty much ready, but needed to do final testing and then enable... but I could be misremembering
15:23:51 <nirik> Hopefully dusty would know more.
15:24:58 <mboddu> Okay, I will ping Dusty on the ticket
15:27:16 * nirik gets more coffee, back in a few min
15:30:21 <mboddu> #topic #8478 Retired packages should close rawhide bugzilla as WONTFIX or EOL
15:30:22 * nirik is back
15:30:28 <mboddu> #link https://pagure.io/releng/issue/8478
15:30:38 <mboddu> Should we take this to fedpkg?
15:30:48 <mboddu> Or should we create a toddler?
15:31:03 <mboddu> I think toddler makes sense
15:31:04 <nirik> didn't pingou work on this one? or am I misremembering...
15:31:08 <nirik> there was an infra ticket
15:31:27 * mboddu searches
15:31:43 <jednorozec> sorry for being late, there was a bit of rain over here and I had to dig a trench to get the water away from the house down the hill.
15:31:57 <nirik> oh, it was closing retired packages to new bugs...
15:32:03 <nirik> https://pagure.io/fedora-infrastructure/issue/7639
15:32:11 <nirik> jednorozec: yikes. Stay safe. ;)
15:32:46 <mboddu> jednorozec: Oh, thats bad...
15:32:49 <nirik> so, perhaps that same process that closes retired components to new bugs could close old ones... but is this really needed? they would get EOLed anyhow...
15:32:50 <jednorozec> mboddu, I would say lets use the script that miro has provided and port it to toddler
15:33:16 <nirik> and if someone unretires the package, all those bugs would be closed, so they couldn't easily see what needs fixing.
15:33:17 <mboddu> nirik: Yeah, but they get EOL'd when the release goes EOL
15:33:44 <nirik> right...
15:33:58 <mboddu> nirik: Right, I guess you are right when the pkg gets unretired
15:34:00 <nirik> but whats the advantage of closing them sooner? I just see disadvantage
15:35:08 <jednorozec> I can imagine that lots of opened BZs can slow down some queries
15:35:11 <nirik> so, I'd say further discussion
15:36:03 <nirik> I doubt by much in the larger picture...
15:37:27 <pingou> toddler should do it
15:37:31 <mboddu> I agree with nirik on this, when the unretirement happens, we need to figure out what are the bz's that we closed and reopen them
15:37:38 <pingou> distgit-bz-sync should do it
15:37:44 <pingou> and it's being merged into toddlers
15:37:57 <jednorozec> reopening the issues on unretirement should not be a problem
15:38:21 <pingou> but nirik is rigth, it closes retired packages to new bug, it doesn't close existing bugs (which should be assigned to orphan)
15:38:27 <jednorozec> there was some discussion on devel list, one point is valid. It will bring more consistency
15:39:05 <nirik> how would you keep track of what to reopen on unretirement?
15:39:16 <pingou> we do remove all CC/watchers on retired packages (monthly)
15:39:24 <pingou> which should remove these people from these bugs
15:39:39 <nirik> I guess looking at it from the user side it's better to close...
15:39:50 <nirik> (since there's not much hope it would be fixed)
15:41:14 <nirik> I just worry that we will get: package foo has a bunch of bugs, it gets retired, we close the bugs, some time later someone comes along and unretires it... and all those bugs are still in it, but they don't realise it.
15:41:42 <nirik> we could also ask devel or punt to fesco if we want more input.
15:41:48 <jednorozec> that is a good point
15:41:49 <mboddu> So, here's my plan:
15:42:08 <mboddu> retire: assign the bz's to orphan and close - wont fix
15:42:27 <mboddu> unretire: find the bz's associated to that pkg that are assigned to orphan and reopen them?
15:42:39 <mboddu> And assign the bugs to the new maintainer
15:43:20 <nirik> yeah, we could do something like that...or a whiteboard of 'retiredbug' and look for that...
15:43:21 <pingou> how many packager do we think will go through the existing bugs to figure out if they are still valid or not?
15:43:47 <nirik> also a good question. ;) Just because they are there and even open they could just ignore them.
15:43:50 <pingou> (vs asking the users to re-open the bug they reported, if they are still valid)
15:44:24 <nirik> when someone reopens a bug... does it reassign it to the current contact?
15:45:05 <mboddu> I think it does
15:45:22 <pingou> dunno
15:46:50 <nirik> just seems like ignoring them would be the easiest way. ;)
15:47:02 <pingou> +1
15:47:08 <nirik> The only one that would ever get email from them is the old point of contact right?
15:47:14 <pingou> tbh, I find the current situation ok
15:47:27 <pingou> the bugs are orphaned, w/i a month all the people CC'ed will be removed
15:47:34 <pingou> when Fedora goes EOL, the bugs are closed
15:47:54 <mboddu> So... ?
15:47:57 <pingou> (w/i a month -> after the package is retired)
15:48:03 <mboddu> Lets vote:
15:48:07 <mboddu> 1. Leave as is
15:49:04 <mboddu> 2. Ask devel@ for the options, a: when unretired, assign the bugs to the new maintainer b: when unretired, dont do anything and leave it to the new maintainer
15:50:10 <smooge> 2.
15:50:35 <pingou> I'd be for #1 or #2.b (with a potential mitigation: send the new maintainer a list of the old bugs closed - up to them to see what they want to do with it)
15:51:19 * pingou needs to step out
15:51:22 <nirik> same as pingou
15:52:35 <mboddu> nirik: Step out or 1 or 2.b with modification?
15:53:06 <nirik> same vote as pingou: #1 preferred, 2B otherwise.
15:55:15 <mboddu> Okay
15:55:49 <mboddu> And jednorozec seems to be on board with 2 in general
15:56:26 <mboddu> So, lets go with 2b, and in that case we dont need to ask devel@ list, right? We know what we need to do
15:56:47 <nirik> well, wait...
15:56:55 <nirik> whats the different then between 1 and 2B?
15:57:14 <mboddu> 1 is dont do anything, leave as it is right now
15:57:50 <mboddu> 2b is when retirement happens close the bugs with wont fix and when unretirement happens send a  list of the old bugs closed
15:58:02 <mboddu> to the new maintainer
15:58:31 <nirik> ah I see.
15:59:08 <nirik> I think 2b is a waste of time/work on our part. ;) but if everyone else wants to do that...
15:59:53 <mboddu> Well, we will update the ticket with the thing we have decided and we will get to it if we can or ask for the community to pick it up
16:00:25 <mboddu> I will update the ticket
16:00:29 <mboddu> #topic Open Floor
16:00:36 <mboddu> So, I have an update
16:00:46 <mboddu> https://pagure.io/releng/issue/9577#comment-688916
16:01:00 <mboddu> fmw 4.16 is verified, thanks jednorozec and nirik
16:01:18 <mboddu> I filed a websites ticket to update them
16:02:35 <mboddu> Anything else before I close the ticket
16:02:37 <nirik> I think we just need to put them on sundries and it's updated.
16:02:45 <mboddu> s/ticket/meeting/ :D
16:02:46 <nirik> and I already put the mac one there.
16:03:01 <mboddu> I will place the win one
16:03:09 * nirik has nothing off hand.
16:04:02 <mboddu> Thanks everyone for joining
16:04:05 <mboddu> #endmeeting