21:00:22 <tdawson> #startmeeting EPEL (2021-11-24)
21:00:22 <zodbot> Meeting started Wed Nov 24 21:00:22 2021 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 https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
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_(2021-11-24)'
21:00:22 <tdawson> #meetingname epel
21:00:22 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca
21:00:22 <tdawson> #topic aloha
21:00:22 <zodbot> The meeting name has been set to 'epel'
21:00:22 <zodbot> Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson
21:00:25 <rsc> .hello robert
21:00:26 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
21:00:31 <pgreco> .hi
21:00:32 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
21:00:40 <tdawson> Hi rsc
21:00:44 <tdawson> Hi pgreco
21:00:55 <dcavalca> .hi
21:00:56 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
21:00:57 <SSmoogen[m]> hey I made it home in one piece. hello everyone
21:01:01 <tdawson> Hi dcavalca
21:01:03 <cyberpear> .hi
21:01:04 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
21:01:05 <Eighth_Doctor> .hello ngompa
21:01:06 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
21:01:28 <rsc> SSmoogen[m]: in one piece? What happened? Btw, modularity is "in" these days.
21:01:55 <cyberpear> did we make an archive of 8.4 content now that 8.5 is out?
21:02:00 <tdawson> Hi cyberpear
21:02:16 <tdawson> Hi Eighth_Doctor
21:02:19 * nirik is on PTO, but happens to be here in front of the computer
21:02:26 <tdawson> Hi nirik
21:02:40 <tdawson> I know there is a ticket/issue for archiving the 8.4 content ...
21:02:47 <pgreco> nirik: we need you here today I guess
21:03:14 <pgreco> To guide us on complications for A B or C
21:03:38 <carlwgeorge> .hi
21:03:39 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
21:03:59 * pgreco os slow writing from the phone....
21:04:03 <tdawson> cyberpear: https://pagure.io/releng/issue/10385
21:04:13 * nirik nods
21:04:52 <tdawson> michal will not be here, but he gave me his vote for the epel9 plans.
21:05:30 <tdawson> #topic Mock config
21:05:42 <tdawson> which repo do we use for the default epel config.  https://pagure.io/epel/issue/133
21:06:17 <nirik> personally, I would prefer rhel with clear instructions on how to switch
21:06:22 <carlwgeorge> +1
21:06:36 <pgreco> For me rhel is not an option
21:06:41 <carlwgeorge> alternate `{clone}+epel-*` configs exist, and more can be added
21:06:59 <themayor> Hello sorry to be late
21:07:04 <tdawson> Hi themayor
21:07:09 <nirik> pgreco: yeah, but its always been weird that mock used centos and epel didn't.
21:07:15 <Eighth_Doctor> well, obviously I'm in the "rhel is not an option" camp (unless fatherlinux's tease about rhel ubi becomes a reality)
21:07:31 <nirik> I know it's a pain, but a one time 'oh, let me use alma then' isn't that bad and makes it clear you are setting it to do that
21:07:32 <dcavalca> I also agree that rhel doesn't seem to be a usable option here
21:07:33 <carlwgeorge> moving to rhel would be an office space style "fixed the glitch" thing
21:07:47 <Eighth_Doctor> not really
21:08:05 <tdawson> To me it's  "Add a glitch" if we switch to RHEL
21:08:14 <Eighth_Doctor> +1
21:08:32 <pgreco> Alma or Rocky, flip a coin
21:08:32 * nirik sees no one else agrees. oh well.
21:08:36 <carlwgeorge> epel builds against rhel in koji.  mock epel building against anything but rhel is the problem.
21:08:53 <carlwgeorge> i agree with nirik
21:08:59 <nirik> carlwgeorge: ah, missed that...
21:09:00 <Eighth_Doctor> it was never weird
21:09:06 <pgreco> carlwgeorge: but it is the same problem as we have now
21:09:19 <Eighth_Doctor> it was always done that way because RHEL is painful for people to use locally
21:09:23 <tdawson> koji builds against RHEL because we have a dedicated downloaded RHEL mirror in place.   Are you asking all mock users to continuassly download RHEL?
21:09:24 <carlwgeorge> yes, it's a problem we have now, and rather than continue the problem this is the chance to correct it
21:09:27 <nirik> it's caused issues in the past... people mock build something, test it, it works, they do epel builds and they fail or don't work
21:10:01 <carlwgeorge> tdawson: of course not.  they can set up a subscription or use one of the explicit alternative configs.
21:10:02 <Eighth_Doctor> carlwgeorge: there is only a minute hope local use issues would be resolved, they haven't in the past decade, I doubt they care enough now
21:10:21 <nirik> tdawson: no need for that.
21:10:43 <pgreco> Can I have a local rhel mirror with just rsync?
21:10:49 <Eighth_Doctor> nope
21:10:52 <tdawson> But, your argument that "if koji does it, everyone can do it" is exactly what you are saying.
21:10:53 <rsc> Is this about the default mock configuration for EPEL? Make it configurable for users via alternatives(1)?
21:10:55 <Eighth_Doctor> they don't support rsync, I asked
21:11:38 <Eighth_Doctor> we want less `alternatives(1)` in our life, not more
21:11:41 <carlwgeorge> no, i said koji builds against rhel, and it's possible for mock to also so it should.  anyone who doesn't want to set up a sub has multiple alternative options.
21:11:47 <nirik> no need for alternatives...
21:12:16 <Eighth_Doctor> The only reason Koji builds against RHEL is because that's the only way to get RHEL exposed to the community's needs
21:12:34 <pgreco> The replacements for what Red Hat broke are Alma and Rocky
21:12:34 <Eighth_Doctor> and even then, up until a couple months ago, people barely cared anyway
21:12:42 <mroche[m]> Just a thought, but does there need to be an `epel-8-<arch>` config?
21:12:43 <nirik> ln -sf /etc/mock/epel-8-x86_64.cfg /etc/mock/epel-8-x86_64.cfg
21:12:46 <pgreco> Rhel doesn't fill the gap
21:12:59 <carlwgeorge> i still have not heard an argument for why `{clone}+epel-*` configs are not sufficient
21:13:05 <rsc> Maybe no "epel-8-x86_64.cfg" at all, and let users decide for "clone+epel"?
21:13:15 <nirik> Eighth_Doctor: lots of people care. I have had people tell me they can only use epel because it's built against rhel.
21:13:21 <carlwgeorge> mroche[m]: upstream mock did suggest just removing that config and forcing people to choose one of the labeled ones
21:13:37 <Eighth_Doctor> nirik: doesn't change the fact I get radio silence whenever I have bugs in RHEL packages that break my EPEL ones that people use
21:13:43 <pgreco> That is better than using rhel
21:13:46 <nirik> I think mock can help people here... spew out a link or doc that explains whats going on
21:13:47 <mroche[m]> I'd lean that way myself, no default config.
21:14:01 <tdawson> I'm going to say I prefer using a clone.  But on the flip side, I also use the appropriate mock thing (rhelepel, alma-epel, etc.)  so I don't have too strong a feelings.
21:14:12 <Eighth_Doctor> the rhel configs have significant dificencies
21:14:45 <Eighth_Doctor> there's limited access with rhel, no cross-arch access, forced cache expiration (making things much slower), and subscription-manager regularly breaks on non-rhel
21:14:53 <carlwgeorge> and remember that these files are config(noreplace) so anyone can modify them and not have those changes altered by future updates
21:14:57 <Eighth_Doctor> it also totally destroys non RH/Fedora mock usage
21:14:59 <rsc> I would have no epel-8-<arch>.cfg, that still allows to create users from rhelepel, rockepel (or whatever) a symlink to epel-8-<arch> as favorite.
21:15:14 <rsc> (given that alternatives(1) was disliked)
21:15:22 <Eighth_Doctor> carlwgeorge: they're not supposed to be `%config(noreplace)`
21:15:25 <Eighth_Doctor> that's actually a bug
21:15:38 <Eighth_Doctor> the only file that's a config file is the default.cfg symlink
21:16:14 <carlwgeorge> that doesn't make any sense, but we don't have to dig into that here.  the state of things is they are config(noreplace) now.
21:16:22 <pgreco> 3 alternatives and no default (which can be fixed with a symlink) is the least bad option for me
21:16:25 <tdawson> My biggest concern is fedpkg breaking.  Is there a way to have fedpkg choose the right mock?  (there might be ... checking ...)
21:16:38 <Eighth_Doctor> there is not right now
21:16:47 <pgreco> Rhel is the worst, by far
21:16:50 <nirik> there's an open issue about what fedpkg mockbuild should do
21:16:54 <Eighth_Doctor> and note that altarch emulated builds flat out does not work with rhel configs
21:16:56 <carlwgeorge> considering mock already does symlink handling for default and rawhide, adding another one for epel8 seems fine
21:17:29 <carlwgeorge> fedpkg appears to be deferring to us
21:17:35 <carlwgeorge> *fedpkg devs
21:18:07 <dcavalca> if we go the symlink (or alternatives) route, is there a concern of potentially builds made by different users behaving slightly and confusingly differently?
21:18:08 <nirik> fedpkg mockbuild on a epel target could even just ask the user...
21:18:10 <tdawson> So, fedpkg mockbuild does have a --mock-config option, so I'm ok with ... well anything at the momement, including removing epel-8
21:18:27 <Eighth_Doctor> if RHEL UBI tomorrow had the entire package set available, I'd just suggest that and be done with this
21:18:30 <nirik> dcavalca: well, we already have that
21:18:38 <Eighth_Doctor> but it doesn't and aside from Scott teasing it, I've heard no indications of it happening
21:18:42 <rsc> nirik: could it? Ask the user is also an option for me (to let the user configure it)
21:18:55 <carlwgeorge> i still have not heard an argument for why `{clone}+epel-*` configs are not sufficient
21:19:11 <carlwgeorge> unless i missed it
21:19:15 <nirik> carlwgeorge: they seem fine to me. ;)
21:19:20 <rsc> carlwgeorge: your point is to have only `{clone}+epel-*` configs and no epel-8-*?
21:19:23 <Eighth_Doctor> I have not heard a decent argument for `epel-*` should be rhel
21:19:39 <pgreco> Eighth_Doctor: +1
21:19:55 <Eighth_Doctor> what Koji uses is immaterial to what local users need
21:19:59 <nirik> because epel official builds use rhel.
21:20:02 <Eighth_Doctor> and if a rhel clone is doing its job well, it doesn't even matter from a package build perspective
21:20:06 <carlwgeorge> rsc: my point is just that all the complaints about defaulting epel to rhel are easily mitigated by the other epel configs
21:20:09 <pgreco> Rhel as a default breaks users, that is not an option for me
21:20:14 <nirik> if you are making packages and trying to test locally thats the way to make sure it's the same as in the build system
21:20:16 <Eighth_Doctor> nirik: so what? nobody can upload their binaries into Koji to release
21:20:34 <carlwgeorge> Eighth_Doctor: depending on a rhel clone doing their job well is not something i'm prepared to rely on
21:20:48 <nirik> so, they should never test local mock builds? Or just assume whatever clone is 100% the same?
21:20:54 <mroche[m]> In that case just use the rhelepel config? I don't see a need to have a default epel-8 config, personally.
21:20:55 <Eighth_Doctor> carlwgeorge: I'm not prepared to rely on Red Hat to improve RHEL consumption experience
21:21:00 <pgreco> Rhel should be an option, no question about it, but not the default
21:21:09 <rsc> carlwgeorge: I dislike RHEL as default, except for the usage in office, where it's RHEL. 99% of my builds use a clone, I don't want to reconfigure that by default to a clone.
21:21:25 <rsc> carlwgeorge: but that's my personal preference.
21:21:35 <nirik> rsc: even when the reconfigure is... just changing a symlink?
21:21:41 <carlwgeorge> seems like there is no consensus about a default, so are we recommending no default?
21:21:50 <dcavalca> IMO shipping no config is better than defaulting to RHEL
21:21:57 <tdawson> carlwgeorge That's what it's looking like
21:21:59 <pgreco> No default is better than rhel
21:22:02 <dcavalca> at least with no config it's pretty explicit that one needs to make a choice
21:22:05 <Eighth_Doctor> carlwgeorge: more people in this conversation are for clone than fo rrhel
21:22:06 <rsc> Right.
21:22:10 <dcavalca> defaulting to rhel just creates a broken experience for almost everybody
21:22:30 <Eighth_Doctor> but I'm fine with no default if we want to ignore the majority
21:22:32 <rsc> The other question would be if we could agree on a specific clone, given there are at least two.
21:22:39 <nirik> it just means everyone has to read and decide what they want to use
21:22:45 <mroche[m]> +1 to no default
21:22:55 <dcavalca> now, whether shipping a clone is better than shipping no config -- I'm not sure tbh
21:23:11 <dcavalca> it's definitely a better experience for users, as it'll work out of the box, and work right in like 99% of cases
21:23:23 <Eighth_Doctor> rsc: I proposed Alma because they've been the fastest to release and have committed to supporting all RHEL architectures expeditiously
21:23:32 <carlwgeorge> Eighth_Doctor: doesn't really look like a majority to me, as rsc said picking "any clone" is not really a choice, something has to be picked
21:23:35 <dcavalca> but I can definitely see some corner case where the different might matter, and it would be super confusing to track down unless you know what's going on
21:23:38 <SSmoogen[m]> i am confused .. if there is no default, how does `fedpkg mockbuild` work for a developer?
21:23:44 <pgreco> I'll repeat, for me the best option is 3 options with no default
21:23:50 <Eighth_Doctor> SSmoogen: it doesn't
21:24:14 <nirik> SSmoogen[m]: they would get a "sorry, you haven't set what you want to build against, link the approprate file..." message. They would set that link and rerun
21:24:20 <carlwgeorge> Eighth_Doctor: but they have also committed to an open build system, and we're still waiting on that.  i'm sure it will happen eventually, but how long?
21:24:21 <tdawson> SSmoogen[m]: But, on a blank fedora machine, having RHEL as the option doesn't work either.
21:24:44 <Eighth_Doctor> carlwgeorge: well, we can always ask themayor, since he's here
21:25:06 <rsc> Make the link on RHEL to rhel, on Rocky to rocky and on Alma to alma? And Fedora users have to choose themself?
21:25:21 <tdawson> Ooohhh
21:25:26 <rsc> Nasty %post scriptlet.
21:25:27 <Eighth_Doctor> basically "screw Fedora users" :/
21:25:39 <carlwgeorge> i think having `fedpkg mockbuild` spit out `set up your sub or pick an alternative config` is a perfectly fine outcome
21:26:11 <carlwgeorge> Eighth_Doctor: no one is saying screw fedora users.  please don't jump to conclusions like that.
21:26:18 <Eighth_Doctor> it would have to do it without setting symlinks (e.g. by using fedpkg's config file)
21:26:33 <SSmoogen[m]> for EPEL-9, the plan a couple of months ago was not to have fedpkg ported to EPEL and have people rely on doing their work in Fedora systems. If RHEL-X doesn't work for a fedora system.. I think we are looking at a fun time in anycase
21:26:34 <rsc> carlwgeorge: well, my suggestion would somehow be "screw Fedora users"
21:26:44 <carlwgeorge> Eighth_Doctor: which mock devs have already said they are willing to do
21:26:57 <Eighth_Doctor> carlwgeorge: not in mock
21:26:59 <Eighth_Doctor> in fedpkg
21:27:19 <Eighth_Doctor> if you're going to make people deal with this, the configuration should be at the correct abstraction
21:27:28 <Eighth_Doctor> when using mock directly, you already have to tell it which config anyway
21:27:34 <Eighth_Doctor> fedpkg does not do that
21:28:06 <tdawson> I'm going to timebox this discussion.  on the half hour we need to either have a decision, or just move on.
21:28:07 <carlwgeorge> i'm happy to discuss the implementation in more detail if that's what we're deciding, but lets keep this on track so we can get to the other voting items
21:28:09 <Eighth_Doctor> and if we do this, then `epel-*` configs get deleted, no replacement, end of story
21:28:40 <nirik> thats seems...wrong
21:29:13 <Eighth_Doctor> so is forcing a decision based on a privileged position you have onto everyone else
21:29:16 <SSmoogen[m]> My main reason for saying I was "+1 for Alma" was mainly for the reasons Conan pointed out earlier about speed of distro release AND the fact that we are going to have to explain to various developers how to set up a Red Hat account and then have mock set up to work with it.
21:29:25 <tdawson> The biggest problem is with fedpkg, can a user set the fedpkg default?
21:29:33 <nirik> I missed where I was forcing anything. I was trying to explain my position.
21:29:35 <carlwgeorge> Eighth_Doctor: stop.
21:29:36 <Eighth_Doctor> tdawson: not today
21:29:48 <SSmoogen[m]> Conan Kudo: I think you are getting a little too heated for this conversation. Could you back off.
21:29:56 <Eighth_Doctor> fine
21:29:58 * Eighth_Doctor walks away
21:30:07 <dcavalca> so, to me it sounds like having the ability to set a default in fedpkg would be valuable regardless of the outcome here
21:30:26 <tdawson> dcavalca: I agree with that
21:30:28 <rsc> Maybe fedpkg could have the magic to prefer the local distribution?
21:30:43 <carlwgeorge> +1 to no out of the box default with the ability to set your own default
21:30:57 <nirik> well, we have until the end of the year for this right? perhaps gather more info and discuss more on lists/ponder onit more
21:31:04 <dcavalca> is there urgency in this decision?
21:31:12 <carlwgeorge> yes i don't think this one has to be decided today
21:31:22 <Eighth_Doctor> this was being forced because copr wants to switch now
21:31:26 <nirik> I don't think we should force a decision... folks got heated, perhaps we can find a consensus?
21:31:29 <Eighth_Doctor> and copr currently controls mock upstream
21:31:40 <carlwgeorge> i don't recall copr asking for "now"
21:31:54 <carlwgeorge> punting for a week seems fine
21:32:03 <dcavalca> yeah, if we can hold off another week I think that might help in getting closer to a consensus, or at least a better understanding of the tradeoffs
21:32:36 <tdawson> OK, I'm going to call a timebox with no decision.   Let's move this to the epel issue
21:33:14 <tdawson> #topic EPEL 9 Rollout Proposals
21:33:22 <tdawson> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/NH4CM6MAVUTUH35NDM53PTKCHODSEP6F/
21:33:55 <carlwgeorge> as this one has had longer to bake on the list and is more time sensitive, i propose we just vote unless people have more questions
21:34:14 <carlwgeorge> time sensitive == we'd like to announce in line with the c9s launch promo
21:34:20 <dcavalca> are we doing ranked choice?
21:34:24 <nirik> do we have any sense about beta updates?
21:34:33 <pgreco> For me, the order is CBA, but highly dependant on th strain ip puts on infra
21:35:08 <tdawson> dcavalca: We can do ranked choices yes.
21:35:29 <carlwgeorge> the indication i've gotten from the high touch beta folks is that updates happen, they just aren't focused on security, more focused on changes that rhel wants customer interaction to iterate on before ga
21:35:34 <tdawson> michal also chose CBA
21:35:34 * nirik is waffling between A and B first, then C last. If beta is going to get updates so it's not insecure I could go with B
21:35:59 <carlwgeorge> B and C are equal to me, A last
21:36:12 <dcavalca> I'm leaning towards CB >> A, i.e. I have a slight preference for C over B, but I can see the benefits in either, and I feel both are superior to A
21:36:20 <rsc> B and C are quite equal to me to, except that I dislike the freeze point.
21:36:51 <tdawson> rsc: What about the freeze point is the problem?
21:36:54 <carlwgeorge> yeah my main question on b vs c is which is harder, getting the beta bits in our current arrangement or doing the c9s freeze
21:36:56 <Eighth_Doctor> I have a preference to C over B, but I'm fine with either
21:37:08 <rsc> tdawson: what happens to security updates during such a freeze?
21:37:20 <carlwgeorge> nirik: thoughts on implementation difficulty of b vs c?
21:37:23 <nirik> My problem with C is the 'not built against rhel' which I think will cause a lot of confusion
21:37:58 <carlwgeorge> rsc: security updates generally don't affect library sonames, which is what would actually impact epel packages
21:38:10 <nirik> I think on implementation B is a bit easier than C, but not vastly so... the freeze point will need coordination
21:38:16 <Eighth_Doctor> the problem I have with B is that the feedback loop is too slow
21:38:40 <Eighth_Doctor> if something is missing that should be part of the RHEL 9.0 GA, we can easily iterate on that now
21:38:47 <carlwgeorge> any package that has problems with B can still opt in to epel9-next
21:38:48 <Eighth_Doctor> post-GA, we're basically screwed
21:38:48 <nirik> with C we get nothing between freeze point and release? or ?
21:38:52 <rsc> carlwgeorge: really? Some security updates have at least API changes, so I wouldn't bet on ABI changes, too.
21:39:10 <Eighth_Doctor> rsc: it's extremely rare that ABI changes happen as part of security updates
21:39:20 <Eighth_Doctor> but if it helps, there are no "security updates" pre-GA
21:39:44 <carlwgeorge> also to be clear the freeze isn't freezing epel, it's freezing the c9s mirror used for the buildroot so no 9.1 changes show up
21:39:55 <Eighth_Doctor> right
21:40:12 <Eighth_Doctor> from my perspective, the problem with epel9-next is that the buildroot repo is there
21:40:23 <tdawson> I'm leaning towards C for the "missing devel packages" reason.  There have been several devel packages added since Beta that I need, so I will be pretty much forced to use epel9-next, thus having the epel9 option, isn't an option for me.
21:40:25 <nirik> I do like B over A for not having to mass rebuild. that makes it easier on releng.
21:40:48 <Eighth_Doctor> if we didn't have that, then B would probably be workable
21:41:06 <carlwgeorge> Eighth_Doctor: separate from this decision, i'm fine doing further changes to the epel9-next buildroot to only use content in the compose
21:41:11 <Eighth_Doctor> but as tdawson said, it's really painful right now to use RHEL beta
21:41:36 <Eighth_Doctor> I'd rather err on the side of agility so that the content set for RHEL is in good shape for EPEL by GA
21:42:22 <tdawson> Has anyone done a comparison of what packages are in RHEL9 Beta vs what is currently in CS9?
21:42:24 <carlwgeorge> i would much rather explain to maintainers and users that epel9 is temporarily built against c9s than explain all the mess that is involved with plan A
21:42:34 <tdawson> +1
21:42:35 <Eighth_Doctor> yeah
21:42:38 <carlwgeorge> tdawson: for library sonames, yes, almost identical
21:42:52 <Eighth_Doctor> tdawson: sonames are fine, it's the CRB content set that's _extremely_ different
21:42:59 <tdawson> carlwgeorge No, I mean packages in CRB
21:43:03 <Eighth_Doctor> I know that because it's pretty much mostly my fault the content set has expanded
21:43:31 <tdawson> I've got 4 packages that they added too .... which I am very grateful for.
21:43:48 <rsc> I think, I like B most, because it's a RHEL (with its advantages and disadvantages)
21:43:55 <nirik> for C, would we just currently use the same buildroot as we do for epel9-next?
21:43:59 <carlwgeorge> are you suggesting we do C but with the buildroot, not the compose content?
21:44:27 <tdawson> nirik No, We would need to use the repo's that we end up using for the final epel9, meaning AppStream, BaseOS and CRB
21:45:29 <nirik> ok. well, why would we need to, pre freeze?
21:46:17 <tdawson> The problem is that at some point, CS9 starts becoming RHEL 9.1
21:46:17 <carlwgeorge> based on what i know about the rhel process, it's extremely unlikely additional -devel packages get added to crb between our freeze and the 9.0 ga release
21:46:24 <pgreco> To avoid getting 9.1 content just before ga
21:47:02 <nirik> tdawson: right, but for C to work, we have to know when that happens?
21:47:06 <Eighth_Doctor> I think it's super-valuable for us to hit missing devel packages early and get people notifying maintainers of the issues up front and getting fast feedback cycles
21:47:12 <carlwgeorge> nirik: i know, we're good
21:47:41 <nirik> I guess this is a sidetrack/implementation detail. We can figure it later.
21:47:42 <Eighth_Doctor> it'll make EPEL9 a way nicer experience for RHEL 9.0 GA than EPEL8 was for 8.0 GA
21:47:42 <carlwgeorge> we're not supposed to say publicly but rest assured i'll make sure we freeze before any 9.1 content shows up in c9s
21:48:07 <carlwgeorge> Eighth_Doctor: +1, the entire goal of the alternative proposals
21:48:16 <Eighth_Doctor> and tdawson has fancy automation to tell people to retire their packages when they move into RHEL
21:48:29 <Eighth_Doctor> which means if a package gets plucked even during this process, we can react to it fairly quickly
21:48:31 <Eighth_Doctor> which is super-nice
21:48:32 <tdawson> That's true ... it's got a few bugs, but it's working.
21:48:55 <Eighth_Doctor> well yeah, I got a BZ for retiring redhat-fonts in epel9 before it even opened up :P
21:48:56 <nirik> anyhow, I think I am BAC now, but it sounds most folks are for C?
21:49:23 <tdawson> Yep ... has anyone changed their minds from what they originally said their preferences were?
21:49:35 <Eighth_Doctor> I think folks are going to seriously appreciate it if we have epel9 with option C
21:49:38 <rsc> nirik: BCA here
21:49:42 <Eighth_Doctor> I know my team certainly will
21:49:47 <Eighth_Doctor> CBA here
21:49:53 <pgreco> C or B with preference for C, please no A
21:50:03 <dcavalca> same as pgreco :)
21:50:12 <Eighth_Doctor> same as pgreco technically :)
21:50:28 <Eighth_Doctor> but I suspect "no A" is not an option to vote for
21:50:39 <carlwgeorge> i feel like we should just vote B or C at this point
21:50:46 <pgreco> C
21:50:54 <tdawson> Ya, A is out of the running, everyone had it last.
21:51:05 <tdawson> Except for nirik, sorry nirik
21:51:15 <nirik> no worries. :)
21:51:42 <Eighth_Doctor> C
21:51:42 <nirik> B I guess for me, but if I'm outvoted so be it... :)
21:51:49 <rsc> B
21:51:50 <carlwgeorge> i pick whatever nirik thinks is easiest to implement between B and C
21:51:59 <Eighth_Doctor> lol, such a non-answer :)
21:52:10 <nirik> carlwgeorge: it's about a wash probibly... so pick the one you think is better. :)
21:52:20 <carlwgeorge> well my original alternative idea was B, but tdawson convinced me of the value of C
21:52:46 <carlwgeorge> nirik: in that case, i'd rather explain B
21:53:08 <tdawson> Thus far, we have 2 B's and 4 C's ... which seems short, just a sec.
21:53:15 <carlwgeorge> someone at some point said something about "always using rhel, with all it's pros and cons"
21:53:37 <Eighth_Doctor> that was rsc
21:53:39 <rsc> carlwgeorge: that was /me
21:53:41 <dcavalca> C
21:53:47 <tdawson> 2 B's and 6 C's
21:53:48 <carlwgeorge> ah yes, i agree with that outlook rsc
21:54:15 <Eighth_Doctor> in Fedora Koji, I generally do agree with that, it's just there are too many benefits to having epel9 pre-release using c9s to ignore
21:54:40 <Eighth_Doctor> especially when we have to one-by-one request unshipped packages to be added back to the compose
21:54:48 <tdawson> Unless some major swing happens, I'm going to declare Plan C the winner.
21:54:50 <nirik> so looks like C wins?
21:54:51 <Eighth_Doctor> if we could do it en-masse, then that would be a different story
21:55:14 <Eighth_Doctor> I think so
21:55:22 <Eighth_Doctor> based on tdawson's count
21:55:25 <nirik> so back to my question quickly then? can we implement this by just using the same buildroot repo we use for epel9-next? then when we 'freeze' copy that off to a frozen repo?
21:55:47 <nirik> or do we need the composed content?
21:55:52 <carlwgeorge> i think that's the best choice to get started, we can switch to compose content later if needed
21:56:03 <tdawson> #info Plan C was chosen.  Plan A - 0 votes, Plan B - 2 votes, Plan C 6 Votes  (1 vote for Plan C was placed before the meeting)
21:56:16 <carlwgeorge> which we'll do anyways when it switches to rhel
21:56:42 <tdawson> Gonna hit the last topic while we are here -
21:56:53 <tdawson> #topic Set lower days to stable for epel9-next
21:57:25 <carlwgeorge> c9s is already reflecting 9.0 content, so i think sticking with 7 days is best
21:57:37 <tdawson> Someone, I think it was Miro, asked for epel9-next bodhi days to be 3 instead of 7
21:57:49 <carlwgeorge> changing it to 3 days would kinda contradict our upcoming c9s launch promotion
21:57:56 <rsc> 3 would be also fine for me, it would be equal to unreleased Fedora versions
21:58:02 <Eighth_Doctor> yeah, Miro would like epel-next to follow the same conditions as branched Fedora
21:58:05 <nirik> I'm fine with 3 days, but no lower.
21:58:13 <tdawson> I don't have an opinion either way on this.
21:58:16 <Eighth_Doctor> yeah I'm fine with that
21:58:22 <tdawson> Oh, definatly no lower than 3 days.  \
21:58:25 <carlwgeorge> if we change it, when do we change it back to 7?
21:58:38 <nirik> carlwgeorge: at 9 GA?
21:58:40 <Eighth_Doctor> carlwgeorge: never? epel9 is 7, epel9-next is 3
21:58:53 <nirik> oh, yeah.. .that would work too
21:58:59 <carlwgeorge> hmmm
21:59:06 <Eighth_Doctor> we could use epel9 at 3 during pre-release
21:59:11 <Eighth_Doctor> but bump it to 7 at GA time
21:59:17 <carlwgeorge> now that epel9-next isn't going to launch standalone, that changes how i was thinking of this
21:59:17 <Eighth_Doctor> that would also make iteration faster
21:59:59 <Eighth_Doctor> ideally, epel9-next would be used very sparingly during pre-release time
22:00:07 <carlwgeorge> i'm still not really on board with implying that stream == pre-release fedora, they aren't really comparable
22:00:16 <Eighth_Doctor> it's not, sure
22:00:18 <nirik> there is a bit more time crunch to epel9-next, since it becomes moot at the next point release... but thats a 6 month window right?
22:00:24 <Eighth_Doctor> but the churn rates are relatively similar
22:00:43 <nirik> well, the churn should go down after GA right?
22:00:44 <carlwgeorge> nirik: yup, 4-6 months depending on when a change lands
22:00:45 <tdawson> I don't think the churn rates will stay as high as they are right now.
22:00:55 <Eighth_Doctor> god I hope not
22:01:17 <Eighth_Doctor> but branched fedora is relatively stabilized compared to rawhide
22:01:52 <carlwgeorge> as long as main epel stays at 7 days, i guess i'm fine with epel-next being shorter
22:02:06 <Eighth_Doctor> I'm fine with that too
22:02:14 <Eighth_Doctor> just no more 14 days nonsense
22:02:33 <nirik> note also you can set your update to higher if you like. ;)
22:02:41 <Eighth_Doctor> yup
22:02:42 <tdawson> I really have no opinion on this, so I will abstain from voting.    So, am I reading it right as we think 7 days for epel9 and 3 for epel9-next ?
22:02:45 <Eighth_Doctor> it's just the floor
22:03:12 <Eighth_Doctor> tdawson: yeah
22:03:19 <carlwgeorge> but default is king
22:03:28 <tdawson> Is anyone opposed to this?
22:03:32 <mroche[m]> Considering the reasons why a package would end up in -next, a shorter timeline sounds fine
22:03:53 <carlwgeorge> yeah without a standalone phase, it should be mostly simple rebuilds
22:04:09 <pgreco> I think I'm fine with next being shorter than epel
22:04:17 <carlwgeorge> apart from tdawson's kde work of course
22:04:31 <Eighth_Doctor> lol
22:04:38 <Eighth_Doctor> whenever I trigger Qt updates :P
22:04:39 <tdawson> I get enough karma that mine go through fairly fast no matter what it's set to. :)
22:04:50 <mroche[m]> 12 hours tops for those 😛
22:04:56 <tdawson> That's why I have no opinion.
22:05:09 <tdawson> ;)
22:05:11 <Eighth_Doctor> this is probably going to make maintainers of other DEs much happier though
22:05:26 <Eighth_Doctor> they don't have the same clout KDE Plasma has, and giving them some agility is nice
22:05:57 <Eighth_Doctor> who knows, maybe someone will backport Pantheon from Fedora to EPEL 9
22:06:15 <Eighth_Doctor> or Deepin
22:06:22 <Eighth_Doctor> or any of the other lesser-known DEs
22:06:37 <carlwgeorge> we're over time but i have one quick thing i want to throw out for people to noodle on.  what do yall think about focusing our discussions on the epel issue tracker, and tagging issues as "meeting" to drive the agenda?
22:06:47 <carlwgeorge> example https://pagure.io/epel/issue/133
22:06:48 <tdawson> #info Passed: epel9 will have 7 day and epel9-next will have 3 day waiting period in bodhi.  6 votes for, 0 votes against, 1 obstain.
22:07:13 <tdawson> carlwgeorge You mean, like I found in the old documentation. :)
22:07:19 <carlwgeorge> hehe
22:07:37 <carlwgeorge> also gives us a nice place to record decisions
22:07:54 <nirik> that is always a nice idea, but often it doesn't work in practice. ;)
22:08:28 <nirik> happy to try it, but usually people get busy and don't get time to update things and having an actual meeting makes them think about that thing
22:08:55 <tdawson> Let's do it for at least part of the meeting.  See how it goes.
22:09:29 <carlwgeorge> i think what i'm getting at is shifting most of the conversation from the mailing list to the issue tracker, mainly because i don't like email :P
22:09:53 <carlwgeorge> but also the organization stuff for meetings and decisions
22:10:34 <tdawson> Yep
22:10:49 <tdawson> We're way over time, thank you all for the good discussions.  Ya'll are great to work with and each makes EPEL a great place for everyone.
22:11:00 <dcavalca> thanks tdawson
22:11:02 <tdawson> I'll talk to ya'll next week, if not sooner.
22:11:07 * nirik thinks tickets are a poor place for discussion, but whatever, I will go where the discussion is.
22:11:11 <tdawson> #endmeeting