21:00:35 <tdawson> #startmeeting EPEL (2020-09-18)
21:00:35 <zodbot> Meeting started Fri Sep 18 21:00:35 2020 UTC.
21:00:35 <zodbot> This meeting is logged and archived in a public location.
21:00:35 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:35 <zodbot> The meeting name has been set to 'epel_(2020-09-18)'
21:00:36 <tdawson> #meetingname epel
21:00:36 <zodbot> The meeting name has been set to 'epel'
21:00:37 <tdawson> #chair nirik tdawson bstinson Evolution pgreco carlwgeorge
21:00:37 <zodbot> Current chairs: Evolution bstinson carlwgeorge nirik pgreco tdawson
21:00:39 <tdawson> #topic aloha
21:00:44 <michel_slm> .hello salimma
21:00:45 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
21:00:56 <bstinson> hey all
21:01:00 <tdawson> Hi michel_slm
21:01:03 <tdawson> Hi bstinson
21:01:24 <tdawson> nirik has already let me know he won't be here.
21:01:26 * cyberpear listens in
21:01:34 <tdawson> Hi cyberpear
21:01:38 <michel_slm> hi tdawson , bstinson
21:01:41 <pgreco> oh, I'm here
21:01:46 <tdawson> Hi pgreco
21:03:01 <carlwgeorge> howdy yall
21:03:12 <tdawson> Hi carlwgeorge
21:04:24 <michel_slm> Hi pgreco, carlwgeorge
21:05:02 <tdawson> #topic Old Business
21:05:13 <tdawson> epel8-playground
21:05:17 <tdawson> This should be quick
21:05:32 <tdawson> All the bugs and issues are in, and most are done.
21:06:00 * michel_slm says goodbye to package.cfg
21:06:00 <tdawson> I am planning on sending out documents and announcements early next week (hopefully monday)
21:06:16 <pgreco> michel_slm: and really happy to!
21:06:39 <tdawson> :)  And I will be removing any package.cfg that users haven't already removed on Thursday.
21:07:26 <tdawson> Hmm ... maybe I need to send out the email today ... we'll see if I have time after this meeting.
21:07:53 <tdawson> We'll give it at least one week before we start cleaning up the automatically built packages.
21:08:34 <michel_slm> as someone with quite a few EPEL packages I'm happy to have it auto-cleaned
21:08:35 <tdawson> I think that's it ... any questions before we move on?
21:09:21 <tdawson> Me too
21:09:40 <tdawson> I think next we have epel8-next
21:10:00 <tdawson> carlwgeorge ... do you want to take the floor
21:10:18 <carlwgeorge> sure
21:10:53 <carlwgeorge> i sent a summary to the list about the dist manipulation, but it hasn't received any direct feedback
21:11:23 <carlwgeorge> right now i'm leaning towards .el8.next
21:11:49 <pgreco> +1 on that, the koji limitation is a big impediment IMO
21:11:52 <carlwgeorge> side question, if playground is .epel8.playground, why aren't regular builds .epel8?
21:12:25 <carlwgeorge> because i'm sure at some point someone will ask why it's .epel8.playground but .el8.next
21:13:15 <pgreco> I'm not sure we even talked about it when playground was set
21:13:26 <bstinson> i'm guessing that's a "it's always been like that" thing for the main epel channels
21:13:27 <pgreco> I think smooge would know a bit more
21:13:48 <carlwgeorge> i'm fine with either .el8.next or .epel8.next, i'm just a sucker for consistency
21:13:54 * tdawson agrees with bstinson and pgreco.  I think "it's always been like that" and smooge would know.
21:13:58 <bstinson> i know we've had the .el\d disttag since 4
21:14:13 <carlwgeorge> and playground isn't consistent with main epel now
21:14:15 <King_InuYasha> do we want el8.next to universally win?
21:14:26 <michel_slm> branch names changed in epel7, right? it used to be el6 matching the disttag
21:14:33 <bstinson> yeah
21:14:34 <King_InuYasha> like, given the same EVR, do we want el8 to win over el8 next?
21:14:49 <bstinson> erm, that was a 'yeah' to the branch-name changes in epel8
21:14:51 <bstinson> *7
21:14:53 <michel_slm> deciding what we want to name it now might be nice so when el9 comes around everything is consistent :)
21:14:56 <bstinson> i need to stop typing for the day
21:15:04 <michel_slm> oh, el8 next should win, right?
21:15:05 <carlwgeorge> King_InuYasha: no, the next build should win
21:15:13 <michel_slm> since we only have packages there if el8 is broken on c8s
21:15:30 <King_InuYasha> carlwgeorge: okay
21:15:38 <carlwgeorge> it's basically an overrides repo
21:17:52 <carlwgeorge> the other big question mark for me is bodhi enablement.  i think it would be a good thing and give people more confidence in using centos stream.  doing automatic nightly composes would make people think it's like rawhide, and i don't want to encourage that.
21:18:25 <tdawson> I'm confused by that statement
21:18:45 <michel_slm> rawhide also uses bodhi but automatically goes to stable ,right? how do we see el8.next working?
21:18:54 <michel_slm> like fedora branched, so 3 days wait by default maybe?
21:19:00 <carlwgeorge> it would mean having epel-next and epel-next-testing repos, which as nirik mentioned is significantly more releng work.  i think it would be worth it, but that's easy for me to say not being part of releng.
21:19:31 <tdawson> Ah, so not have -testing repos, for less work.
21:20:04 <tdawson> But at the same time, would people be worried about using the repo, since there isn't a -testing repo.
21:20:19 <carlwgeorge> the concerns about stability could be mitigated by tests similar to the rawhide gating, but i'm not sure that has seen significant adoption
21:20:19 <pgreco> if it is going to be "epel for stream", I agree with carlwgeorge on both counts, the fact that it would be good to have it, and that we have no idea the releng work behind it
21:20:48 <michel_slm> this has to be the nirik-less meeting :p
21:21:28 <tdawson> :)
21:21:32 <pgreco> or he knew what we were going to ask, and decided that disappearing was easier than saying no ;)
21:21:48 <carlwgeorge> not surprisingly the devil is in the details.  but aside from what i've mentioned here and on list, does anyone have questions i can help clear up?
21:22:06 * michel_slm smells a conspiracy :p
21:22:27 <michel_slm> argh, the epel wrangler SIG topic could probably use nirik's input too
21:22:42 <tdawson> I'm still a little fuzzy on if you mean the repo to last beyond the next RHEL release, or have it be retired at some period of time after the last RHEL release.
21:23:40 <carlwgeorge> i think it's valid to stick around for the lifetime of the rhel release, as it's still valid for rhel betas
21:24:06 <carlwgeorge> and, during the centos linux rebuild gap, it gives maintainers a place to do a build to fix rhel compatibility without breaking for centos linux users
21:24:09 <tdawson> But wouldn't that mean you'd have to keep updating the build repository with each beta release?
21:24:15 <michel_slm> as long as minor releases are produced for elX then elX.next should exist, right?
21:24:30 <michel_slm> so there could be multiple elX.next branches in flight (el8.next, el9.next)
21:25:09 <carlwgeorge> tdawson: ah, good point.  after 8 stream is eol, the buildroot would need juggling (switching from rhel to rhel beta)
21:25:26 <tdawson> In theory, I like that.  In practice, I worry about the workload.
21:26:04 <King_InuYasha> carlwgeorge: there are a set of default tests that rawhide runs
21:26:11 <tdawson> Maybe if the workload could fall on the Stream team ... have epel-next build repo point somewhere on stream, and the STream team is the team that updates that repo.
21:26:12 <King_InuYasha> we can do the same for el-next
21:26:36 <King_InuYasha> installability, dependency checks, rpmlint, abicheck, etc.
21:27:05 <carlwgeorge> if those checks gave people confidence, more people would use rawhide
21:27:09 <tdawson> King_InuYasha: Can we get those for regular epel?
21:27:28 <tdawson> Actually, I've seen more people using rawhide.
21:27:56 <King_InuYasha> tdawson: in theory, yes
21:28:03 <tdawson> :)
21:28:06 <King_InuYasha> I think the only reason we don't have them is nobody asked Fedora CI to activate them
21:28:32 <King_InuYasha> it'd be nice if updates colliding with RHEL and not-installable packages bounced back with feedback like it does for Fedora
21:28:46 <tdawson> Yep
21:28:48 <King_InuYasha> PackageHub in openSUSE does this, and it's handy
21:28:58 <michel_slm> given this is a new repo, might be worth enabling all these and if it goes well, enable it for el8 too?
21:29:00 <King_InuYasha> (PackageHub is SLE's equivalent to EPEL)
21:30:13 <carlwgeorge> tdawson: for the buildroot reason, i wouldn't argue with eol-ing epel8-next at the same time as c8s
21:30:35 <King_InuYasha> oh, does this mean that we're getting c9s with s390x?
21:30:41 <King_InuYasha> (please let that be true...)
21:30:46 <carlwgeorge> but i also would be happy to get more involved with releng and be responsible for those buildroot changes
21:30:52 <pgreco> I'd like to set the params for the minimal working version, and stretch goals
21:31:03 <pgreco> so we don't get lost in the details :)
21:31:13 * michel_slm will be back in 5 mins
21:31:14 <King_InuYasha> well, minimal is rawhide gating :D
21:31:15 <bstinson> King_InuYasha: including s390x is our intent for c9s
21:31:28 <King_InuYasha> bstinson: yay, that means mock emulated builds will work :D
21:32:38 <tdawson> I think we have three subjects going on, so I'm not sure which pgreco was commenting on.
21:32:38 <carlwgeorge> if we go with gating style only (no -testing), how hard would that be to add on later?
21:33:07 <King_InuYasha> straightforward, generally
21:33:10 <King_InuYasha> it's just another layer
21:33:21 <King_InuYasha> and you're retargeting from pending->testing instead of pending->stable
21:33:23 <bstinson> wrt workloads, i'm hesitant to give this formally to carlwgeorge in his CPE capacity without making sure we give him some cover with management, but of course his free time is fair game ;)
21:33:55 <King_InuYasha> carlwgeorge: I would expect that we're talking about a conversion from rawhide gating to branched gating configurations
21:34:11 <King_InuYasha> that workflow already exists, so adding -testing later shouldn't be difficult
21:34:26 <King_InuYasha> it could also exist from the beginning and just not get used
21:34:36 <King_InuYasha> I'm pretty sure that's how it works internally anyway
21:34:37 * michel_slm back
21:34:38 <carlwgeorge> in that case, i'm ok with not having -testing at first
21:35:08 <tdawson> welcome back michel_slm
21:35:40 <pgreco> tdawson: mostly what do we want for el8.next to be up running, if we want bodhi initially or can be deferred for the next stage
21:35:41 <carlwgeorge> does anyone want to fight me on the next name?  seems like most list replies were about calling it stream.
21:36:10 <tdawson> carlwgeorge: I'm fine with "next"
21:36:15 <King_InuYasha> carlwgeorge: mattdm was pretty set on stream, though I think next is fine
21:36:21 <pgreco> we know the reasons for not being stream, so el8.next (or epel8.next) is fine with me
21:36:48 <King_InuYasha> besides, being brand-agnostic is beneficial for us anyway
21:36:48 <King_InuYasha> it'
21:36:56 <King_InuYasha> it's not like CentOS is the _only_ consumer
21:36:59 <michel_slm> if we pick next I guess we should also make it discoverable if someone search for stream
21:37:18 <michel_slm> but yeah stream is so overloaded
21:37:34 <King_InuYasha> and yes, I'm getting sick of "stream" being attached to fifty different things (!!!)
21:38:02 <tdawson> carlwgeorge: Do we have enough to move things back to email and/or next meeting?  I want to give the time to the wranglers.
21:38:31 <carlwgeorge> works for me.  i'll try to sync up with nirik before the next meeting to learn more about the releng work involved.
21:38:45 <tdawson> OK, sounds good.
21:38:56 <King_InuYasha> A+ :D
21:39:10 <tdawson> michel_slm - Do you want to take the floor for EPEL-Packaging-SIG ?
21:39:18 <michel_slm> yup!
21:39:42 <pgreco> good for tdawson delegating everything today ;)
21:40:19 <michel_slm> so, there was an existing aborted effort and a pre-existing SIG called epel-wranglers, that we should either resurrect or delete completely. naming-wise it seems that the convention is for SIGs to end in -sig so maybe nuke that, and have epel-packagers-sig or epel-maintainers-sig?
21:40:46 <King_InuYasha> is epel-wranglers associated with any existing releng cruft?
21:40:51 <King_InuYasha> if so, we may want to reuse that
21:40:59 <King_InuYasha> otherwise I think changing to something new would be better
21:41:00 <michel_slm> per our discussion last week I posted in devel- and epel-devel-, and there seems no objection to having this, with some discussion about how to actually automate the proces
21:41:28 <King_InuYasha> but I don't have a strong opinion either way
21:41:33 <michel_slm> bstinson and sgallagh were involved in that, I think? afaik nothing has happened yet
21:41:52 <michel_slm> Miro suggested the -sig naming when I asked him about my other SIG (Lua packagers)
21:42:00 <tdawson> I'll just say I'm not a big fan of the "wrangler" name ... I'll be honest, I'd heard of it before and had no idea what it was until this conversation.
21:42:35 <bstinson> i have no attachments to epel-wranglers
21:42:40 <tdawson> So I'm in favor of the epel-<something>-sig name
21:42:46 <bstinson> i don't think it has anything structural attached
21:43:06 <King_InuYasha> tdawson: we used to have -wranglers, -zappers, etc.
21:43:08 <King_InuYasha> for various things
21:43:13 <King_InuYasha> most of them died with Fedora Legacy
21:43:14 <pgreco> If using the name saves something in releng work, I'd be ok, but if it doesn't, I prefer something else
21:43:19 <michel_slm> so I guess what I hope we can decide today is, what's the next steps? the consensus seems to be that automating can come later and we can figure it out later, but we can start the SIG now.
21:43:20 <michel_slm> I can request the SIG ACL and mailing list today, and start by adding this SIG to my packages and then announce it
21:44:01 <carlwgeorge> i like the simplicity of just calling it epel-sig
21:44:04 <pgreco> michel_slm: epel-whatever-sig (or even epel-sig) is fine bye me
21:44:10 <michel_slm> epel-sig sounds fine, yeah
21:44:17 <pgreco> *by
21:44:31 <michel_slm> so: check with nirik (or someone else) if there's existing support for epel-wranglers, if not, call it epel-sig?
21:44:41 <pgreco> +1
21:44:45 <King_InuYasha> sounds fine to me
21:44:53 <King_InuYasha> I'm pretty sure epel-sig already exists too
21:45:01 <michel_slm> and then just get it out of the door; I can start a pagure project and we can track any planned automation later
21:45:03 <King_InuYasha> if it doesn't, I'd be really surprised
21:45:05 <michel_slm> oh let me check
21:45:14 <tdawson> https://fedoraproject.org/wiki/EPEL_SIG
21:45:21 <King_InuYasha> *something* must be tied to epel@ and such
21:45:31 <King_InuYasha> that's how all the other SIGs work
21:45:49 <King_InuYasha> so we probably _can't_ use that
21:45:50 * michel_slm sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/JoukeGELttKShSZKtImUdeQv/message.txt >
21:45:59 <King_InuYasha> well then
21:46:08 <King_InuYasha> let's go with epel-packagers
21:46:12 <King_InuYasha> if we can
21:46:23 <King_InuYasha> (that is, if nothing existing is wired into epel-wranglers)
21:46:24 <tdawson> epel-packagers-sig ... so it ends in -sig
21:46:28 <michel_slm> epel-packagers-sig sounds good
21:46:29 <michel_slm> yup
21:46:34 <King_InuYasha> right, that's a thing that current FAS requires
21:46:39 <King_InuYasha> I keep forgetting that
21:46:59 <King_InuYasha> (it used to not, and now it does, and soon won't again)
21:47:05 <michel_slm> with an associated mailing list only so we can get bugzilla to work. we don't need a discussion mailing list for this, right, epel-devel is enough
21:47:15 <King_InuYasha> yeah, please no more mailing lists
21:47:16 <carlwgeorge> what's wrong with just making the existing epel sig group become what we want it to be?
21:47:17 <michel_slm> "soon won't again" -- huh, TIL.
21:47:37 <tdawson> Hmm ... carlwgeorge has a point ... nothing has touched epel-sig since 2014
21:47:37 <King_InuYasha> carlwgeorge: I don't want to touch the picket fence if I don't have to
21:47:40 <michel_slm> carlwgeorge: which group is that? I don't see an epel-sig ACL group. oh, epel-wranglers?
21:47:57 <michel_slm> ah, gotcha. where's that group anyway?
21:48:00 <carlwgeorge> whatever King_InuYasha was referencing about epel@ and not being able to use it
21:48:14 <michel_slm> https://fedoraproject.org/wiki/EPEL_SIG
21:48:24 <King_InuYasha> carlwgeorge: no I'm referring to that mailing lists have to be owned by a group
21:48:24 <michel_slm> oh wow there's a lot of names there
21:48:31 <King_InuYasha> yes... it's quite an old list
21:48:51 <bstinson> heh, we also have an epel-cabal FAS group...which is an even older iteration of what we're trying to do here
21:48:53 <King_InuYasha> nowadays FAS + pagure groups usually manage this
21:48:56 <michel_slm> isn't that the EPEL steering committee though. like, it has regular meetings
21:48:59 <King_InuYasha> yes
21:49:28 <King_InuYasha> pardon the dust, old fedora was messy :D
21:49:32 <michel_slm> we can archive that page and point it to both the EPEL SC and the new packaging SIG, since I think those are separate
21:49:36 <michel_slm> *separate concerns
21:50:05 * King_InuYasha still remembers all the insanity around setting this stuff up in the beginning
21:50:16 <tdawson> One thing about having it called "epel-packaging-sig" is that it's very clear what the sig is.  Nothing fuzzy.
21:50:21 <King_InuYasha> yup
21:50:24 <michel_slm> the packaging sig will be more similar to e.g. the python sig or provenpackager, the SC might be more like, um, fedora council for epel?
21:50:44 <King_InuYasha> I wonder if we can get these names changed when we migrate to the new system
21:50:50 <King_InuYasha> some of this are... eugh
21:51:11 <michel_slm> I like the regularity of enforcing -sig names for... SIGs
21:51:18 <michel_slm> ok. anything else we need to discuss today?
21:51:23 <King_InuYasha> nah, I think we're good
21:51:36 <King_InuYasha> (the -sig thing becomes a problem when they "upgrade" to working groups)
21:51:40 <tdawson> michel_slm: Thank you very much for championing this
21:51:50 <King_InuYasha> I'm looking forward to this getting off the ground
21:52:10 <tdawson> Othere than some minor naming things, I haven't heard anyone against it.
21:52:14 <King_InuYasha> (oh, and technically the fedora term for all this now is "teams", to make things even more confusing)
21:52:19 * michel_slm sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/fcJcWoDbbRzPbAHduarEAxiR/message.txt >
21:52:29 <michel_slm> King_InuYasha: now my brain hurts
21:52:37 <King_InuYasha> yup
21:52:44 <michel_slm> thanks everyone for your input! let me know if I got anything wrong in the summary
21:52:49 <King_InuYasha> looks good to me
21:52:57 <bstinson> michel_slm++
21:52:57 <zodbot> bstinson: Karma for salimma changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
21:53:00 <King_InuYasha> though that message did not expand in IRC
21:53:08 <King_InuYasha> so it's not going to be in the logs
21:53:13 <michel_slm> oof
21:53:20 <King_InuYasha> paste one at a time?
21:53:30 <michel_slm> #1 I'll get epel-packagers-SIG and a bugzilla mailing list set up
21:53:43 <michel_slm> #2 start a Pagure project, propose potential automation as issues there
21:53:50 <michel_slm> #3 announce in devel- and epel-devel-
21:54:08 <tdawson> Sounds good.
21:54:12 <King_InuYasha> looks awesome
21:54:22 * King_InuYasha wishes zodbot was matrix native...
21:54:22 * michel_slm going to set up weechat for IRC since Matrix is sometimes weird
21:54:43 <tdawson> WE have 5 minutes left ...
21:54:45 <King_InuYasha> I use KVirc specifically just for IRC meetings
21:54:49 <tdawson> #topic General Issues / Open Floor
21:54:50 <tdawson> #info https://pagure.io/epel/issues
21:55:23 <tdawson> #info EPEL-6 is End of Life in 2020-11. It will be moved to archives in 2020-12
21:55:25 <tdawson> #info THIS IS NOT A DRILL - Less than 2 months left
21:55:38 <King_InuYasha> I'm happy about this :D
21:55:45 <King_InuYasha> no more caring about systemd-less systems
21:55:55 <tdawson> :)
21:56:03 <michel_slm> I'll pop open the champagne on that day
21:56:05 <King_InuYasha> I have ~100K of code to delete after the EOL
21:56:29 <King_InuYasha> and I'm going to enjoy deleting every line of code
21:56:56 <tdawson> Anything for EPEL7 or 8?
21:57:01 <michel_slm> King_InuYasha: start a Dead Code Society at Datto now, and award yourself a tshirt for a cleanup
21:57:08 <King_InuYasha> :D
21:57:17 <pgreco> I haven't received any answer on those 1 and 2 year old packages in bohdi (for epel7), should we nuke them or leave them there?
21:58:02 <tdawson> pgreco: I'd say nuke them.  I'm not positive they will install in an expected way.
21:58:11 <King_InuYasha> nuke
21:58:24 <pgreco> ok, who has the red button?
21:58:37 <tdawson> pgreco: Are any of my previous "these will go away" messages on those?  If not, I can put them on.
21:58:55 <pgreco> let me check, but I don't think so
21:59:35 <pgreco> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d
22:00:41 <pgreco> tdawson: ok, not yours, but mine, please do as you see fit, warn/nuke :)
22:00:53 <pgreco> ok, out of time
22:00:55 <tdawson> pgreco: I'll get rid of them.   Especially that condor one since it's a -1
22:01:01 <tdawson> Yep
22:01:27 <tdawson> Thank you eveyrone for being here this week.  Very good discussions.  I'm glad of the progress EPEL is seeing on the various fronts.
22:01:42 <tdawson> Talk to you all next week, or earlier.
22:01:50 <tdawson> #endmeeting