16:00:58 <sgallagh> #startmeeting ELN (2023-09-08)
16:00:58 <zodbot> Meeting started Fri Sep 22 16:00:58 2023 UTC.
16:00:58 <zodbot> This meeting is logged and archived in a public location.
16:00:58 <zodbot> The chair is sgallagh. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:58 <zodbot> The meeting name has been set to 'eln_(2023-09-08)'
16:00:59 <sgallagh> #meetingname eln
16:00:59 <zodbot> The meeting name has been set to 'eln'
16:00:59 <sgallagh> #topic Init Process
16:01:05 <yselkowitz> .hi
16:01:07 <zodbot> yselkowitz: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
16:01:07 <sgallagh> .hi
16:01:10 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:01:24 <dcavalca> .hi
16:01:25 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <davide@cavalca.name>
16:03:55 <tdawson> Howdy
16:04:23 <sgallagh> Greetings, folks. I'm just going to wait a couple more minutes for people to filter in, since we're going to be discussing policy today.
16:06:17 <sgallagh> OK, I guess we should get started.
16:06:23 <sgallagh> #topic ELN Packaging Policies
16:07:11 <sgallagh> It has become clear that we need to formalize the packaging policies that ELN will be following, since we've been running up against some friction lately.
16:07:34 <sgallagh> Enough that it has been escalated to FESCo to resolve.
16:08:14 <sgallagh> I agreed that we need to formally document our policies (and FESCo will probably review them as well) so that we can at least point to them when disagreements arise.
16:08:55 <sgallagh> So I'm going to start this at a high-level and we can drill down into specific cases from there.
16:09:52 <Son_Goku> .hello ngompa
16:09:53 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:10:59 <sgallagh> Proposal 1: Fedora ELN will follow all published Fedora Packaging Guidelines, except where explicitly documented otherwise.
16:11:28 <sgallagh> We can talk about the exceptions if and when this first proposal is approved.
16:12:16 <yselkowitz> ugh
16:12:18 <sgallagh> Proposal 1 is modeled after EPEL (and RHEL, internally) where most packaging rules are just pointers to the upstream Fedora policy.
16:12:55 <dcavalca> I might have missed previous discussions on this but... was _not_ following the guidelines even an option?
16:13:17 <sgallagh> dcavalca: Left unstated, it has been ambiguous.
16:13:25 <dcavalca> the vast majority of ELN content is unmodified imports from Fedora, it seems reasonable to follow as closely as possible
16:15:33 <sgallagh> dcavalca: Right, I don't think there's anything controversial about the unmodified packages. Things get more fuzzy when we have packages that have ELN/RHEL-specific changes.
16:16:18 <dcavalca> yeah, that's fair
16:16:32 <dcavalca> anyway, I'm +1 on this in case it wasn't clear
16:16:47 <sgallagh> #info Proposal 1: Fedora ELN will follow all published Fedora Packaging Guidelines, except where explicitly documented otherwise.
16:17:09 <yselkowitz> *generally follow
16:17:24 <sgallagh> yselkowitz Can you elaborate?
16:17:47 <sgallagh> I think that weakens the statement considerably, so I'd like to know what you are thinking.
16:18:35 <yselkowitz> do you want to have a meeting every single time I need to modify a package?
16:19:08 <Son_Goku> +1
16:19:16 <dcavalca> if ELN has broad deviations from the guidelines, then yeah I think we should discuss those
16:19:21 <Son_Goku> yselkowitz: yes, actually
16:19:23 <yselkowitz> we need to focus on where ELN differs from Fedora, and focus on making these differences clear
16:19:25 <dcavalca> but obviously in the general sense, not on a package-by-package basis
16:19:25 <sgallagh> yselkowitz If your modifications don't mesh with Fedora policy or one of the exceptions we'll carve out, I think "yes"
16:19:49 <Son_Goku> I would like to avoid so-called "weasel-words" if we can
16:20:01 <dcavalca> this has the added benefit of clearly documenting how ELN is different (and thus how RHEL is different) as a byproduct
16:20:01 <Son_Goku> because a big part of doing this is repairing the relationship between RHEL-devel and Fedora contributors
16:20:58 <Son_Goku> it's also obvious to most people that these things are "generally" anyway, but significant deviations are important to capture for all kinds of useful reasons
16:21:09 <sgallagh> Son_Goku: I won't guarantee a lack of "weasel-words" in the exceptions, if appropriate.
16:21:20 <sgallagh> But they'll have to be justified to be approved :)
16:21:30 <Son_Goku> not the least of which is that one of the larger problems RHEL has is a lack of understanding of the tech debt it incurs when it forks from Fedora
16:21:54 <Son_Goku> IMO, we want to capture that and reduce that over time
16:22:14 <yselkowitz> that's what i've been trying to reduce
16:22:37 <Son_Goku> I know
16:22:43 <sgallagh> Yes, and I think that's one of the major benefits to Fedora of ELN.
16:22:45 <Son_Goku> but we don't have anything to prove it
16:23:05 <yselkowitz> to prove the benefits?  content resolver
16:23:12 <Son_Goku> ehhhhhh
16:23:32 <Son_Goku> I'm going to leave that aside for another topic someday
16:23:41 <sgallagh> yselkowitz That proves when changes impact the dependency chain, but that's not the end of all things.
16:23:59 <sgallagh> But it's definitely a measurable outcome
16:24:07 <yselkowitz> anyway, can we focus on outlining where we can/should differ?
16:24:09 <dcavalca> example: RHEL has a preference for vendoring rust packages, which is a major deviation from Fedora; this should be clearly documented, ideally with attached reasoning
16:24:29 <Son_Goku> same with Go
16:24:42 <Son_Goku> but one side-effect that has been painful for everyone is the method in which this is done
16:24:43 <sgallagh> dcavalca: Right, vendoring in general is on my list of Exceptions to cover today
16:25:04 <dcavalca> it gives us something to point at if people ask, and it makes it a lot easier to have future discussion around whether it should be revisited in the next releases
16:25:08 <Son_Goku> rationalizing the method to be compatible between the two communities is something we need to tackle for tech debt reduction
16:25:23 <dcavalca> (didn't mean to open a can of worms with vendoring right now to be clear, it was just an example that came to mind)
16:25:42 <sgallagh> Son_Goku: I don't disagree, but I think we should tackle that as a separate topic at a future meeting.
16:25:46 <Son_Goku> sure
16:25:58 <sgallagh> Far too easy to get into the weeds with that
16:26:04 <Son_Goku> but this is a point of how the content resolver isn't an outcome for Fedora
16:26:25 <Son_Goku> and why we need policy to steer things in the right direction
16:26:46 <sgallagh> That's a fair point: we need to capture in our documentation what the benefits are for Fedora, not just CentOS Stream and RHEL.
16:26:48 <dcavalca> yselkowitz: I would say in general we "can" differ on anything technical, as long as the reasoning is sound and it gets approved; we "should" however try to differ as little as possible IMO
16:26:50 <Son_Goku> because from a Fedora community perspective, it's just the what, it's the how and why
16:27:11 <Son_Goku> s/just/not just/
16:27:16 <sgallagh> dcavalca: I don't agree with that exactly.
16:27:30 <sgallagh> Hence Proposal 1.
16:27:47 <Son_Goku> sgallagh: I don't think Proposal 1 disagrees with that
16:27:49 <sgallagh> Technical deviations should need to follow explicit rules that we lay out.
16:28:01 <Son_Goku> Proposal 1 is a rule that has no process
16:28:19 <Son_Goku> dcavalca is stating that we will need a process to implement the rule
16:28:33 <Son_Goku> otherwise the rule is not effective
16:28:39 <dcavalca> Son_Goku: my assumption was that process would come via Proposal 2+
16:28:42 <sgallagh> Son_Goku: Maybe I misinterpreted, but "in general we "can" differ on anything technical" conflicts
16:29:21 <sgallagh> I'm not sure I follow you
16:29:21 <Son_Goku> I would interpret this as a difference between CAN and SHOULD
16:29:39 <sgallagh> I try never to use the word SHOULD in a policy document.
16:29:54 <sgallagh> I generally try to limit myself to MUST and MAY
16:30:01 <Son_Goku> I agree, but I'm just stating how I interpret what he's saying
16:30:08 <dcavalca> sgallagh: what I meant to say was that, apart from legal stuff, this doesn't _prevent_ ELN from deviating, as long as due process is followed, but that I would like us to adopt a "north start" of deviating at little as possible
16:30:22 <dcavalca> I suspect we're all in agreement here, it's just that language is hard, even more so over text
16:30:28 <sgallagh> Fair enough.
16:30:57 <sgallagh> Son_Goku: I'm not sure I understand what you mean about "process" though.
16:31:23 <sgallagh> Are you asking "What's the process for establishing exceptions?"
16:31:26 <Son_Goku> yes
16:31:29 <Son_Goku> and reviewing them
16:31:38 <sgallagh> OK, now I'm following.
16:31:45 <yselkowitz> half past already, and we're still discussing the header paragraph.  I suggest we table that and focus on documenting the differences.  otherwise I'm -1 at this time as it's too restricting this early on.
16:31:45 <dcavalca> if we say ELN can have exceptions, we need to establish how those exceptions are defined, who approves them, etc.
16:31:45 <Son_Goku> and tracking them, most importantly
16:32:42 <sgallagh> Son_Goku: Should I read "tracking" as "publishing", or did you mean something else?
16:33:09 <dcavalca> publishing, but also ideally revisiting these every cycle or so to make sure they're still relevant
16:33:12 <Son_Goku> yes
16:33:17 <Son_Goku> what dcavalca said
16:33:44 <Son_Goku> I've encountered broken stuff in the past because of forgotten stuff like this
16:34:24 <sgallagh> Proposal 2: Exceptions will be decided on by a majority vote of ELN SIG members at a regularly-scheduled ELN SIG meeting comprised of a quorum of at least five members.
16:34:39 <Son_Goku> +1
16:34:47 <yselkowitz> who are even the members?
16:34:58 <yselkowitz> do we have a formal membership?
16:35:12 <Son_Goku> I assume it's this list right now: https://github.com/orgs/fedora-eln/people
16:35:22 <Son_Goku> we should probably sync this into docs.fp.o if it isn't there already
16:35:39 <dcavalca> yeah, I also assumed it was the github org membership
16:35:44 <sgallagh> That's supposed to be the list, indeed. It's out of date though.
16:35:48 <sgallagh> That's on me
16:35:53 <tdawson> It is currently not in the docs
16:36:01 <yselkowitz> three of those people I haven't seen any activity wrt ELN
16:36:06 <sgallagh> tdawson It actually is
16:36:15 <sgallagh> Second paragraph on https://docs.fedoraproject.org/en-US/eln/sig/
16:36:43 <tdawson> Ohh ... ok.  I was expecting the list to be there and missed that.
16:36:53 <dcavalca> oh good, we already have an actual membership policy spelled out there, that was going to be my next question
16:37:05 <dcavalca> in that case I'm +1 on this
16:37:18 <sgallagh> Like I said, it's out of date because you and Yaakov are not on it. I'll fix that post-meeting
16:37:25 <tdawson> +1 from me too
16:37:27 <sgallagh> (If you could send me your github account names, please)
16:37:33 <yselkowitz> yselkowitz
16:38:10 <yselkowitz> and looks like Davide is listed there
16:38:22 <sgallagh> Oh, I missed that somehow.
16:38:41 <yselkowitz> oh and now I can see the private members too
16:38:59 <dcavalca> there are private members?
16:39:08 <sgallagh> I don't know what's up with that.
16:39:13 <sgallagh> I assume it's self-service
16:39:14 * dcavalca goes to login on github to check :)
16:39:32 <sgallagh> You're public
16:39:43 <dcavalca> oh I see now
16:39:52 <dcavalca> I think it's a per-user setting in their github profile
16:39:57 * yselkowitz thinks the membership needs to be cleaned up any policies built around determining membership before anything can be dependent on membership
16:39:59 <dcavalca> I remember having to mess with this for some of the meta orgs
16:40:13 <sgallagh> #info Proposal 2: Exceptions will be decided on by a majority vote of ELN SIG members at a regularly-scheduled ELN SIG meeting comprised of a quorum of at least five members.
16:41:00 <yselkowitz> -1 at this time, per my comment above
16:41:25 <dcavalca> sgallagh: we probably want to actually put the membership list on docs.fpo.org or it'll be very confusing with this public/private thing
16:42:11 <Son_Goku> dcavalca: agreed
16:42:46 <sgallagh> I hate maintaining duplicate lists...
16:42:50 <sgallagh> But I can do that if needed
16:42:51 <dcavalca> yselkowitz: is your concern that some of the members that could vote haven't actually been involved, or that people that are involved aren't in the members list and wouldn't be represented fairly?
16:43:54 <yselkowitz> from a pure process point, we can't have something dependent on a membership that isn't itself properly defined, otherwise the next question will be how that is determined etc.
16:44:05 <sgallagh> #info Proposal 3: Members who have not attended a regularly-scheduled ELN SIG meeting in six months or more will be removed as active members. They may re-request membership following the normal process.
16:44:43 <yselkowitz> are we discussing packaging policies or SIG policies?
16:45:33 <sgallagh> yselkowitz: From what I'm reading, you just made the former contingent on the latter, so...
16:47:48 <Son_Goku> sgallagh: is there something to discuss within a six month timeframe outside of the burst up for a RHEL release?
16:48:45 <Son_Goku> not that I have a problem with the rule per se, but if we don't have much going on, then naturally attendance will be lower
16:48:47 <sgallagh> Son_Goku: I try to put together an agenda for most of the biweekly meetings. Occasionally they're just status updates, but I expect they will become more procedural, particularly if Proposal 2 passes
16:48:55 <Son_Goku> okay
16:48:57 <Son_Goku> +1
16:48:58 <yselkowitz> six months?  I've been working on ELN for 9+ months and there's still a ton to do before c10s branches together with f40
16:49:38 <sgallagh> And the second half of Proposal 3 gives people ample opportunity to revive their membership
16:49:41 <dcavalca> yeah, this seems reasonable; I've been tracking ELN for a while now and interesting things come up fairly often, I don't think we'll run out of topics to discuss anytime soon :)
16:49:41 <Son_Goku> yselkowitz: my experience has been that ELN livens up only in the lead up to a new CentOS Stream release
16:49:56 <Son_Goku> now that may change :)
16:50:04 <yselkowitz> it already has imo
16:50:17 <sgallagh> Son_Goku: ELN is perpetually in the lead-up to a new Stream release :)
16:50:31 <dcavalca> +1 for the record
16:50:40 <Son_Goku> sgallagh: you know what I mean :P
16:50:42 <tdawson> Let's just go with six months and see what happens.  +1
16:50:47 <sgallagh> Our Mission is to eventually get to the point where a new Stream could be launched at no more than a week's notice.
16:51:20 * yselkowitz is glad I wasn't drinking anything when you wrote that
16:51:28 <sgallagh> hahahaha
16:52:08 <sgallagh> OK, I've got +4 for Proposal 3. yselkowitz do you want to vote?
16:52:09 <tdawson> Well ... Other than getting the CentOS Stream stuff setup ... I think it's still a fairly valid thing.
16:52:22 * Son_Goku did choke on his water when he read that
16:52:35 <sgallagh> It's a long-term goal, but each release gets closer.
16:53:00 <dcavalca> I think it's an excellent goal fwiw
16:53:17 <Son_Goku> Indeed!
16:53:18 * yselkowitz abstains
16:53:24 <sgallagh> #agreed Proposal 3: Members who have not attended a regularly-scheduled ELN SIG meeting in six months or more will be removed as active members. They may re-request membership following the normal process. (+4, 1, -0)
16:53:26 <Son_Goku> shoot for the moon!
16:54:28 <yselkowitz> ftr I can't make this slot for the next two weeks.  the main question here is this policy going to help reinforce my ability to do my work on ELN or tie my hands.  I guess you all will have to decide that without me. /shrugs
16:55:01 <sgallagh> I count (+4, 0, -1) for P2. Is that still accurate?
16:55:19 <sgallagh> We only meet biweekly, so you'd only miss one.
16:55:44 <sgallagh> Let's get P1 and P2 voted on, then I'll quickly raise a couple Exceptions I have in mind.
16:55:57 <Son_Goku> that sounds right
16:56:15 <Son_Goku> uhh
16:56:19 <sgallagh> I realize we're short on time; if I try to keep this moving, can any of you hang around a little past the hour?
16:56:23 <sgallagh> I realize we're short on time; if I try to keep this moving, can any of you hang around a little past the hour?
16:56:26 <Son_Goku> yeah I can hang around
16:56:33 <tdawson> sure
16:56:37 <dcavalca> yeah that's fine, I need to dial in a VC meeting but I can multitask :)
16:57:16 <sgallagh> #agreed Proposal 2: Exceptions will be decided on by a majority vote of ELN SIG members at a regularly-scheduled ELN SIG meeting comprised of a quorum of at least five members.
16:57:19 <sgallagh> #undo
16:57:19 <zodbot> Removing item from minutes: AGREED by sgallagh at 16:57:16 : Proposal 2: Exceptions will be decided on by a majority vote of ELN SIG members at a regularly-scheduled ELN SIG meeting comprised of a quorum of at least five members.
16:57:30 <sgallagh> #agreed Proposal 2: Exceptions will be decided on by a majority vote of ELN SIG members at a regularly-scheduled ELN SIG meeting comprised of a quorum of at least five members. (+4, 0, -1)
16:58:17 <sgallagh> I count +3 on P1, with no vote from tdawson or yselkowitz yet
16:58:27 <tdawson> +1 from me
17:00:26 <tdawson> Although I'm giving it a +1, I do have a concern that there are several weeks that we don't have 5 people here.  But I suspect on the weeks a policy/exception come up, we'll have more.
17:00:51 <sgallagh> #agreed Proposal 1: Fedora ELN will follow all published Fedora Packaging Guidelines, except where explicitly documented otherwise. (+4, 0, 0)
17:00:56 <sgallagh> tdawson: I tend to agree.
17:01:06 <dcavalca> I was thinking the same, but otoh I think this kind of stuff does need quorum or it will look sketchy
17:01:16 <dcavalca> so 5 seems fair in the end
17:01:17 <tdawson> +1 one this one too ...
17:02:02 <sgallagh> Unfortunately, we just lost yselkowitz which means we don't have quorum to vote on the exceptions
17:02:48 <sgallagh> Unless we want to violate the policy we just created and accept the exceptions that were discussed during FESCo yesterday with just the remainder of us.
17:03:34 <sgallagh> Proposal 4: Packaging Guidelines Exception: ELN may opt to bundle content more freely than in Rawhide. If we do so, we must follow the Fedora bundling policy.
17:03:34 <sgallagh> Proposal 5: Packaging Guidelines Exception: ELN may opt to exclude (or bundle deps of) certain tests if running them would cause unwanted dependencies to end up in the RHEL content set.
17:03:41 <Son_Goku> well the policy technically doesn't exist yet until after this meeting
17:03:52 <sgallagh> These have been de-facto polices up to this point, but we never recorded them.
17:04:27 <Son_Goku> so one thing that I've observed as a bigger issue is that ELN/RHEL packages don't record licensing correctly for bundled stuff
17:04:30 <dcavalca> let's get these provisionally voted on and quickly review them on the next meeting if there's objections?
17:04:34 <tdawson> I have a +1000 on Proposal 5
17:04:52 <sgallagh> dcavalca Seems fair
17:05:00 <tdawson> Although I've heard that even my big votes only count at 1
17:05:02 <dcavalca> for proposal 5, how do we define "unwanted dependencies"?
17:05:11 <Son_Goku> can we amend proposal 4 to indicate that licensing policies need to be followed too?
17:05:21 <Son_Goku> because currently that is not clear to some folks
17:05:31 <sgallagh> Son_Goku I think that's implicit in "must follow the Fedora bundling policy"
17:05:42 <tdawson> dcavalca: I would define it as packages marked as "unwanted" in Content Resolver.
17:05:51 <Son_Goku> sgallagh: maybe we need to update the doc there to make it explicit then
17:05:55 <Son_Goku> because right now it isn't, I think?
17:06:02 <sgallagh> Son_Goku Which doc?
17:06:04 <dcavalca> tdawson: oh is there an explicit workload with those?
17:06:06 <Son_Goku> bundling policy doc
17:06:17 <sgallagh> dcavalca: Yes
17:06:22 <tdawson> dcavalca: Not just one ... each group can have their own.
17:06:23 <sgallagh> Multiple workloads, actually
17:06:40 <sgallagh> Son_Goku I defer to you and the rest of FPC to resolve that :)
17:06:55 <dcavalca> oh I see, hadn't noticed that before
17:06:56 <Son_Goku> sgallagh: it's not explicit here: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/
17:07:07 <dcavalca> yeah, this is fine then, though we should probably document it somewhere
17:07:17 <Son_Goku> it is mentioned here though: https://docs.fedoraproject.org/en-US/legal/license-field/
17:07:29 <Son_Goku> that's why I want it to be clear that fedora's licensing policy needs to be followed
17:07:38 <Son_Goku> it's not obvious to some people that they need to read both when bundling
17:08:03 <sgallagh> Sure, adding a note/link into the bundling policy sounds like a good idea
17:08:15 <dcavalca> maybe the easiest here is to write a short "bundling guidelines for RHEL" doc stressing the major point and linking to the actual policies
17:08:34 <Son_Goku> sgallagh: yeah, I'll see about adding a link there
17:09:00 <sgallagh> #info Proposal 4: Packaging Guidelines Exception: ELN may opt to bundle content more freely than in Rawhide. If we do so, we must follow the Fedora bundling policy.
17:09:01 <sgallagh> #info Proposal 5: Packaging Guidelines Exception: ELN may opt to exclude (or bundle deps of) certain tests if running them would cause unwanted dependencies to end up in the RHEL content set.
17:09:40 <sgallagh> dcavalca: Since there shouldn't be any deviation, I think just fixing the Fedora doc is enough
17:09:58 <tdawson> I'm +1 for both of those with this new wording
17:09:59 <dcavalca> fair enough
17:10:20 <sgallagh> tdawson What new wording?
17:10:38 <sgallagh> I *think* we said that the phrasing I just #info-ed is sufficient
17:10:48 <sgallagh> I might have misunderstood
17:11:12 <Son_Goku> I think I'd prefer bundling test deps than disabling tests
17:11:30 <tdawson> sgallagh: Oh ... it is the same wording ... sorry, I thought you had added a few words about fedora documentation and content set ... nevermind what I said ... other than the +1
17:11:39 <Son_Goku> with RHEL's longevity and patchiness, not running tests can be a recipe for problems
17:11:50 <sgallagh> I think I'd prefer to leave that as an exercise to the packager. It may be more trouble than it's worth.
17:12:14 <Son_Goku> we do that in Fedora too, but expressing a preference is not harmful
17:12:24 <Son_Goku> and I think it would make sense to indicate that
17:12:37 <sgallagh> Son_Goku RHEL often skips tests at the RPM build phase and just moves them into a different step in the pipeline where the dependencies can be pulled in without impact to the compose.
17:12:38 <tdawson> RHEL has alot of extra tests on top of the package build testss.
17:13:03 <Son_Goku> tdawson: I don't want to go down that side tangent
17:13:09 <tdawson> Yep
17:13:12 <Son_Goku> we can talk about it later
17:13:37 <Son_Goku> needless to say, I would really rather rely on upstream validation in package tests
17:13:42 <sgallagh> #info Proposal 5v2: Packaging Guidelines Exception: ELN may opt to exclude (or preferably bundle deps of) certain tests if running them would cause unwanted dependencies to end up in the RHEL content set.
17:13:50 <Son_Goku> +1
17:14:00 <dcavalca> +1 on both 4 and 5v2
17:14:07 <sgallagh> Well, those tests still run in Fedora, but I'm not opposed to providing a recommendation here.
17:14:20 <Son_Goku> sgallagh: after forking, they're not running in Fedora anymore :)
17:14:39 <Son_Goku> and we've seen weirdness with things like compiler flag differences before
17:14:49 <Son_Goku> so I want to make sure we don't mess up accidentally
17:14:50 <sgallagh> True enough. As I said, I made the requested edit.
17:14:59 <Son_Goku> yup, and I'm satisfied
17:15:13 <tdawson> I'm +1 to 5v2 as well
17:15:13 <sgallagh> tdawson?
17:15:13 <Son_Goku> +1 to P4 and P5v2
17:15:42 <sgallagh> I'll assume his +1 carried over
17:16:20 <tdawson> Well, P4 didn't change, so I'm still +1 to it.
17:16:21 <sgallagh> #agreed Proposal 4: Packaging Guidelines Exception: ELN may opt to bundle content more freely than in Rawhide. If we do so, we must follow the Fedora bundling policy. (+4, 0, -0)#agreed Proposal 5v2: Packaging Guidelines Exception: ELN may opt to exclude (or preferably bundle deps of) certain tests if running them would cause unwanted dependencies
17:16:21 <sgallagh> to end up in the RHEL content set. (+4, 0, -0)
17:16:32 <sgallagh> #undo
17:16:32 <zodbot> Removing item from minutes: AGREED by sgallagh at 17:16:21 : Proposal 4: Packaging Guidelines Exception: ELN may opt to bundle content more freely than in Rawhide. If we do so, we must follow the Fedora bundling policy. (+4, 0, -0)#agreed Proposal 5v2: Packaging Guidelines Exception: ELN may opt to exclude (or preferably bundle deps of) certain tests if running them would cause unwanted dependencies
17:16:37 <sgallagh> #agreed Proposal 4: Packaging Guidelines Exception: ELN may opt to bundle content more freely than in Rawhide. If we do so, we must follow the Fedora bundling policy. (+4, 0, -0)
17:16:37 <sgallagh> #agreed Proposal 5v2: Packaging Guidelines Exception: ELN may opt to exclude (or preferably bundle deps of) certain tests if running them would cause unwanted dependencies to end up in the RHEL content set. (+4, 0, -0)
17:16:53 <dcavalca> we should put something in the minutes that these last two are provisionally agreeded due to missing quorum
17:18:36 <sgallagh> dcavalca: I'm going to accept Son_Goku's interpretation that the P1 policy isn't in effect until it's announced. So our standard policy of "majority of members who show up to the meeting" applies.
17:19:59 <sgallagh> OK, at this point we are well over time, so I'll close the meeting out in a moment.
17:20:51 <sgallagh> #info Additional Exceptions may be proposed by filing a ticket at https://github.com/fedora-eln/eln/issues and will be discussed at the next meeting (2023-10-06)
17:21:05 <tdawson> sgallagh: Thanks for running the meeting, and doing al the ELN stuff you do.
17:21:15 <sgallagh> Thank you everyone for one of our more fruitful meetings!
17:21:18 <sgallagh> #endmeeting