21:00:22 <tdawson> #startmeeting EPEL (2020-09-04)
21:00:22 <zodbot> Meeting started Fri Sep  4 21:00:22 2020 UTC.
21:00:22 <zodbot> This meeting is logged and archived in a public location.
21:00:22 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:22 <zodbot> The meeting name has been set to 'epel_(2020-09-04)'
21:00:24 <tdawson> #meetingname epel
21:00:24 <zodbot> The meeting name has been set to 'epel'
21:00:25 <tdawson> #chair nirik tdawson bstinson Evolution pgreco carlwgeorge
21:00:25 <zodbot> Current chairs: Evolution bstinson carlwgeorge nirik pgreco tdawson
21:00:27 <tdawson> #topic aloha
21:00:36 <nirik> morning
21:00:41 <pgreco> hi
21:00:42 <tdawson> Hi nirik
21:00:50 <tdawson> Hi pgreco
21:00:55 <carlwgeorge> howdy yall
21:01:02 <michel_slm> hello all
21:01:09 <tdawson> Hi michel_slm
21:01:18 <michel_slm> nirik: you're on the West Coast right?
21:01:27 <nirik> yep. oregon, usa
21:01:45 <michel_slm> ah. Seattle here. Thought you were in Hawaii when you said morning ;)
21:02:14 <nirik> naw... I just always say that when I join a meeting/channel... it's UGT...
21:02:47 <nirik> http://www.total-knowledge.com/~ilya/mips/ugt.html
21:03:03 <michel_slm> TIL!
21:03:28 <nirik> my work here is done. :)
21:04:10 <pgreco> I just thought it was IDGAFT
21:04:22 <michel_slm> I have a topic to bring up but I'll wait until the open floor at the end
21:04:35 <tdawson> Huh ... that explains why I like to use "Hi"
21:05:10 <tdawson> I was sorta hoping we'd get carlwgeorge today ... buy maybe he'll get here a bit later.
21:05:17 * carlwgeorge waves
21:05:29 <tdawson> Hi carlwgeorge
21:05:32 <tdawson> #topic Old Business
21:05:33 <tdawson> epel8-playground
21:06:00 <tdawson> I figured we'd start of with the biggest ... epel8-playground
21:06:39 <nirik> I meant to reply to your last email, but been busy with other stuff.
21:06:47 <pgreco> yeah, there's a lot there, and the difference between what we "could" do and what we "can" do
21:07:27 <pgreco> we can discuss a lot about the "could" but I think the "can" is mostly nirik and smooge
21:07:39 <tdawson> Yep ... overworking the releng team is something I'm concerned about.
21:07:48 <nirik> I like the idea of parceling out what we can and doing it over time.
21:09:23 <nirik> FWIW, the report is already happening, it just goes to the releng-cron list... if we moved it to epel-devel it would be more visible, but also more automated noise...
21:09:40 <tdawson> nirik: Ah ... cool, so that step would be easy.
21:10:08 <tdawson> Ya, doing it right now would be too much noise ... let's wait until we change fedpkg and remove the files.
21:10:28 * nirik looks for an example
21:10:55 <nirik> https://lists.fedoraproject.org/archives/list/releng-cron@lists.fedoraproject.org/thread/XZ7AYEX63COJV2H52OPRM5ZMZPKIAJBW/
21:11:03 <nirik> but thats too technical/noisy...
21:11:17 <nirik> we may be able to generate something like the rawhide report for fedora-devel
21:12:01 <tdawson> Ya, ya it is.
21:12:27 <tdawson> But I'm betting once we get rid of the automatic builds, the noice should drop signifigantly.
21:13:57 <nirik> yeah, it should not send on days with no changes
21:14:29 <tdawson> I guess one of the first things we need to do, is approve that we move forward with it.  It being, changing playground to be a place for just major changes of packages.
21:15:35 <pgreco> same build env (rhel), only new things (additive to epel8), no package.cfg
21:15:40 <nirik> sure. I wish I knew what our maintainers wanted. ;)
21:16:10 <pgreco> the biggest question we get from packagers is "why do I have a package.cfg"?
21:16:23 <tdawson> nirik: From what I've heard, many of the maintainers have been against the automatic rebuilds.
21:16:29 <carlwgeorge> what about getting rid of playground, but still adding next?  make it clear that it's a new thing unrelated to the playground experiment.
21:16:34 <michel_slm> and "I hate it, I want to keep all my release branches identical"
21:16:41 <nirik> carlwgeorge: would anyone use it?
21:16:43 <tdawson> And yep, what pgreco said.  They don't like that their epel8 repo is different than their fedora repo.
21:16:51 <nirik> yeah, agreed on the package.cfg
21:17:13 <carlwgeorge> nirik: yes, i think so.  there are already packages in epel8 that don't install on c8s.
21:17:22 <pgreco> yeap, what michel_slm said
21:17:27 <nirik> that still seems really weird to me. :(
21:17:54 <michel_slm> carlwgeorge: if there's an epel-next that is automatically built so packagers don't have to care, that'd be great news for Facebook (who's converting their servers to c8s)
21:17:55 <nirik> I guess it's api vs abi compat
21:18:02 <carlwgeorge> it will mainly be a documentation/education thing, el8/c8 uses epel8, c8s (and rhel 8 betas) use epel8-next
21:18:37 <carlwgeorge> michel_slm: seeking automatic stuff is what complicated playground to be honest
21:18:45 <nirik> I don't think we have a way to automatically build stuff aside a package.cfg
21:18:45 <tdawson> other than smooge, and myself, I haven't heard any developers saying to drop playground.
21:19:01 <tdawson> And I just said to drop it because it was on the list of things we could do.
21:19:33 <michel_slm> carlwgeorge: true.
21:20:40 <carlwgeorge> michel_slm: i'm thinking more of epel8-next as a optional branch that maintainers can build for, that builds against stream, for situations when incompatibilities are found.  for example, c8s has a llvm soname bump, so everything in epel8 that links against that is uninstallable right now.
21:20:53 <tdawson> carlwgeorge: The problem with dealing with -next right now is manpower.   When Facebook provides some manpower to help ... they we can put it on a higher priority.
21:20:53 <nirik> in some kind of awesome world we would have CI that would see a epel8 package doesn't install on stream and rebuild it in next and test that.
21:21:01 <michel_slm> carlwgeorge: so the idea I want to discuss is related to this. Can we have something like 'epel-provenpackagers' who have blanket access to branch and build packages for EPEL and epel-next
21:21:26 <filbranden> hey folks! I'm new here, but michel_slm and I work together. I'm interested in helping out here. I'm particularly interested in building golang and rust packages in epel8.
21:21:47 <tdawson> filbranden: Hi, and welcome
21:21:49 <nirik> michel_slm: might be possible... provenpackages in fedora already can build epel stuff.
21:21:54 <michel_slm> I brought this up yesterday with mattdm, asking if it's possible to have a FAS group for contributors from a single company -- and Matt suggested just making it general and anyone can join it
21:21:54 <nirik> welcome filbranden
21:21:56 <carlwgeorge> michel_slm: i don't hate the idea, but is it work having a separate group for that or just use the regular provenpackagers?
21:22:01 <carlwgeorge> *worth
21:22:10 * carlwgeorge waves at filbranden
21:22:20 <michel_slm> nirik: as a provenpackager, I still can't branch a package until I'm added as a committer though
21:22:22 * filbranden waves back!
21:22:30 * michel_slm waves at filbranden - we were just discussing this yesterday
21:22:36 <nirik> yep
21:22:39 * pgreco waves at everybody :)
21:22:43 <nirik> thats intentional
21:23:13 <michel_slm> carlwgeorge: higher barrier to entry, but yeah that would suffice provided the branching problem is solved
21:23:20 <nirik> to prevent someone driving by, making a new branch and then foisting off maintainership on the existing maintainer(s)
21:23:33 * mattdm parachutes in
21:23:37 <nirik> if you are going to branch it, shouldn't you step up to maintain it?
21:23:39 <tdawson> The problem with provenpackages doing branches is what is called "drive by maintaining" ... someone will request branches for 100 packages, build them, then off they go, never touching them for years, or ever.
21:23:40 <carlwgeorge> we could add an epel-sig group.  i have branch request access for a ton of stuff from being in the python-sig and go-sig groups.
21:23:43 <mattdm> that seems like a good reason for something separate from proven packagers
21:24:12 <michel_slm> nirik: yup, and we want to. question is what's the best way of adding a group of interested people without adding them individually - so yeah, a new packager group
21:24:13 <nirik> I'm not sure how another group would help any...
21:24:26 <michel_slm> epel-sig sounds good
21:24:31 <carlwgeorge> then if a maintainer wants, they add the epel-sig group to state they are ok with new epel branches being created
21:24:49 <nirik> oh, you are talking about a pagure/src group that would be added as commiter/point of contact when branching?
21:24:49 <michel_slm> plus once it's added to a package once, group members have access to branch for the next EL release i n3 years' time
21:25:04 <carlwgeorge> nirik: exactly
21:25:31 <nirik> ah yeah, I see. that makes sense...  as long as the group gets bug reports and such
21:25:37 <pgreco> don't forget that this needs to work after the gl migration :)
21:25:37 <carlwgeorge> that way if a maintainer is against having epel branches, they just don't add the epel-sig
21:26:05 <michel_slm> only for packages where the Fedora maintainer doesn't care about EPEL or is not overly responsive - we made the mistake of not doing this earlier and so we're only noticing missing packages we need when the service using it starts migrating to c8s :)
21:26:09 <carlwgeorge> it works well enough for python-sig and go-sig, at least from what i can tell
21:26:14 <nirik> well... some folks could be fine with epel, but wanting to maintain themselves...
21:26:21 <michel_slm> carlwgeorge: ah, we want it the other way around though
21:26:38 <michel_slm> if the maintainer doesn't want to maintain in epel, then add epel-sig and the SIG will maintain that branch?
21:27:18 <michel_slm> (sorry for derailing from the playground-and-next discussion)
21:27:37 <carlwgeorge> sure, or getting an individual added as a primary epel branch maintainer, with epel-sig as a fallback
21:28:19 <michel_slm> I can write a proposal and send it to epel-devel
21:28:23 <tdawson> It's ok, I've written it doesn.
21:28:31 <tdawson> michel_slm: If you could do that, it would be great.
21:28:45 <nirik> yeah
21:29:21 * pgreco tries to reel in the conversation
21:29:30 <tdawson> About the epel8-playground proposal ... are people ok voting on it?
21:29:48 <tdawson> This is without stream and -next, which will be a completely seperate topic.
21:29:59 <nirik> so that would be what you outlined in the email?
21:30:29 <tdawson> nirik: Correct, the "5 step plan"  ... as much as I hate calling it that, but ...
21:30:47 <nirik> the first step it to admit you have a problem... or wait, thats something else. :)
21:30:53 <nirik> yes, I am +1 to that plan
21:31:32 <tdawson> I'm +1 for it too
21:32:04 * carlwgeorge speed reads the email thread
21:32:21 <michel_slm> +1 (assuming any epel maintainer can vote)
21:33:15 <pgreco> I'm +1 too
21:33:49 <carlwgeorge> so what we're voting on is making playground independent basically?
21:33:57 <pgreco> yeah
21:34:08 <michel_slm> independent but inheriting from epel, right?
21:34:19 <pgreco> right
21:34:19 <tdawson> carlwgeorge: independent builds, but inheriting from epel ... correct.
21:34:28 <michel_slm> which solves the issue I've had of playground not building because one of the dependencies doesn't have package.cfg
21:34:29 <tdawson> So that we don't have to have every package in there.
21:34:30 <carlwgeorge> yes, i mean independent like no automatic branching/builds
21:34:39 <tdawson> carlwgeorge: Correct
21:34:44 <michel_slm> so playground is sort of like a permanent override
21:34:51 <carlwgeorge> i'm +1 to that (or to just killing it off if that's easier)
21:35:07 <nirik> michel_slm: yep. if you have the repo enabled.
21:35:49 <michel_slm> if we approve epel-next on the next topic, I feel it will make playground's purpose clearer too which would help
21:36:22 <tdawson> #info 5 Step Proposal for epel8-playground passed +5 For 0 Against, 1 missing
21:37:15 <tdawson> That's one of the reasons I wanted it seperate from -next, so we could have a clearing idea of what is wanted .
21:38:33 <tdawson> carlwgeorge: Would you be willing to write up a semi-detailed proposal of what you are thinking of for epel-next
21:39:12 <carlwgeorge> sure.  and i like the idea of separating it from the playground discussion, thanks for that.
21:39:30 <tdawson> Ya, things were getting muddled.
21:39:56 <tdawson> It will also get up a clear idea of what work is involved, both for releng, as well as non-releng people.
21:40:52 <tdawson> carlwgeorge: Do you want to send it in an email, or have it as a discussion next week?  Or both?
21:41:56 <carlwgeorge> whatever you like, i'm easy
21:42:28 <nirik> email to list and vote next week sounds good.
21:42:41 <pgreco> if you can both, the email will make things for releng easier to see in advance
21:42:42 <tdawson> carlwgeorge: How about you send it as an email, so we can get more disucssion on it.  And if we have enough people next week, have a discussion then.
21:42:49 <tdawson> So, sounds like I'm saying "both"
21:42:53 <pgreco> there may be things we're now aware of
21:43:02 <carlwgeorge> roger roger
21:43:24 <tdawson> OK, moving on ... getting close on time.
21:43:30 <tdawson> #info EPEL-6 is End of Life in 2020-11. It will be moved to archives in 2020-12
21:43:31 <tdawson> #info THIS IS NOT A DRILL.
21:43:55 <michel_slm> \o/
21:44:13 <tdawson> nirik: I'm going to start sending out emails.  Is there anything else we need to do, or is it all releng?
21:44:29 <nirik> nothing off hand... should be pretty easy to EOL
21:44:51 <carlwgeorge> killitwithfire.jpg
21:44:55 <michel_slm> same procedure as when a Fedora release goes EOL?
21:46:11 <nirik> similar.
21:46:31 <tdawson> #topic EPEL-7
21:46:40 <tdawson> Do we have anything for EPEL7?
21:46:51 <tdawson> I didn't hear anything this week, but I might have missed some stuff.
21:47:16 <pgreco> the long time "testing" packages
21:47:29 <nirik> I had one and pushed it stable.
21:47:34 <nirik> I just forgot about it. :)
21:47:38 <tdawson> That's right.  pgreco, what did you find out?
21:47:40 <pgreco> pinged in the 3 conversations, but only nirik responded, right ;)
21:48:14 <pgreco> let's give it a few more days, I think I did it Wed or Thu, so not enough time
21:49:11 * nirik nods
21:49:57 <tdawson> Sounds good to me.
21:50:05 <tdawson> Anything else EPEL7 ?
21:50:29 <tdawson> #topic EPEL-8
21:51:10 <tdawson> Other than -playground and -next, the only things I've heard about is packages in EPEL7 but not EPEL8, even with open bugzillas.
21:51:42 <tdawson> I'm wondering if this EPEL-SIG will be what we want to deal with those.
21:52:21 <filbranden> So I wanted to ask about golang and rust in epel-8... Yesterday I spent some time looking at building go-rpm-macros... I guess it's something I can follow up on #epel later on to ask more questions about it.
21:53:01 <michel_slm> re: stale open bugzillas, it will be nice to have an option that doesn't require using the non-responsive maintainer process
21:53:05 <carlwgeorge> tdawson: i'm imagining so, with some kind of standard procedure like "if the maintainer doesn't respond after 2 weeks, epel-sig proceeds with requesting epel8 branch and building"
21:53:41 <carlwgeorge> filbranden: i believe work is under way for that, you should reach out to the go-sig, in particular nim, about that
21:53:51 <michel_slm> carlwgeorge: that sounds great. I wonder if it can be automated
21:53:58 <carlwgeorge> filbranden: #fedora-golang
21:54:28 <michel_slm> and #fedora-rust for rust
21:54:28 <tdawson> filbranden: I hadn't heard about rust problems ... other than there are a ton of rust library packages.
21:54:38 * filbranden thanks carlwgeorge !
21:54:53 <michel_slm> tdawson: one prob with Rust is the way it works in Fedora now, the dynamic dependency generator requires RPM 4.15 or 4.16 (I forgot which)
21:55:02 <carlwgeorge> in general rust and golang packaging is a nightmare unless you bundled the build requirements in your tarball
21:55:11 <michel_slm> Igor Raits would be a good person to ask
21:55:24 <tdawson> Oh ... well that causes a problem.
21:55:57 <carlwgeorge> igor being ignatenkobrain here on freenode
21:57:08 <tdawson> We're getting close to time.  michel_slm, you said you wanted to talk about something at Open Floor.
21:57:25 <michel_slm> tdawson: oh, it was epel-sig so it's been discussed :)
21:57:33 <tdawson> OK, cool.
21:57:43 <tdawson> #topic General Issues / Open Floor
21:57:50 <filbranden> I saw that rust-rpm-macros builds fine (I opened a bugzilla about releasing it), but didn't try to build packages with it yet... I went down the golang rabbit hole then and got lost there :-)
21:58:20 <tdawson> Any issues before we close?  (although we can continue to talk about rust and golang if we want)
21:58:50 <carlwgeorge> filbranden: it's a deep hole
21:58:56 <pgreco> not here
21:59:29 <tdawson> both golang, and rust, are very deep holes.
22:00:03 <tdawson> Thanks to everyone for coming.  I'm glad we were able to have a good discussion, and get things planned.
22:00:12 <tdawson> Talk to you all next week, or sooner.
22:00:18 <tdawson> #endmeeting