17:07:34 #startmeeting ELN (2021-03-12) 17:07:34 Meeting started Fri Mar 12 17:07:34 2021 UTC. 17:07:34 This meeting is logged and archived in a public location. 17:07:34 The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:07:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:07:34 The meeting name has been set to 'eln_(2021-03-12)' 17:07:34 #meetingname eln 17:07:35 #chair sgallagh 17:07:35 #info Welcome to the inaugural meeting of the ELN Special Interest Group! 17:07:35 The meeting name has been set to 'eln' 17:07:35 Current chairs: sgallagh 17:07:35 #topic Init Process 17:07:44 .hello2 17:07:45 jforbes: jforbes 'Justin M. Forbes' 17:07:46 .hello2 17:07:47 cyberpear: cyberpear 'James Cassell' 17:07:48 .hello2 17:07:49 .hello salimma 17:07:50 sgallagh: sgallagh 'Stephen Gallagher' 17:07:51 .hello2 17:07:53 michel_slm: salimma 'Michel Alexandre Salim' 17:07:55 .hello ngompa 17:07:56 dcavalca: dcavalca 'Davide Cavalca' 17:07:58 .hello2 17:07:59 Eighth_Doctor: ngompa 'Neal Gompa' 17:08:02 bookwar: bookwar 'Aleksandra Fedorova' 17:08:31 #chair jforbes cyberpear michel_slm dcavalca Eighth_Doctor bookwar 17:08:31 Current chairs: Eighth_Doctor bookwar cyberpear dcavalca jforbes michel_slm sgallagh 17:08:56 #topic Populate the initial SIG membership 17:09:09 My original plan was that we'd welcome anyone who turned up for this meeting as an initial member of the SIG. Then we can work out rules on how to expand or contract the membership later. 17:09:24 (Okay, I think we've replayed the relevant bits for the bot now) 17:09:31 sgallagh: we have also request from tstellard to count him in, even though he can not be here in person today 17:09:52 #info tstellard is also a member of the SIG, though he cannot be in attendance today 17:10:31 #topic Agenda 17:10:40 Topics for today's meeting include: 17:10:52 #info Agenda Item: Membership Rules 17:11:04 #info Agenda Item: Future Meeting Plans 17:11:22 #info Agenda Item: Identify a Documentation Czar 17:11:41 #info Agenda Item: Relationship of ELN and EPEL 17:11:51 Any other topics that people would like to add? 17:12:18 I'd like to also talk about how to consume and mirror ELN composes if there's time 17:12:32 maybe review of important locations? docs, tracker, code..? not sure if this is a discussion item though 17:12:35 #info Agenda Item: ELN mirroring and distribution 17:12:51 bookwar: I think we can bundle that into the documentation topic. 17:12:58 ok 17:13:04 If nothing else, we should have our landing page cover that 17:13:20 OK, let' 17:13:23 s get started 17:13:31 #topic Membership Rules 17:14:23 I proposed a simple, inclusive mechanism for joining the ELN SIG on the mailing list. I'll repeat it here for the record. 17:14:57 #info Proposal: Anyone may join the SIG by asking to become a member. If 17:14:57 no existing SIG member *opposes* that request within a week, they're 17:14:58 in. If an existing SIG member opposes, we hold a regular vote at the 17:14:58 next scheduled meeting as described above. 17:15:05 #undo 17:15:05 Removing item from minutes: INFO by sgallagh at 17:14:57 : Proposal: Anyone may join the SIG by asking to become a member. If 17:15:08 +1 17:15:12 welp 17:15:14 #info Proposal: Anyone may join the SIG by asking to become a member. If no existing SIG member *opposes* that request within a week, they're in. If an existing SIG member opposes, we hold a regular vote at the next scheduled meeting as described above. 17:15:27 sgallagh: +1 17:15:27 +1 17:15:29 +1 17:15:32 sgallagh: there was a comment from Matthew about adding the time limit 17:15:32 (My email's newlines were getting in the way) 17:15:53 bookwar: Indeed there was. 17:15:59 Let's consider that separately. 17:16:00 "I strongly recommend at minimum a requirement for anyone who has not been active by some measure to reaffirm interest annually." 17:16:02 ok 17:16:13 then +1 on the initial proposal 17:16:26 +1 17:17:25 cyberpear: Want to vote? 17:17:46 +1 17:17:51 #agreed Anyone may join the SIG by asking to become a member. If no existing SIG member *opposes* that request within a week, they're in. If an existing SIG member opposes, we hold a regular vote at the next scheduled meeting as described above. (+7, 0, -0) 17:18:16 #info The first vote of the ELN SIG involved unanimous consent. This is a good beginning! 17:18:27 \o/ 17:18:27 🙂 17:18:43 good start indeed ) 17:18:54 OK, Matthew's point is a good one: in order to avoid the membership list getting too stale, we ought to have some measure of actively reaffirming membership. 17:19:32 what would that actually be though? 17:19:41 because generally to me, ELN work is just fixing Rawhide stuff 17:20:02 e.g. I did a lot of fixing to PipeWire for both Fedora Rawhide and ELN at once 17:20:33 My suggestion is that we just pick a span (maybe January each year) for people to send an email saying they'd like to continue on the SIG. 17:20:35 I wouldn't add any specific metric for the activity, maybe just showing up at the meeting saying hi at least once in half a year? 17:20:43 I'd say showing up to one of these meetings is probably enough affirmation 17:21:00 Anyone who doesn't do so is assumed inactive and can always rejoin later, given our extremely low-effort joining rules. 17:21:14 I'd probably be good with the meeting thing as a bar for that 17:21:15 That seems more than fair 17:21:23 provided that we actually keep having meetings 17:21:31 That's literally the next agenda item :) 17:21:45 I don't remember... do we have a separate mailing list or just devel@? 17:22:07 cyberpear: Until and unless it becomes too noisy for devel@, I'd prefer to keep it there. 17:22:15 +1 17:22:16 Especially since we're building from Rawhide 17:22:20 +1 17:23:05 +1 17:23:21 +1 17:23:33 OK, does anyone want to formalize the keepalive process, or should we just agree to wing it? 17:23:44 let's just wing it 17:24:13 the ELN SIG is a little weird compared to the rest of them in that there aren't really discrete activities we'd be doing 17:24:23 OK, we'll figure out how to keep it up to date as we go 17:25:01 Eighth_Doctor: I don't think that's entirely true. (Alternately: if that becomes true, this SIG is meaningless) 17:25:23 sgallagh: I guess the better statement here is that I'm not exposed to anything that makes me think otherwise 17:25:44 Eighth_Doctor: As a member of the SIG, you are now in a position to influence that :-) 17:25:52 😆 17:25:55 But let's not side-track the agenda yet. 17:26:00 sure 17:26:03 #topic Future Meeting Plans 17:26:44 First point: I think ELN absolutely needs to have regular meetings, but I'm uncertain about the frequency. 17:27:15 I think less-frequent than monthly is prone to losing communication, but I also don't think we'll have enough topics to justify a weekly meeting. 17:27:22 So I'm open to suggestions here! 17:27:36 I'd rather err on more frequent meetings that we can cancel ahead if there's no agenda 17:27:40 bi-weekly? I think we should check on the state of things (the ELN compose and so on) regularly, and meeting is usually a good trigger for that 17:27:42 the minimum is monthly, right? 17:27:43 maybe biweekly is a good tradeoff? 17:27:45 I would likely think monthly is good, if we end up with more topics, we could do every 2 weeks or so? 17:27:49 yeah, biweekly sounds fine 17:28:12 every two weeks sounds fine to me 17:29:05 Sounds like biweekly is generally preferred (and I was thinking about the same), so: 17:29:20 Is the current time slot acceptable or should I run another WhenIsGood? 17:29:36 I would add the "current state of ELN compose" item to agenda as a default topic. And then anything else can be put on top of that 17:29:45 the current slot works for me 17:29:47 (Also: DST gets tricky this time of year) 17:29:51 This is acceptable for me. 17:29:55 bookwar++ 17:29:56 sgallagh: Karma for bookwar changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:30:07 Friday evening is not the best time for me, but other slots are even worse, so we can keep it :) 17:30:29 the current slot (post-DST) works for me 17:30:42 that is, 12pm EDT 17:31:21 Proposal: ELN SIG Meeting will be held biweekly on Fridays at noon Eastern Time 17:31:26 +1 17:31:27 +1 17:31:30 +1 17:31:35 (Following EST/EDT changes unless we vote otherwise in the future) 17:31:42 +1 17:31:50 +1 17:31:53 +1 17:31:56 #info Proposal: ELN SIG Meeting will be held biweekly on Fridays at noon Eastern Time 17:32:10 #agreed ELN SIG Meeting will be held biweekly on Fridays at noon Eastern Time (+7, 0, -0) 17:32:22 (Woohoo, *two* unanimous votes in a row!) 17:32:53 another question - how do we maintain agenda? 17:33:03 Good point 17:33:17 Probably a good time to move into organizational topics 17:33:21 Workstation uses tagged Pagure issues 17:33:31 #topic Landing Page, Documentation and Ownership Thereof 17:33:48 KDE SIG also uses Pagure for this 17:33:52 it works very well for us 17:33:57 (are we booking an hour or 30 min?) 17:34:03 as does Server WG and Cloud SIG 17:34:14 cyberpear: it's generally hour long booking 17:34:22 #link https://docs.fedoraproject.org/en-US/eln/ 17:34:25 cyberpear: an hour, but good to make that explict. 17:34:32 #info Meetings are scheduled for one hour 17:35:06 Currently we don't have a `fedora-eln` group established on Pagure, but we do have one on github 17:35:11 https://github.com/fedora-eln/ 17:35:35 https://github.com/fedora-eln/eln is specifically the issue tracker. I propose using tags there to establish the agenda. 17:36:01 Though if everyone would prefer to move to Pagure, it's not a hill I am willing to die on. 17:36:06 we have initially setup repos on github, because we wanted to be able to move issues between projects, for example like fedora-ci or minimization which are also hosted on github 17:36:14 not exactly a fan of using GitHub, but if everyone else wants to... 17:36:25 well, only people who are member of all those orgs can do moves 17:36:28 nobody else can do that 17:36:39 I think it's fine to keep it where it is. I say "Pagure" to mean "issue tracker" 17:36:50 likewise, I would prefer Pagure, but if the consensus is github I'll go with it 17:36:52 * Eighth_Doctor shrugs 17:36:55 Eighth_Doctor: I think you can always give it away 17:37:01 sgallagh: nope 17:37:06 * sgallagh shrugs 17:37:10 I agree with michel_slm that the important thing is having an issue tracker in the first place 17:37:11 tried that when the feature first launched 17:37:12 Eighth_Doctor: we have friends :) 17:37:48 I prefer pagure, but I'm not going to hold a sword over everyone for it 17:38:20 i think we have consensus on using issue tracker and labels 17:38:25 #info Proposal: ELN SIG will continue to use https://github.com/fedora-eln/eln for issue tracking and agenda tagging. 17:38:43 +1 17:38:47 that does mean we need to collect github IDs to add to ELN org 17:38:49 +1 17:38:56 +1 17:39:00 +1 sigh 17:39:07 Conan Kudo: yeah, was about to ask how we track that 17:39:15 +1, conditional to adding everybody into the github org 17:39:31 +1, but make sure all members are added to the org 17:39:43 my +1 is conditional on that too 17:39:45 naturally :) 17:40:38 For clarity: 17:40:38 #info Proposal: ELN SIG will continue to use https://github.com/fedora-eln/eln for issue tracking and agenda tagging. SIG members will be added to the Github organization. 17:40:47 (I think I requested to be added to the FAS group way back when, but don't know if it went anywhere) 17:40:53 qq: with Pagure, there's also no sync between project membership and group ACLs, right? 17:41:12 cyberpear: The FAS group has not, to my knowledge, had any purpose to date. 17:41:23 Michel Alexandre Salim: to date, no, but it's being worked on 17:41:45 ah. it'd be a good time to revisit the issue tracker when that's possible 17:41:55 #agreed ELN SIG will continue to use https://github.com/fedora-eln/eln for issue tracking and agenda tagging. SIG members will be added to the Github organization. (+7, 0, -0) 17:42:10 sgallagh, sig emails is about all 17:42:28 Michel Alexandre Salim: we'll see after the move to the new accounts system 17:43:09 Moving on to the landing page: 17:43:35 #info Proposal: The ELN SIG landing page will continue to be at https://docs.fedoraproject.org/en-US/eln/. 17:44:06 +1 17:44:07 +1 17:44:17 we should have eln.fp.o redirect to it 17:44:21 +1 17:44:25 to clarify the sources are under the same org on github https://github.com/fedora-eln/eln-docs 17:44:30 +1 from me 17:44:38 thanks bookwar, I was about to ask :) 17:44:47 +1 17:45:28 +1 17:45:37 Eighth_Doctor: that's a good point. Also we don't have those ELN docs exposed on the docs.fp.org front page either 17:45:48 #agreed The ELN SIG landing page will continue to be at https://docs.fedoraproject.org/en-US/eln/ (+7, 0, -0) 17:45:48 #info The sources to that page are located at https://github.com/fedora-eln/eln-docs 17:46:32 Clearly there are some shortcomings with how our docs are organized and accessed today. 17:47:23 Would anyone (who is not me) like to volunteer to act as our first Documentation Czar, taking ownership of doc organization and trimming stale information? 17:47:23 bookwar: indeed 17:48:55 sgallagh: i can review the current content, but i don't think we have that much of a stale data. We have some missing data maybe, like describe the current automation, and maybe tips for common issues. 17:49:02 If no one volunteers, I will nominate someone and the rest of us will vote on whether to voluntell you :) 17:49:25 bookwar: I think we should ALL help to clean up the initial state, but I'm looking for someone to own it long-term. 17:50:51 is it auto-published when a GitHub PR is merged? 17:50:53 I am not sure i understand what do you mean by ownership here, but you can sign me in for merging incoming pull requests :) 17:51:30 cyberpear: fedora docs site is regenerated by a cron job, and the eln sire is part of it 17:51:49 so it is not triggered on PR but it is updated in about hour or two 17:51:50 perfect! so upon-merge, but with delay until next cron run 17:53:30 bookwar: Someone taking responsibility for ensuring we don't have incorrect or outdated information in place. 17:55:23 I see incorrect information as a bug. So if someone finds it, they file a ticket, and then someone needs to act on it. 17:55:25 OK, we're running out of time for the meeting, so let's move along. 17:55:51 We can do a regular review, but then i'd rather see it as a quarterly cleanup event, not a personal thing 17:55:55 #topic Relationship between ELN and EPEL 17:56:18 There was a *lot* of chatter about this on the devel@ mailing list 17:56:54 my original idea on this was that it would be nice to be have matching EPEL composes with ELN 17:56:58 My personal stance is that, while both are Fedora projects related to Enterprise Linux, that's pretty much where the similarities end. 17:57:16 both to make it easier to test ELN in the real world, and potentially as a way to "seed" the next EPEL 17:57:26 * sgallagh nods 17:57:39 well, EPEL isn't terribly useful in an ELN context 17:57:43 we have all of Rawhide still built 17:58:04 I'd like to see an ELN-extras built that includes the set of packages in the most recent EPEL or EPEL-Next 17:58:13 ah, we rebuild all of Rawhide, not just the packages that will end up in the next EL? that changes things 17:58:22 Eighth_Doctor: Well, ELN builds in a different configuration and with different flags. 17:58:24 but maybe have that set of composed into its own repo? 17:58:31 oh, I thought we rebuilt a subset of rawhide, not all of it 17:58:40 * cyberpear also thought it was a subset 17:58:40 if we already do all of rawhide, that changes things 17:58:41 We only build a subset 17:58:49 we don't do all of Rawhide today 17:58:57 Eighth_Doctor: the good example is freeipa, which is ipa in ELN even though it uses the same sources from Rawhide 17:59:00 However, ELN *can* still use Rawhide as an extra repo 17:59:12 I think that's what Eighth_Doctor meant, but I'm not certain 17:59:12 in that case, if EPEL maintainers can opt into getting built against EL that will be nice 17:59:19 sgallagh: yes 17:59:26 yeah, I think an opt in mechanics would be the best here 17:59:36 Rawhide is already a working overlay on ELN 18:00:04 Eighth_Doctor: the problem with using Rawhide is that it's going to be built with different macros, so it's not necessarily representative 18:00:11 I dunno how much of an issue it'd be in practice though 18:00:18 There are some very small corner cases, where mixing ELN and Fedora can be hazardous, but I think even those are temporary 18:00:21 in my experience, not very much 18:00:25 Incorporating an EPELN (SWIDT?) is something we could explore, though it will need discussion with releng/infra 18:00:30 s/Fedra/Rawhide 18:00:31 For me the question here is the "early EPEL" a thing? So is anyone interested in building EPEL 10 packages now? 18:00:40 not a chance in hell 18:00:42 SWIDT? 18:00:50 software identifier tag 18:00:55 ah 18:01:01 (See What I Did There?) 18:01:06 that too :P 18:01:16 if we get to a point where ELN is installable, having EPELN might be useful 18:01:25 michel_slm: Is ELN not installable today? 18:01:27 I mentioned this on list, but for the record: my usecase here is taking an ELN compose and deploying it alongside CentOS Stream, as a way to do ongoing validation of what the *next* CentOS Stream will be 18:01:51 sgallagh: I haven't tried, happy to hear it is 18:02:13 my use-case is similar to dcavalca's, but also oriented around driving the next RHEL/CentOS Stream to have improvements and potential candidates for backporting into current EL/CS 18:02:15 michel_slm: Well, it's possible it isn't installable this very second, but it HAS been installable (and I've installed it in a VM) in the past. 18:02:15 dcavalca: the issue here is that ELN is already a 10, but the next CentOS Stream is still 9. So are you interested in 10 or 9 at this point? 18:02:20 michel_slm: planning to try that once the next agenda item is sorted out :) 18:02:29 bookwar: 10 18:02:45 bookwar: for 9, I understand that c9s composes will be coming out "soon" 18:02:54 for some definition of soon 18:03:04 that's actually cool, didn't expect that 10 is so active already :) 18:03:21 (We are beyond our allotted hour now; I happen to be free and can continue, but if this is an issue for others, we can move this discussion to the devel@ list) 18:03:50 do we have a dedicated Matrix room? 18:03:54 I can continue 18:04:08 Eighth_Doctor: Soon measured in weeks, not months or geological epochs :) 18:04:45 Eighth_Doctor: I created #fedora-eln a long while ago, but I didn't really advertise it. 18:05:13 dcavalca: so EPEL for ELN is still the Rawhide sources but built in ELN environment for the wider set than ELN itself, right? 18:05:34 bookwar: That's how I was interpreting it, yeah. 18:05:50 bookwar: yes, that's what I had in mind; an ELN rebuild of the set of packages that is currently in EPEL + their buildrequires 18:06:04 If it was an opt-in, I think I'd be good with exploring that. We'd just need to tweak the compose process to exclude it from the BaseOS and AppStream repos. 18:06:18 as mentioned above, this might be more tenable in practice if we make it an opt-in thing, at least in the beginning 18:06:23 sgallagh: i would do it via separate tag 18:06:47 Good point; it would simplify syncing 18:07:01 Well, this is also going to require resources, are those resources available? 18:07:03 I would never expect it to get its own branch or anything 18:07:04 leaving eln for the limited content, but extending out rebuild tooling to handle another target 18:07:06 `koji build --target=epeln ...` :) 18:07:17 jforbes: That was going to be my next question 18:07:30 Eighth_Doctor: having a epeln branch could be handy to bootstrap the next epel though 18:07:30 pretty much all the same principles that apply to ELN itself would have to apply to an EPELN 18:07:34 no 18:07:35 I think we will probably get the okay as long as we're talking about one-at-a-time opt-ins. 18:07:43 Not a mass-inclusion of Rawhide thuogh 18:07:47 sgallagh: I am not sure that we can answer that here today 18:07:51 dcavalca: the issue with that is ELN is pretty fluid 18:07:51 in theory the resources should be counted as EPEL resources, and there is a plan to expand EPEL afaik. 18:08:03 and what winds up being in EL vs EPEL can change basically at a whim 18:08:06 I'm not suggesting we can. We absolutely would need to propose this to Infra 18:08:19 that could lead to all kinds of insanity if we have to retire and unretire epeln branches like nuts 18:09:08 sgallagh: wrt resources, if there's ways for non-RH folks to help with this, let me know 18:09:15 we can define the epel-next workload in content resolver, and with some additional python scripting add it to existing eln pipelines, so it is only koji resources we should be worried about 18:09:26 dcavalca: I would have to direct you to Infra about that. 18:09:51 I know there are a lot of rules they have to follow 18:09:57 I think if we do epeln things, we should just use content-resolver rules 18:10:19 because generally speaking, fixing builds in rawhide should be our target because we have no real idea of what the final content set will actually be at branch time 18:10:30 Eighth_Doctor++ 18:10:36 ngompa++ 18:10:44 🤣 18:10:55 No cookie for you 18:11:26 agreed, the goal should be for fixes to end up in rawhide 18:11:53 having more content be EL-ready will likely make it easier to ask for an official EPEL branch, so yeah, fixing Rawhide makes sense 18:12:30 dcavalca: do you have a specific set of packages you are interested in for this EPEL? how do you estimate the number of packages for that rebuild? 18:12:35 do we anticipate blowbacks from maintainers who don't like their rawhide branches messed with? 18:12:43 no more than they have now 18:13:00 bookwar: I haven't run the numbers yet, but I can definitely make a list 18:13:02 Probably, but I honestly think that's a net positive. 18:13:21 there are certainly things I'd like in an "epeln" list 18:13:24 I think that we need to provide this functionality generally for the community, but if we provide some initial estimation that we expect 50 packages there, it might be easier to sell to the infra 18:13:24 We've (Fedora Project) been trying to get people to recognize that they don't "own" their packages, they steward them. 18:13:43 Active hostility to other people working on them is something we need to be discouraging. 18:14:20 Suggestion: we agree to limit ourselves to a small number (50 is good) for this calendar year. 18:14:25 a number of my packages that exist in EPEL and Fedora today for me, I'd like to have evaluated in ELN 18:14:39 50 is a nice, even number 18:14:42 So that Infra would have time to adjust resourcing requirements for FY2022 well in advance. 18:15:02 50 + buildrequires seems reasonable 18:15:04 basically, I want to get Fedora infra apps that I maintain packages for in the EPELN content-resolver 18:15:27 sgallagh: we have ~4000 packages in ELN now, and +-50 seems to be in that range still 18:15:27 dcavalca: ehhh, that's got a little too much wiggle-room 18:16:13 You'd be amazed at how many packages get pulled in if you allow ANY rust content, for example. 18:16:30 sgallagh: I agree, but it's kinda hard to discuss this in the abstract 18:16:31 actually it is 3726 now 18:16:51 if we add workload to content resolver, it will calculate it for us 18:16:55 I can tell you that things like rust and golang wouldn't be needed for me, at least at this point 18:17:03 dcavalca: That's true, but I guess I'm suggesting that we should focus on building out our pipeline first 18:17:04 but I can make an actual list with a few hours of work 18:17:08 I'm mostly focused on Python and C/C++ 18:17:09 so I'll do that early next week 18:17:15 sgallagh: fully agree there 18:17:21 i think it could be a great first step actually, to identify the reasonable small workload, add it to content resolver, and check the outcome 18:17:23 Which is going to take some time, which also gives Infra time to prepare for a larger influx later 18:17:40 dcavalca: That would be much appreciated 18:17:55 dcavalca++ 18:17:55 bookwar: Karma for dcavalca changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:17:56 #action dcavalca to create a first-pass at a starter set of EPELN package. 18:18:12 #undo 18:18:12 Removing item from minutes: ACTION by sgallagh at 18:17:56 : dcavalca to create a first-pass at a starter set of EPELN package. 18:18:14 #action dcavalca to create a first-pass at a starter set of EPELN packages. 18:18:24 (The typo was going to bug me) 18:18:30 are we going with that name now? :) 18:18:32 dcavalca++ 18:18:32 sgallagh: Karma for dcavalca changed to 5 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:18:42 EPELN? :) 18:18:44 bookwar: It works: Extra Packages for ELN 18:19:10 Also EPEL Next 18:19:19 Yup, works in both directions 18:19:24 So I'm good with it 18:19:36 I like EPELN 18:19:45 is it the same thing which is discussed as epel next on the mailing list now? 18:19:47 EPELN ++ 18:19:55 bookwar: Probably not? 18:20:00 er, +1 for EPELN I mean 18:20:15 dcavalca++ 18:20:15 Conan_Kudo: Karma for dcavalca changed to 6 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:20:16 I think epel next is epel for CentOS stream 18:20:20 I think that was around how to deal with CentOS Linux being replaced by CentOS Stream 18:20:30 sgallagh: we better check, because I saw mentions of that, and if it means something else already we are going to be in trouble 18:21:13 Carl George is driving that, I'm near 100% certain it doesn't clash (apart from the name) with EPELN here. the thought was that "stream" is overloaded 18:21:14 epel-next = epel staging build for CentOS Stream 18:21:17 turns out "next" is also confusing 18:21:44 "EPELN != epel-next" will be hard to sell 18:21:59 maybe they change it on the stream side 18:22:05 Extra Packages for ELN 18:22:12 I'm putting my foot down here. No naming debate on this meeting, please :) 18:22:20 sorry :) 18:22:23 there's an EPEL meeting this afternoon, we should bring it up there 18:22:25 🤣 18:22:30 yep 18:23:00 OK, we're well over time, so I'm going to close up here, unless there are any urgent remaining topics. 18:23:11 let's go destroy someone else's meeting now :) 18:23:20 haha 18:23:45 sgallagh: will you be chairing the next one? 18:24:04 I'll just mention https://github.com/fedora-eln/eln/issues/33 if folks have thoughts on the remaining item (consuming and mirroring composes) 18:24:08 I'll default to acting as chair and find someone to fill in if I have a conflict. 18:24:16 sounds gravy 18:24:28 if there is going to be an epel for eln, i don't think i have a choice but to rename epel-next to epel-stream 18:24:38 hey carlwgeorge :D 18:24:51 one last thing, how will we collect GitHub IDs? 18:24:55 Everything is negotiable 18:25:01 i have almost none of the meeting context, i'm just here because michel_slm pinged me 18:25:23 #action Everyone on the SIG to email me their Github IDs over the next few days. 18:25:29 #undo 18:25:29 Removing item from minutes: ACTION by sgallagh at 18:25:23 : Everyone on the SIG to email me their Github IDs over the next few days. 18:25:34 #action Everyone on the SIG to email sgallagh their Github IDs over the next few days. 18:25:48 #action sgallagh will update the landing page and github org with the new members 18:25:52 carlwgeorge: damn, I didn't even tag your IRC nick. do you keep a watch for "Carl George" too? :) 18:26:19 probably just "carl", i forget what highlight words i set up 18:26:58 carlwgeorge: there's a plan to enable EPEL for ELN, and the obvious name, EPELN, is dangerously close to epel-next which tracks CentOS Stream 18:27:31 OK, I'm closing up shop now. Thank you to everyone who joined us today. 18:27:32 #endmeeting