<@tdawson:fedora.im>
18:00:04
!startmeeting EPEL (2024-04-17)
<@meetbot:fedora.im>
18:00:05
Meeting started at 2024-04-17 18:00:04 UTC
<@meetbot:fedora.im>
18:00:05
The Meeting name is 'EPEL (2024-04-17)'
<@rcallicotte:fedora.im>
18:00:08
!hi
<@salimma:fedora.im>
18:00:08
!hi
<@zodbot:fedora.im>
18:00:09
Robby Callicotte (rcallicotte) - he / him / his
<@zodbot:fedora.im>
18:00:10
Michel Lind (salimma) - he / him / his
<@tdawson:fedora.im>
18:00:11
!meetingname epel
<@dherrera:fedora.im>
18:00:13
!hi
<@zodbot:fedora.im>
18:00:14
Diego Herrera (dherrera) - he / him / his
<@tdawson:fedora.im>
18:00:18
!topic aloha
<@rcallicotte:fedora.im>
18:00:22
woot woot!!
<@salimma:fedora.im>
18:00:23
wow everyone's so eager :)
<@nhanlon:beeper.com>
18:00:34
!hi
<@dherrera:fedora.im>
18:00:35
^^
<@zodbot:fedora.im>
18:00:35
Neil Hanlon (neil) - he / him / his
<@salimma:fedora.im>
18:00:35
do we count if we 'hi' before the aloha topic? we do right
<@nhanlon:beeper.com>
18:00:47
everyone receives a participation trophy
<@nirik:matrix.scrye.com>
18:00:51
morning
<@tdawson:fedora.im>
18:00:53
Hi Robby Callicotte Michel Lind 🎩 Diego Herrera and Neil Hanlon
<@tdawson:fedora.im>
18:01:08
Morning nirik
<@nhanlon:beeper.com>
18:01:22
it'd have been funnier if you didn't welcome them because they didn't wait until you said hi .... ;)
<@salimma:fedora.im>
18:01:31
I need to take a bio break, 1 min
<@nhanlon:beeper.com>
18:01:49
hey folks, happy third monday etc etc
<@salimma:fedora.im>
18:03:03
back
<@salimma:fedora.im>
18:03:17
third Monday?
<@salimma:fedora.im>
18:03:20
oooh
<@salimma:fedora.im>
18:03:24
third Monday of the week lol
<@tdawson:fedora.im>
18:03:46
I was thinking it was the third monday of the month .... then thought about it a bit.
<@nirik:matrix.scrye.com>
18:03:46
It's mondays all the way down.
<@rcallicotte:fedora.im>
18:04:06
mondays... turtles... ya know
<@salimma:fedora.im>
18:04:16
same
<@salimma:fedora.im>
18:04:43
Monday was cancelled this week because tax
<@salimma:fedora.im>
18:05:01
sorry for the US centric reference :P
<@tdawson:fedora.im>
18:05:19
!topic End Of Life (EOL)
<@tdawson:fedora.im>
18:05:23
RHEL 7 / epel-7 will go EOL on 2024-06-30
https://endoflife.date/rhel
CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
https://endoflife.date/centos-stream
<@tdawson:fedora.im>
18:05:34
Inching closer and closer.
<@salimma:fedora.im>
18:05:51
I'm looking forward to being able to just close all the python-django EPEL7 CVEs :D
<@tdawson:fedora.im>
18:06:19
A mass bugzilla closing .... 🎉
<@rcallicotte:fedora.im>
18:06:49
whoa! neochat went crazy for a sec
<@tdawson:fedora.im>
18:07:05
Oh, so that wasn't just the web browser doing that ... cool.
<@tdawson:fedora.im>
18:07:10
moving on.
<@salimma:fedora.im>
18:07:18
ah I was on my phone so did not see that
<@tdawson:fedora.im>
18:07:21
!topic EPEL Issues https://pagure.io/epel/issues
<@tdawson:fedora.im>
18:07:38
Let's start with the newer one.
<@tdawson:fedora.im>
18:07:51
https://pagure.io/epel/issue/271
<@salimma:fedora.im>
18:08:02
yay
<@salimma:fedora.im>
18:08:21
so this seems uncontroversial but nirik asked for some useful clarifications
<@salimma:fedora.im>
18:08:44
and I also have a question about where I should put the final form of this. Can I host it somewhere in the EPEL docs?
<@nirik:matrix.scrye.com>
18:09:10
yeah, I think fedora.im is.... having some slowdown issues or something.
<@nirik:matrix.scrye.com>
18:09:13
oh, you know thats a good point. Who will close all the epel7 bugs? ;)
<@salimma:fedora.im>
18:09:18
direct link to nirik's concern https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/J2NLAU6WIM32Z7JO7I5F72G6S7FVT3D2/
<@salimma:fedora.im>
18:09:30
hmm
<@rcallicotte:fedora.im>
18:09:59
it sounds like we do not have an automation for closing the bugs :(
<@salimma:fedora.im>
18:10:06
we do for Fedora right?
<@salimma:fedora.im>
18:10:08
can it be reused?
<@smooge:fedora.im>
18:10:17
isn't there a script for Fedora? and can it be ... oh what he said
<@nirik:matrix.scrye.com>
18:10:21
none I am aware of. Yes, there's fedora EOL stuff.
<@nirik:matrix.scrye.com>
18:10:33
but... some brave human needs to adapt it, and such
<@smooge:fedora.im>
18:10:51
this sounds like a job for an AI
<@tdawson:fedora.im>
18:11:18
Wha ... are you calling my Intelligance artificial?
<@nhanlon:beeper.com>
18:11:25
sudo make me a script
<@salimma:fedora.im>
18:11:40
we are all impostors
<@rcallicotte:fedora.im>
18:11:57
now THAT would be a great AI name "Sudo AI"
<@tdawson:fedora.im>
18:12:33
OK, getting back to the issue ....
<@davide:cavalca.name>
18:12:34
!hi
<@nirik:matrix.scrye.com>
18:12:39
https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/eol-day/
<@zodbot:fedora.im>
18:12:42
Davide Cavalca (dcavalca) - he / him / his
<@nirik:matrix.scrye.com>
18:12:46
(and there's a eol-warn a month before)
<@nhanlon:beeper.com>
18:13:02
and it's wasted on frog nfts. https://www.sudo.ai/
<@salimma:fedora.im>
18:14:33
(took Llama two tries, it misspelled sudo the first time. of course)
<@salimma:fedora.im>
18:15:10
in case someone wants to volunteer, is there any special access you need to be able to execute the fedora eol script?
<@tdawson:fedora.im>
18:15:14
Michel Lind 🎩: Just to be clear, it's likely that the LTS builds will overlapp for a period of time, correct? And the "swap" would only happen when the one goes EOL.
<@salimma:fedora.im>
18:15:28
like, is there a test mode where it just lists the issues it will close
<@salimma:fedora.im>
18:15:33
ok, back to Django
<@nirik:matrix.scrye.com>
18:15:56
I think you just need a bugzilla account, no special access... although we might want to run it as some automated user to prevent someone from getting emails about it later.
<@salimma:fedora.im>
18:15:58
yes, I will try to get the new LTS in as soon as its out (to Fedora first, then to EPEL since we sometimes have to deal with missing or older dependencies)
<@neil:fedora.im>
18:16:24
the latency on a different homeserver is unbearable right now.
<@salimma:fedora.im>
18:16:43
so I see three "incompatibility upgrade" waves we need to deal with separately
- the ones needed to get the new Django LTS in. this we can use the standard notice period assuming the old LTS is still supported
<@neil:fedora.im>
18:16:44
re: django -- that all makes sense I think
<@salimma:fedora.im>
18:17:03
- the ones needed to say upgrade mailman. again we can handle this with normal urgency
<@salimma:fedora.im>
18:17:39
- and... the incompatible upgrades we need when the old LTS goes end of life, and yet we have some Django dependents that do not support the new LTS yet. basically the cleanup
<@salimma:fedora.im>
18:18:20
(any incompatible upgrade outside of those three should probably be handled on a case by case basis, between the person who needs the new version and the maintainer of that specific Django dependent)
<@salimma:fedora.im>
18:18:47
yeah, I always join Fedora meetings from fedora.im just in case :P. been bitten by that too often
<@salimma:fedora.im>
18:18:55
even within two EMS hosted instances!
<@salimma:fedora.im>
18:19:05
even between two EMS hosted instances!
<@salimma:fedora.im>
18:20:18
for cleanup... not sure how to handle that. put up PRs to fix the packages affected? or just list them in the deprecation announcement and say "FYI"?
<@conan_kudo:matrix.org>
18:20:21
!hi
<@tdawson:fedora.im>
18:20:24
I know that we (EPEL) follows Fedora's Updates Exception list ... I remember us having a discussion about it. But I'm having a hard time finding where we say that.
<@zodbot:fedora.im>
18:20:26
Neal Gompa (ngompa) - he / him / his
<@tdawson:fedora.im>
18:20:37
Hi Conan Kudo
<@salimma:fedora.im>
18:20:53
I think nirik also suggested auditing what Django dependents work with the old Django LTS only and whichi work with the new one as well, and which works if they can be upgraded. that can be part of the announcement when the new LTS lands
<@salimma:fedora.im>
18:21:23
I think we discussed that at a previous meeting, and the conclusion is we follow Fedora's processes unless we state otherwise
<@nirik:matrix.scrye.com>
18:21:33
yeah, and as far as 3rd party stuff... if we make enough announcements/notice hopefully it will be ok.
<@salimma:fedora.im>
18:21:42
in this case these are brand new packages so we don't need to do updates exception ... only for the dependencies and dependents
<@salimma:fedora.im>
18:22:09
e.g. asgiref needs to be updated to support django 4.2, and we already have an incompatible upgrade policy to handle that
<@salimma:fedora.im>
18:23:04
do we have anything else we should consider? if not, I guess my next question is where can I put the policy document for this
<@tdawson:fedora.im>
18:23:28
Ya, that's what I was looking for ... the place we said we'd put our policies.
<@salimma:fedora.im>
18:23:32
can I put it as a subpage of this? https://docs.fedoraproject.org/en-US/epel/epel-policy-updates/
<@salimma:fedora.im>
18:23:59
btw when finding that yesterday I noticed the "stable releases" policy seems inconsistent with what people actually do in practice (and is not enforced)
<@tdawson:fedora.im>
18:24:01
That is my first choice, yes.
<@salimma:fedora.im>
18:24:13
the "must have at least 1 week or +3"
<@salimma:fedora.im>
18:24:59
and then the parent page https://docs.fedoraproject.org/en-US/epel/epel-policy/ has long paragraphs also talking about upgrade policy that is different - it's stricter still. e.g. wait two weeks even going from 1.0.1 to 1.0.2
<@nirik:matrix.scrye.com>
18:25:25
we changed the default stable from 2 weeks to 1... perhaps that wasn't adjusted.
<@salimma:fedora.im>
18:25:27
and 1.0.1 to 1.2.0 - it basically says "wait until sufficient karma" but does not say anything about the wait period :P
<@salimma:fedora.im>
18:25:53
in this case, do we want to be stricter than Fedora? if not we might be able to just remove a lot of these
<@conan_kudo:matrix.org>
18:26:31
In general, I don't think we need to be stricter than Fedora
<@salimma:fedora.im>
18:26:31
(I can see an argument for being more careful than with Fedora updates - I think Carl normally makes that)
<@salimma:fedora.im>
18:27:05
but yeah. we already have a specific policy to slow down incompatible upgrades, so idk if we want to deal with the overhead of implementing additional policies?
<@tdawson:fedora.im>
18:27:59
I disagree. I feel strongly that we should have a stricter update policy than Fedora.
<@salimma:fedora.im>
18:28:06
I'll prep a PR for adding this document, and post it to the list and chat after this so we can nitpick it there
<@salimma:fedora.im>
18:28:25
that could be fine too, but in that case we should decide what that is, *and* get Bodhi to enforce it
<@salimma:fedora.im>
18:28:58
right now you can adjust it down to +1
<@conan_kudo:matrix.org>
18:29:09
Troy Dawson: Only if people are being paid to maintain that strictness for updates.
<@conan_kudo:matrix.org>
18:29:27
I do not think it is reasonable to do that for a largely community run volunteer contributed project.
<@tdawson:fedora.im>
18:29:40
Ya ... and now that I read it, I realize that I often put mine down to +1 ... so ... I'm being a hypocryte here. :(
<@conan_kudo:matrix.org>
18:30:05
Not to mention, with how much RHEL shrinks and churns now, this would just make our lives unnecessarily hard.
<@salimma:fedora.im>
18:30:24
I wonder if we can tabulate the trend of how many reviews happen per package over time. I suspect EPEL packages get less karma than Fedora packages, and even for Fedora unless it's a popular package, nada
<@tdawson:fedora.im>
18:30:41
But, I totally agree with this statement on our policy guidelines `no "hey, there is a new version, it builds, let’s ship it" mentality.`
<@salimma:fedora.im>
18:30:48
which reminds me. what would really help is getting the same CI we have in Fedora for EPEL
<@nirik:matrix.scrye.com>
18:30:57
I don't think I heard any feedback when we changed it from 2 weeks to 1 week... no complaints that things were too fast or anything
<@salimma:fedora.im>
18:31:05
Carl told me there are internal issues filed but they are... stuck in prioritization
<@salimma:fedora.im>
18:31:27
yes, same
<@nirik:matrix.scrye.com>
18:31:43
but yes, people shouldn't toss updates just because they exist. They should fix something that users actually would encounter.
<@salimma:fedora.im>
18:31:46
so the tricky thing is in theory Fedora has the same 'stable update' policy. you shouldn't just upgrade "just because shiny"
<@salimma:fedora.im>
18:31:53
in practice Fedora does not enforce that... at all
<@nirik:matrix.scrye.com>
18:32:08
(except in rawhide, update there as long as it's usable)
<@salimma:fedora.im>
18:32:27
yeah. or in some ecosystems like Rust
<@smooge:fedora.im>
18:32:28
... looks at his standard update policy because his packages tend to be 'its shiny so users ask for it'
<@tdawson:fedora.im>
18:32:39
I'm trying to think how many times people have asked me to update a package to "The newest thing" and often what they want hasn't even been released by the upstream maintainers.
<@nirik:matrix.scrye.com>
18:32:39
it would be pretty difficult to enforce.
<@salimma:fedora.im>
18:32:44
fwiw Rust packagers don't upgrade willy nilly either, normally only when you want a newer version of a leaf package :)
<@salimma:fedora.im>
18:32:53
yikes
<@salimma:fedora.im>
18:33:02
well now you can point to xz and say "ni!"
<@tdawson:fedora.im>
18:33:45
Yes ... exactly ... I'm looking back on those and going "wow ... now I wonder what would have happened if I'd done that."
<@salimma:fedora.im>
18:33:50
quick question while we bikeshed this / commiserate with each others about upgrade firehoses
<@conan_kudo:matrix.org>
18:34:07
In practice, the EPEL incompatible update policy gets followed like the Fedora incompatible update policy
<@conan_kudo:matrix.org>
18:34:26
whereas the Fedora incompatible update policy rarely gets followed for Fedora updates in stable releases :/
<@salimma:fedora.im>
18:34:28
so the incompatible upgrade for asgiref (not sure if it's incompatible, actually, just *potentially* so) - that got announced 04/11. should I wait one extra day or do people see no issue with starting today to unblock Django?
<@nirik:matrix.scrye.com>
18:34:32
I know! we'll get AI to find all the incompatible upgrades!
<@conan_kudo:matrix.org>
18:34:50
🪦
<@nirik:matrix.scrye.com>
18:35:17
Anyhow, please everyone follow the policies and leed by example. ;)
<@salimma:fedora.im>
18:35:18
the two dependents seem to build and pass their test suites just fine. happy to just wait an extra day too if we want to be careful, though I'm off on Friday so that might delay things a bit :)
<@salimma:fedora.im>
18:35:28
I guess I can save time by doing the django 4.2 release together with it, in a side tag
<@salimma:fedora.im>
18:35:37
I guess that's the answer :)
<@salimma:fedora.im>
18:36:02
sigh. we can't even get CI, forget about AI
<@neil:fedora.im>
18:36:22
ai must come first, no?
<@neil:fedora.im>
18:36:27
ai, bi, ci,,,
<@nirik:matrix.scrye.com>
18:37:05
!fire Neil Hanlon
<@salimma:fedora.im>
18:37:23
seriously... how did we forget to port .fire
<@salimma:fedora.im>
18:37:35
when we do should it say Adam or should it say someone else
<@tdawson:fedora.im>
18:37:50
I want to +1 to what nirik said. Let's lead by example. Wait the extra time.
<@smooge:fedora.im>
18:37:57
It should say the person fires themselves
<@smooge:fedora.im>
18:38:31
anyway I agree with nirik on this.
<@salimma:fedora.im>
18:38:45
do we want to discuss our update karma criteria? or we agree following the Fedora one is sufficient
<@salimma:fedora.im>
18:38:58
or punt until later, we can also create an issue and discuss it there and move on for now
<@nirik:matrix.scrye.com>
18:39:12
we did discuss it back when we moved it from 2 weeks to 1 week... we can again...
<@smooge:fedora.im>
18:39:38
what is the fedora one?
<@salimma:fedora.im>
18:39:39
I'm ok letting it follow Fedora, just asking since I happened to find the inconsistent docs :)
<@salimma:fedora.im>
18:39:54
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
<@salimma:fedora.im>
18:40:12
"The maintainer is free to set the thresholds, but they cannot be lower than the minimum values described below, enforced by Bodhi"
<@salimma:fedora.im>
18:40:40
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#non-critpath-updates
<@salimma:fedora.im>
18:40:48
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#critpath-updates
<@nirik:matrix.scrye.com>
18:40:59
epel has nothing like critical path
<@salimma:fedora.im>
18:41:01
so EPEL is already covered there - they are considered equivalent to critical path
<@salimma:fedora.im>
18:41:04
interesting
<@nirik:matrix.scrye.com>
18:41:14
at least not that I am aware of
<@salimma:fedora.im>
18:41:17
"Critical path and EPEL update thresholds"
<@tdawson:fedora.im>
18:41:25
Even though I said stricter than Fedora's, I also see a need occasionally to do lower than 3.
<@nirik:matrix.scrye.com>
18:41:42
there may be some epel special casing. I dont know.
<@salimma:fedora.im>
18:41:45
except since we don't actually have freezes, in practice we are always "min +1, default +3" huh
<@nirik:matrix.scrye.com>
18:41:57
adamw was reworking all this stuff in a pr...
<@nirik:matrix.scrye.com>
18:42:21
(well, so that bodhi actuall did what the policy said)
<@salimma:fedora.im>
18:42:23
and this still says 14 days which is wrong for us
<@tdawson:fedora.im>
18:42:46
No, that's for Beta Freeze, it actually says 3 days.
<@salimma:fedora.im>
18:42:50
or... is it actually 14 mins for epel? I normally beg for karma so I forget
<@nirik:matrix.scrye.com>
18:42:57
so, I would say make a ticket on this and we can discuss. we shouldn't just shotgun something in meeting
<@salimma:fedora.im>
18:43:06
well, after beta freeze it says 14. since we never freeze we should always be at 14
<@salimma:fedora.im>
18:43:19
yeah.. I think it's worth discussing further since we find inconsistencies in all the docs
<@tdawson:fedora.im>
18:43:42
Ya ... let's file an issue. I think we need something written down and discussed.
<@nirik:matrix.scrye.com>
18:43:44
fedora_epel.mandatory_days_in_testing = 7
<@nirik:matrix.scrye.com>
18:43:49
(thats in bodhi config)
<@tdawson:fedora.im>
18:44:10
And ... we're already going over time.
<@salimma:fedora.im>
18:44:27
!issue 272
<@salimma:fedora.im>
18:44:34
!link https://pagure.io/epel/issue/272
<@tdawson:fedora.im>
18:44:59
Thank you.
<@salimma:fedora.im>
18:45:20
I added nirik's comment too so I think that covers all the different 'claims'
<@tdawson:fedora.im>
18:45:48
So, issue #271 ... passed, correct? But without a cut in time?
<@tdawson:fedora.im>
18:46:34
We never had a vote on that, just moved on like it passed.
<@salimma:fedora.im>
18:46:51
I guess we should vote :)
<@salimma:fedora.im>
18:47:02
!help
<@zodbot:fedora.im>
18:47:02
● `!help [commandname]` - list commands
● `!version ` - return information about this bot
● `!pagureissue <project> <issue_id>` - return a pagure issue
● `!whoowns <package>` - Retrieve the owner of a given package
● `!group <subcommand> [...]` - Query information about Fedora Accounts groups
● `!user <subcommand> [...]` - Get information about Fedora Accounts users
● `!infra <subcommand> [...]` - Fedora Infrastructure commands
● `!bug <bug_id>` - return a bugzilla bug
● `!cookie <subcommand> [...]` - Commands for the cookie system
<@salimma:fedora.im>
18:47:23
wait where are the commands for issue, action etc
<@salimma:fedora.im>
18:47:24
!halp
<@salimma:fedora.im>
18:47:57
ah here
<@salimma:fedora.im>
18:48:41
proposal: approve the Django LTS plan with an added section we discuss to specify how to handle the different classes of incompatible upgrades needed
<@tdawson:fedora.im>
18:49:19
Um ... no
<@salimma:fedora.im>
18:49:22
and that we announce the result of a compatibility audit of packaged Django dependents when announcing a new LTS and when deprecating one
<@tdawson:fedora.im>
18:49:32
How about we just approve the Django LTS plan.
<@salimma:fedora.im>
18:49:36
ah ok
<@salimma:fedora.im>
18:49:37
sure
<@salimma:fedora.im>
18:49:45
I guess those are just details :)]
<@salimma:fedora.im>
18:50:34
I guess I'm +1 to my own plan
<@tdawson:fedora.im>
18:51:03
I'm +1 for the Django LTS plan.
<@nirik:matrix.scrye.com>
18:51:07
+1
<@rcallicotte:fedora.im>
18:51:20
+1
<@dherrera:fedora.im>
18:51:26
+1 :)
<@tdawson:fedora.im>
18:52:18
The only one missing that is here is Conan Kudo
<@conan_kudo:matrix.org>
18:52:32
+1
<@tdawson:fedora.im>
18:52:40
Thanks
<@tdawson:fedora.im>
18:53:32
!agreed The Django LTS plan has been approved. +6 positive, 0 negative ... The different classes discussion has been moved to a different issue.
<@salimma:fedora.im>
18:53:35
thanks for the feedback everyone
<@tdawson:fedora.im>
18:54:13
We're running really short of time. I'm going to open it up to Open Floor if anyone has anything.
<@salimma:fedora.im>
18:54:14
oh ... sorry, I meant the different batches of updates we need to make that are Django related, not the different classes of updates in the policy :)
<@salimma:fedora.im>
18:54:22
that one is definitely a separate issue
<@tdawson:fedora.im>
18:54:26
!topic General Issues / Open Floor
<@tdawson:fedora.im>
18:54:49
Ahh ... ok. I was wondering why you were attaching those two together for the vote.
<@salimma:fedora.im>
18:55:12
my bad :)
<@salimma:fedora.im>
18:55:16
anyone for open floor?
<@rcallicotte:fedora.im>
18:55:47
I have a question related to pagure in epel9
<@tdawson:fedora.im>
18:55:53
Sure
<@rcallicotte:fedora.im>
18:57:05
Michel Lind 🎩 has suggested that the package be placed into infra-sig and or epel-sig. Would that mean that a non epel-sig member could still participate in the building of said package and its deps?
<@salimma:fedora.im>
18:57:48
sure. I just meant maybe we should add infra-sig / epel-packagers-sig to it
<@smooge:fedora.im>
18:58:00
thanks Troy Dawson need to go
<@tdawson:fedora.im>
18:58:05
It usually comes down to permissions.
<@nirik:matrix.scrye.com>
18:58:11
well, sure... but anyone can help anyhow right? with pr's, etc...
<@tdawson:fedora.im>
18:58:14
Stephen J Smoogen: See ya. Thanks for your input.
<@salimma:fedora.im>
18:58:19
we went through something like this for mailman, ended up adding infra sig to a lot of the dependents that used to have one-person maintainers
<@salimma:fedora.im>
18:58:29
(not by force, mind you)
<@rcallicotte:fedora.im>
18:58:39
Ah I understand
<@nirik:matrix.scrye.com>
18:58:49
yeah, having more people is good...
<@nirik:matrix.scrye.com>
18:59:22
and epel9 pagure would be most welcome. ;)
<@salimma:fedora.im>
18:59:48
which RHEL is it running on right now?
<@tdawson:fedora.im>
18:59:50
If there is a package, any package, that you personally want to help on, ask that package maintainer if you can help. Some might not want help, but most welcome it.
<@nirik:matrix.scrye.com>
18:59:51
8
<@salimma:fedora.im>
18:59:57
ah phew
<@tdawson:fedora.im>
19:00:35
After xz, you might not get as many people saying yes, unless they know you, but it doesn't hurt to ask.
<@rcallicotte:fedora.im>
19:01:06
ok. thanks :)
<@tdawson:fedora.im>
19:01:24
And with that, I think we are out of time.
<@salimma:fedora.im>
19:01:44
thanks for chairing Troy Dawson !
<@tdawson:fedora.im>
19:01:44
Thank you all for the good discussions. And I'll talk to ya'll next week, if not sooner.
<@tdawson:fedora.im>
19:02:01
!endmeeting