16:03:31 <sgallagh> #startmeeting Fedora ELN SIG (2021-05-21)
16:03:31 <zodbot> Meeting started Fri May 21 16:03:31 2021 UTC.
16:03:31 <zodbot> This meeting is logged and archived in a public location.
16:03:31 <zodbot> The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:31 <zodbot> The meeting name has been set to 'fedora_eln_sig_(2021-05-21)'
16:03:40 <michel_slm> .hello salimma
16:03:41 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
16:03:45 <dcavalca> .hi
16:03:46 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
16:03:48 <sgallagh> #meetingname eln
16:03:48 <zodbot> The meeting name has been set to 'eln'
16:03:56 <sgallagh> #chair sgallagh bookwar[m]
16:03:56 <zodbot> Current chairs: bookwar[m] sgallagh
16:04:02 <sgallagh> #topic init process
16:04:06 <sgallagh> .hello2
16:04:07 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:04:19 <cyberpear> .hi
16:04:20 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:04:22 <tstellar_> .hello tstellar
16:04:23 <zodbot> tstellar_: tstellar 'Tom Stellard' <tstellar@redhat.com>
16:05:34 <sgallagh> OK, first up:
16:05:43 <sgallagh> #topic Old Business
16:06:18 <sgallagh> Does anyone have any updates on the two topics from last meeting? That would be the AWS images and the alternative composes from side-tags questions.
16:07:32 <dcavalca> I have an update on something else: thanks to nirik, rsync for ELN is now working
16:07:44 <cyberpear> 🎉
16:07:45 <sgallagh> dcavalca++ nirik++
16:07:45 <zodbot> sgallagh: Karma for dcavalca changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:07:48 <zodbot> sgallagh: Karma for kevin changed to 18 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:07:50 <dcavalca> so we've put up http://mirror.facebook.net/fedora-eln/production/latest-Fedora-ELN/
16:08:07 <sgallagh> Nifty!
16:08:08 <michel_slm> nirik++
16:08:09 <zodbot> michel_slm: Karma for kevin changed to 19 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:08:15 <sgallagh> Thanks for driving that
16:08:59 <sgallagh> tstellar_: Did you have any luck with ODCS/OSCI folks?
16:09:16 <tstellar_> sgallagh: I have not reached out to them yet.
16:09:39 <sgallagh> Okay, no problem.
16:10:05 <sgallagh> #topic New Business
16:10:38 <sgallagh> I started a conversation on the Fedora Devel list around how to handle ELN-specific changes going forward.
16:10:57 <sgallagh> This led to a couple useful sub-threads (and a few less-useful sidetracks)
16:11:56 <dcavalca> sgallagh: did we reach a conclusion there?
16:12:06 <sgallagh> One thing that came up that I'd like to specifically discuss is the question of what to do around the time that RHEL/CentOS Stream 10 is going to branch from Fedora.
16:12:31 <sgallagh> dcavalca: No, the conversation has petered off somewhat; I was hoping some of the folks in this meeting could chime in and revitalize it.
16:13:16 <sgallagh> For quick context on the topic: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AE76VCDIBIS7IGDG3D77MK6NWG2XFT7D/
16:14:16 * michel_slm catching up on that thread
16:14:25 <sgallagh> With F34 and EL9, we had decided that we wanted to take advantage of the full F34 process to pick up changes
16:15:02 <dcavalca> sgallagh: the ELN branch is only for ELN specific stuff that can't go into rawhide right? my understanding is that we'd still prefer doing work in rawhide wherever possible
16:15:32 <sgallagh> Actually, I'd like to hold a formal vote of the SIG to make that assertion
16:15:39 * Eighth_Doctor waves
16:15:52 <Eighth_Doctor> .hello ngompa
16:15:52 <tdawson> I thought the ELN branchs are for RHEL specific stuff that can't go into Fedora.
16:15:52 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:16:12 <Eighth_Doctor> sgallagh: so that thread concerned me, it started sounding like people wanted permanent eln branches for all stuff for rhel
16:16:19 <sgallagh> OK, we have two topics going on simultaneously here
16:16:21 <Eighth_Doctor> which is something we've explicitly tried to avoid
16:16:31 <sgallagh> Let's pick one for now:
16:16:32 <tdawson> Sorry ... that is exactly what you said ...
16:16:58 <sgallagh> #topic Rawhide vs. EL-specific changes
16:17:12 <sgallagh> (We can come back to my question about the branch timing)
16:17:44 <sgallagh> I tried to roughly enumerate in the original message to that thread the set of cases where we would need to be able to do this.
16:17:44 <michel_slm> the original proposal mentioned several reasons this could happen. some I think are unavoidable
16:18:08 <michel_slm> but some (like "maintainer does not want to cooperate") is worrying. they have a point, Fedora is not RHEL, but..
16:18:18 <sgallagh> One thing I realized later that I forgot to note was the potential downsides (primarily with regards to complications with syncing to CentOS Stream)
16:18:26 <dcavalca> I think there's a usecase for ELN branches, but IMO we should treat them as a last resort
16:18:27 <cyberpear> I think EL-specific changes should be `--with`/`--without` options in the spec files.
16:18:39 <dcavalca> cyberpear: fully agree there
16:18:40 <sgallagh> dcavalca: That's my personal stance as well.
16:18:47 <Eighth_Doctor> same
16:18:48 <sgallagh> cyberpear: That's definitely something we want to work on.
16:19:01 <dcavalca> IMO the ideal state is that the rawhide spec builds on both EL and Fedora in a sensible way
16:19:06 <cyberpear> dcavalca++ ELN branches should be last resort. perhaps should be voted upon before any are created?
16:19:06 <zodbot> cyberpear: Karma for dcavalca changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:19:12 <dcavalca> this would make everybody's life easier
16:19:15 <Eighth_Doctor> dcavalca: 1000% agree
16:19:17 <sgallagh> Petr Sabata (contyk) was working on that about half a year ago, but we ran out of time in the EL 9 run-up and it was put on the back-burner
16:19:51 <dcavalca> as a random data point, I've occasionally sent PRs to Fedora packages for this, with... mixed outcomes
16:19:58 <Eighth_Doctor> same
16:20:04 <dcavalca> so if we had a policy saying this is desirable, that might help
16:20:07 <sgallagh> Realistically (due to high-priority stuff at RHT), he and I won't have time to refocus on that until probably the end of this summer.
16:20:21 <Eighth_Doctor> I personally don't mind RHEL conditionals in my spec files
16:20:30 <Eighth_Doctor> I already do it for pretty much everything I maintain multi-distro anyway
16:20:35 <sgallagh> Let's try not to focus too hard on that specific case.
16:20:58 <Eighth_Doctor> well, that's the only case that matters, because there is no ELN content that wouldn't make sense to also ship in Rawhide
16:21:06 <Eighth_Doctor> not even that lorax content package
16:21:06 <sgallagh> It turns out that most of the people who are firmest about not allowing that also tend more often than not to be people whose packages ELN does not ship
16:22:06 <dcavalca> let me try and frame this in a different way: is there a usecase for ELN branches that cannot be solved with conditionals in the rawhide spec?
16:22:32 <tdawson> Not that I know of
16:22:39 <Eighth_Doctor> and for the other case, is there a reasonable case where a package would only exist in ELN and not be worth at all shipping in Rawhide/Fedora?
16:22:54 <dcavalca> the only thing I can think of is maybe branding related stuff? though I'm not familiar with that at all
16:22:54 <sgallagh> Packages retired in Rawhide?
16:23:04 <tstellar_> dcavalca: What about different package versions in ELN vs rawhide?
16:23:04 <sgallagh> Branding isn't an issue for ELN vs. Fedora.
16:23:08 <tdawson> I agree with Eighth_Doctor or the lorax content package.  I don't mind it being a seperate package, but I don't see a reason it shouldn't be in Fedora proper.
16:23:09 <Eighth_Doctor> dcavalca: branding is done conditionally
16:23:12 <michel_slm> sgallagh also mentioned lorax-rhel templates
16:23:18 <michel_slm> oh, that's branding I guess
16:23:32 <sgallagh> It's not actually branding, it's defining the repo layour
16:23:35 <sgallagh> *layout
16:23:42 <dcavalca> sgallagh: are retired packages common? my gut feeling there is that they should be unretired and maintained in rawhide
16:23:54 <Eighth_Doctor> yeah, if they're going to be needed, they shouldn't be retired
16:23:57 <dcavalca> tdawson: good point, different versions would require a separate branch
16:24:04 <Eighth_Doctor> otherwise we've got a serious flaw here
16:24:18 <sgallagh> dcavalca: The example I had of that in the thread (that side-tracked things, unfortunately) was Firefox
16:24:33 <sgallagh> ELN might want to ship the LTS version of it instead of the latest like Fedora.
16:24:44 <sgallagh> So that the maintainer doesn't have to downgrade it after the inheritance breaks
16:24:48 <Eighth_Doctor> sgallagh: so IMO, we should be tracking latest firefox in ELN because we don't know _which_ LTS version it will be at branching time
16:24:52 <michel_slm> sgallagh: is there an option of just calling it 'firefox-esr'
16:24:55 <michel_slm> and also shipping it in Fedora?
16:25:07 <Eighth_Doctor> but yeah, shipping firefox-esr in Fedora is also perfectly fine
16:25:20 <dcavalca> yeah, my hunch is that the easiest solution there is to make this a separate package
16:25:22 <sgallagh> Everything is an option :)
16:25:23 <dcavalca> and have it in rawhide
16:25:30 <Eighth_Doctor> sgallagh: another way to resolve the issue is to exclude firefox from inheritance at branching
16:25:38 <Eighth_Doctor> and deal with it manually
16:25:44 <dcavalca> it doesn't need to be shipped to a tagged fedora release if the maintainer doesn't want to, but there's no harm in keeping it in rawhide
16:25:45 <sgallagh> A rename adds a slight complexity related to syncing to CentOS Stream, but that's not the first such case
16:25:45 <Eighth_Doctor> you already do that for fedora-release packages
16:26:07 <sgallagh> In fact, I think we did that for Firefox also
16:26:13 * Eighth_Doctor stares into the soul of qemu-kvm package
16:26:17 <dcavalca> (or a module stream, I guess, if the maintainer wants to go down that rabbit hole)
16:26:20 <sgallagh> I was hoping to avoid that for EL 10
16:26:20 <michel_slm> right, but.. the Stream package can also be called firefox-esr
16:26:30 <michel_slm> and maybe make it conditionally Provide firefox (if not on fedora)
16:26:42 <sgallagh> We don't need to get into the technical details there.
16:26:43 <dcavalca> and have a gated Provides: for firefox on EL if we need to keep the other name
16:26:49 <Eighth_Doctor> yup
16:26:52 * michel_slm tried to look at qemu-kvm yesterday, oof
16:27:09 <sgallagh> Eighth_Doctor: Be careful. Stare too long into the abyss...
16:27:11 <Eighth_Doctor> in any case, sgallagh, I think it would help if we had a concrete list of cases where we need solutions for
16:27:30 <dcavalca> yeah, I think examples here are good to make sure everybody understands the problem scope
16:27:32 <Eighth_Doctor> because it might be we can still continue to avoid eln branches
16:27:44 <Eighth_Doctor> and I would really prefer to keep it that way
16:27:51 <dcavalca> so far, my impression is that we probably don't need ELN branches
16:27:59 <sgallagh> One thing I need to point out: we're very much focusing on what is *technically* possible.
16:28:05 <dcavalca> outside of maybe a handful of exceptions, which we could probably hand manage
16:28:11 <sgallagh> And on that point, I agree: basically all of it is solvable.
16:28:37 <Eighth_Doctor> sgallagh: well, I don't know of a thing that isn't feasible to handle with the "normal" process
16:28:47 <sgallagh> But no matter how much logical sense it might make to us, not all Fedora maintainers are open to things like conditionals.
16:28:52 <tstellar_> I think the version differences could be more common close to ELN -> RHEL synch points.  e.g. I want to update my package in rawhide, but want the new package in RHEL10Beta but not RHEL10Alpha.
16:29:50 <sgallagh> So, the part of the discussion I was trying to start and that never happened in the email thread was this:
16:30:16 <sgallagh> I wanted us to establish a process in the SIG for how we make decisions on when a package should have an eln branch instead of using Rawhide.
16:30:42 <sgallagh> And by extension, what we need to do to make sure that information is kept somewhere that it can be referenced properly when doing sync activities.
16:30:46 <sgallagh> So we don't lose track of things.
16:31:33 <michel_slm> that can be done in stages, right? at the beginning it can be ad-hoc so we just need to discuss the "how", if we can't nail down exactly what cases we need a separate branch for just yet (the "what")
16:31:37 <dcavalca> sgallagh: process-wise, filing a ticket to get a branch so we can discuss it seems reasonable
16:31:55 <dcavalca> but IMO, the maintainer saying "I don't like conditionals" should not be an acceptable reason for a branch
16:32:15 <dcavalca> tdawson's example sounds like a reasonable usecase for a branch
16:32:28 <sgallagh> Remember that most Fedora maintainers are volunteers.
16:32:50 <sgallagh> I don't want us getting into a position where we're essentially causing people to orphan all their packages and leave the Project.
16:33:05 <michel_slm> we seem to have some employees chomping at the bits to prune the ELN/RHEL packages of dependencies too
16:33:12 <dcavalca> sgallagh: definitely not, of course
16:33:31 <dcavalca> but if a maintainer is unwilling to consider a PR adding five lines of conditionals to their spec, IMO that's a problem
16:33:33 <sgallagh> michel_slm: And that's definitely a place that ELN has value
16:33:51 <tstellar_> I think it's important to respect maintainers preferences when it comes to conditionals.  It may be inconvenient, but we don't want to enter people to start feeling like "Red Hat is forcing me too do things..."
16:34:01 <dcavalca> obviously, this shouldn't be framed as "we expect maintainers to add conditionals and keep RHEL working"
16:34:16 <sgallagh> dcavalca: It is a problem that I can tell you unequivocally I have seen happen more times than I can count on both hands and feet :-(
16:34:18 <michel_slm> Miro raised a good point on what happened if the maintainer changes and now is happy with conditionals though
16:34:27 <michel_slm> so... when/how to branch, and when/how to de-branch
16:34:33 <sgallagh> tstellar_++
16:34:43 <dcavalca> michel_slm: is de-branch even a thing? I thought branches could never be removed
16:35:05 <sgallagh> They cannot be removed, but we can switch back to rebuilding from Rawhide
16:35:11 <michel_slm> dcavalca: I guess effective debranching, in that ELN stops using its branch for that package
16:35:14 <michel_slm> yeah
16:35:15 <dcavalca> ah, got it
16:35:20 <sgallagh> See the devel thread between Miro and I
16:35:24 <cyberpear> if we have eln branches, I think the should be like eln10 so that once eln11 comes around we can re-target the rawhide branch without merging ELN branch into rawhide
16:35:50 <sgallagh> cyberpear: I cover that case in the devel thread, actually
16:35:56 <michel_slm> on responsibility... I suppose there needs to be a "Fedora maintainers don't need to care about what's in the %rhel ifdefs", and explicitly clarify they are not responsible to keep the ELN builds alive?
16:36:15 <sgallagh> I essentially proposed that ALL eln branches should get switched back to Rawhide at each EL++
16:36:29 <dcavalca> michel_slm: yeah, we definitely need clarity of communication there regardless of the technical solution we settle on
16:36:37 <sgallagh> Agreed
16:37:08 <sgallagh> Though let's aim for "Not responsible for keeping them building, but it's REALLY appreciated"
16:37:17 <sgallagh> Lest we end up constantly baby-sitting too many packages.
16:37:18 <dcavalca> sgallagh: by switching back, you mean rebased onto rawhide, or that the package starts building from rawhide and ignores the eln branch unless it's requested again?
16:37:25 <sgallagh> The latter
16:37:41 <dcavalca> ok, so we'd essentially start from scratch on every cycle
16:37:44 <michel_slm> sgallagh: give Fedora maintainers cookies for fixing ELN builds ;)
16:37:54 <dcavalca> I like that as it limits the opportunity for cruft
16:38:03 <sgallagh> My thoughts exactly
16:38:06 <dcavalca> michel_slm: we need another "corporate drone"-style badge :)
16:38:09 <michel_slm> agreed on just starting from scratch. otherwise we'll diverge over time
16:38:24 <sgallagh> dcavalca: (Small bit of trivia: I created that badge series :-D )
16:38:40 <tdawson> +1 to rebase back to rawhide
16:38:56 <sgallagh> tdawson: Let's avoid the use of the word rebase
16:38:59 <dcavalca> sgallagh: that's awesome, I was thoroughly entertained when I got the first one after pushing an update to EPEL
16:39:07 <sgallagh> It's got too many git-centric connotations
16:39:07 <dcavalca> yeah, agreed
16:39:14 <Eighth_Doctor> if we do eln branches (which I really don't want to do), they need to be versioned
16:39:38 <sgallagh> Eighth_Doctor: Can you explain what value you see in that?
16:39:52 <Eighth_Doctor> makes it easy to reset and archive them
16:40:07 <dcavalca> I think if we have a policy strongly encouraging people to prefer conditionals (but not mandating it) + we kill eln brances on every release, that might be an acceptable compromise
16:40:14 <Eighth_Doctor> yeah
16:40:25 <dcavalca> I tend to agree with Eighth_Doctor that making them versioned would probably be better
16:40:32 <Eighth_Doctor> I want eln branches to be painful to encourage people to conditionals instead
16:40:41 <dcavalca> ^^ yes, this, basically :)
16:40:43 <sgallagh> That's a fair point.
16:41:01 <sgallagh> So, let me actually put out some proposals for us to vote on
16:41:05 <sgallagh> (For formal agreement)
16:41:09 <Eighth_Doctor> 👍️
16:41:41 <michel_slm> versioning also makes it less confusing the next time the package needs to be branched (heaven forbid)
16:41:49 <michel_slm> we don't end up with a branch already full of content
16:42:00 <sgallagh> #info Proposal: The ELN SIG strongly prefers the use of specfile conditionals over the use of an 'eln' branch for packages.
16:42:10 <sgallagh> (One proposal at a time)
16:42:12 <michel_slm> +1
16:42:14 <sgallagh> +1
16:42:14 <dcavalca> +1
16:42:20 <tstellar_> +1
16:42:24 <tdawson> +1
16:43:11 <sgallagh> I'm counting Eighth_Doctor as +1 based on earlier statements
16:43:15 <sgallagh> #agreed The ELN SIG strongly prefers the use of specfile conditionals over the use of an 'eln' branch for packages. (+6, 0, -0)
16:43:16 <Eighth_Doctor> +1
16:44:42 <sgallagh> #info Proposal: The ELN SIG will establish a process to request the use of an 'eln' branch, including how such requests are approved or rejected.
16:45:25 <michel_slm> +1
16:45:27 <sgallagh> +1
16:45:30 <tdawson> +1
16:46:04 <dcavalca> +1, though we should clarify if it's "an eln branch" or "per version eln branches"
16:46:15 <sgallagh> dcavalca: That will be in the next proposal :)
16:46:21 <dcavalca> works for me
16:46:29 <tstellar_> +1
16:47:13 <Eighth_Doctor> +1
16:47:19 <sgallagh> #agreed Proposal: The ELN SIG will establish a process to request the use of an 'eln' branch, including how such requests are approved or rejected. (+6, 0, -0)
16:47:20 <Eighth_Doctor> with versioned branch caveat
16:48:32 <sgallagh> #info proposal Approved ELN branches will be versioned to the EL release and will reset to Rawhide when the associated CentOS Stream becomes available.
16:48:45 <sgallagh> (Anyone want to wordsmith that? I couldn't get it to sound right)
16:49:10 <tstellar_> sgallagh: If we have versioned branches do they really need to be reset?
16:49:37 <tstellar_> Or does that mean ELN will switch back to building from rawhide?
16:49:46 <sgallagh> Yes, because we'll need to update the auto-rebuild config
16:50:07 <dcavalca> "Approved ELN branches will be versioned to the EL release and lifecycled with it; the package will reset to building from Rawhide when the next CentOS Stream cycle becomes available" maybe?
16:50:08 <sgallagh> And if they want to diverge again, they'll need to request a new versioned branch
16:50:34 <tstellar_> dcavalca: Yeah, I think this is more clear.
16:50:39 <sgallagh> dcavalca: I like that version, thanks.
16:50:49 <tdawson> Approved ELN branches will be versioned to the RHEL release ELN is currently set to.  When ELN resets to the next RHEL release, all ELN branches will have to be reviewed, and if passed, branched into the new associated branch.
16:51:22 <tdawson> not associated, versioned
16:51:35 <dcavalca> tdawson: I don't know if we want to talk about re-reviewing at this stage
16:51:51 <dcavalca> might be better to punt that until we have a better idea of the actual process we'll use
16:51:55 <tdawson> OK, if we aren't going to re-review, then yours is better.
16:52:11 <sgallagh> #undo
16:52:11 <zodbot> Removing item from minutes: INFO by sgallagh at 16:48:32 : proposal Approved ELN branches will be versioned to the EL release and will reset to Rawhide when the associated CentOS Stream becomes available.
16:52:13 <michel_slm> yeah. and if we drop by default and the maintainer wants to bring back, that's in effect a re-review anyway, right?
16:52:19 <tdawson> Correct
16:52:27 <sgallagh> #info Proposal: Approved ELN branches will be versioned to the EL release and lifecycled with it; the package will reset to building from Rawhide when the next CentOS Stream cycle becomes available.
16:52:29 <sgallagh> +1
16:52:34 <dcavalca> +1
16:52:36 <michel_slm> +1
16:52:37 <tdawson> +1
16:52:39 <tstellar_> +1
16:53:04 <sgallagh> Eighth_Doctor: ?
16:53:36 <sgallagh> #agreed: Approved ELN branches will be versioned to the EL release and lifecycled with it; the package will reset to building from Rawhide when the next CentOS Stream cycle becomes available. (+5, 0, -0)
16:53:37 <Eighth_Doctor> +1
16:53:40 <sgallagh> #undo
16:53:40 <zodbot> Removing item from minutes: AGREED by sgallagh at 16:53:36 : : Approved ELN branches will be versioned to the EL release and lifecycled with it; the package will reset to building from Rawhide when the next CentOS Stream cycle becomes available. (+5, 0, -0)
16:53:44 <sgallagh> #agreed: Approved ELN branches will be versioned to the EL release and lifecycled with it; the package will reset to building from Rawhide when the next CentOS Stream cycle becomes available. (+6, 0, -0)
16:54:06 <sgallagh> OK, that covers the proposals, next up: volunteers!
16:54:29 <sgallagh> Does anyone want to take a stab at a first draft of the branch-request policy?
16:55:45 <sgallagh> OK, I guess that means me.
16:55:48 <dcavalca> sgallagh: I can give it a shot, but if we have an example of similar documents that would be useful
16:56:48 <sgallagh> dcavalca: I figure we'd make it relatively lightweight: create an issue template on the ELN tracker, list some valid and explicitly invalid reasons to provide guidance and then decide by meeting vote.
16:57:35 <dcavalca> sgallagh: yeah that seems reasonable
16:57:51 <sgallagh> If you could do a first-draft, we can collaborate on the wording and examples at the next meeting.
16:57:58 <dcavalca> sounds good
16:58:07 <sgallagh> Thank you
16:58:26 <sgallagh> #action dcavalca will create a first draft of the policy to request ELN branches
16:58:38 <sgallagh> #topic Open Floor
16:58:50 <sgallagh> We have two minutes left for other topics.
16:59:15 <sgallagh> I think we used the hour quite productively this time around.
16:59:23 <dcavalca> yep, this was a good meeting
17:00:13 <sgallagh> #endmeeting