15:00:27 <contyk> #startmeeting FESCO (2020-06-15)
15:00:27 <zodbot> Meeting started Mon Jun 15 15:00:27 2020 UTC.
15:00:27 <zodbot> This meeting is logged and archived in a public location.
15:00:27 <zodbot> The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:27 <zodbot> The meeting name has been set to 'fesco_(2020-06-15)'
15:00:29 <contyk> #meetingname fesco
15:00:29 <zodbot> The meeting name has been set to 'fesco'
15:00:31 <contyk> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
15:00:31 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku contyk cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek
15:00:33 <contyk> #topic init process
15:00:33 <mhroncok> hey
15:00:36 <nirik> morning
15:00:38 <zbyszek> .hello2
15:00:38 <sgallagh> .hello2
15:00:41 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:42 <contyk> .hello psabata
15:00:43 <dcantrell> .hello2
15:00:43 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:00:46 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:48 <bcotton> .hello2
15:00:50 <decathorpe> .hello2
15:00:50 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
15:00:56 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:00 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
15:01:29 <mhroncok> .hello churchyard
15:01:30 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
15:01:34 <dcantrell> FYI everyone, I have to step away from the kbd in about 15 minutes for an end of school year thing for my daughter
15:01:50 <contyk> Well, just six people but we have a quorum.
15:01:55 <King_InuYasha> .hello ngompa
15:01:56 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
15:02:08 <contyk> Seven.
15:02:15 <contyk> #topic Welcome new FESCo members & Meeting time
15:02:30 <contyk> So, we have new members, King_InuYasha and cverna replacing bookwar and myself.
15:02:40 <contyk> There's a ticket regarding the possible new meeting time.
15:02:40 <cverna> hello
15:02:45 <contyk> .fesco 2407
15:02:46 <zodbot> contyk: Issue #2407: Is the meeting time good for the new members? - fesco - Pagure.io - https://pagure.io/fesco/issue/2407
15:03:09 <contyk> Welcome to FESCo!
15:03:09 <mhroncok> zbyszek: how's the vote?
15:03:22 <decathorpe> King_InuYasha, cverna: welcome!
15:03:25 <zbyszek> Bad.
15:03:36 <mhroncok> and waiting for dcantrell, right?
15:03:40 <zbyszek> Did everyone get the link on fesco private mailing list?
15:03:42 <sgallagh> Welcome to the dollhouse,  King_InuYasha and cverna!
15:03:43 <nirik> welcome cverna and King_InuYasha
15:03:48 <King_InuYasha> zbyszek: the what?
15:03:57 <dcantrell> King_InuYasha, cverna: welcome!
15:03:59 * mhroncok wanted to check if the list was updated...
15:04:04 * dcantrell looks at new time
15:04:05 <nirik> it's not yet.
15:04:06 <mhroncok> the list is hidden
15:04:23 <zbyszek> I didn't want to post the link publicly because it allows anyone who has the link to edit the results.
15:04:30 <ignatenkobrain> .hello2
15:04:31 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Raits' <igor.raits@gmail.com>
15:04:33 <ignatenkobrain> sorry for delay :)
15:04:42 <zbyszek> It's unlikely, but would be awkward if someone decides to troll.
15:04:52 * nirik can adjust the list now
15:04:59 <zbyszek> King_InuYasha, cverna: welcome!
15:05:13 <bookwar> .hello2
15:05:14 <dcantrell> not sure if I did the whenisgood thing right
15:05:18 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:05:22 <dcantrell> the current time works for me
15:05:23 <bcotton> nirik: i updated it thursday night
15:05:26 <mhroncok> zbyszek: the little red squares/numbers mean people who cannot attend that slot?
15:05:34 * bookwar just came to say hi and congrats to all new members
15:05:35 <mhroncok> bcotton: the mailing list as well?
15:05:39 <bcotton> yep
15:05:43 <mhroncok> bcotton++
15:05:48 <nirik> ah, indeed.
15:06:08 <nirik> thanks bcotton
15:06:16 <bcotton> happy to help :-)
15:06:16 <mhroncok> King_InuYasha actually replied there, so that's a confirmation
15:06:26 <King_InuYasha> I did?
15:06:50 <mhroncok> King_InuYasha: "What timezone are those results in?"
15:06:54 <King_InuYasha> Oh!
15:07:00 <King_InuYasha> that was a private list?
15:07:05 <mhroncok> :)
15:07:10 <mhroncok> indeed
15:07:13 <King_InuYasha> huh, I wondered why I replied with @fp.o email
15:07:15 <contyk> So private you didn't even notice.
15:07:23 <mhroncok> a ninja list
15:07:24 <zbyszek> dcantrell: well, it is "good" in the sense that it is an answer. But it's unlikely that we agree on a time before early afternoon CEST because we have people in USA.
15:07:25 <sgallagh> Double-secret list
15:07:26 <King_InuYasha> no, I just have too many mailing lists and subscriptions :D
15:07:37 <cverna> :D
15:08:14 <dcantrell> oh I didn't change the timezone on the whenisgood thing
15:08:15 <dcantrell> ugh
15:08:18 <zbyszek> mhroncok: yes, the dots show the number of people who *can't* at the given time.
15:08:32 <mhroncok> :)
15:08:48 <contyk> So do you have enough data to pick a new slot for this meeting now?
15:08:48 * nirik changed it to his timezone for his submission, hopefully it did it right.
15:08:51 <King_InuYasha> that was confusing when I first looked at it
15:09:02 <sgallagh> Yeah, my timezone should be correct also
15:09:04 <ignatenkobrain> the interface could be better, yeah
15:09:10 <dcantrell> ok, I submitted a new one because I don't have the "update your response" link from my first submission
15:09:15 <sgallagh> It's very Web 1.0
15:09:22 <King_InuYasha> indeed
15:09:53 <zbyszek> OK, does everyone have the link to the results?
15:10:05 <dcantrell> I do not
15:10:13 <mhroncok> indeed all responses have time zone set (except first dcantrell)
15:10:26 <mhroncok> dcantrell: PMed to you
15:10:44 <zbyszek> I deleted dcantrell's first reponse.
15:11:02 <zbyszek> ignatenkobrain and King_InuYasha have no common times
15:11:09 <zbyszek> cverna and dcantrell have no common times
15:11:16 <King_InuYasha> that's unfortunate
15:11:35 <ignatenkobrain> pretty sure Neal is always around when I am... at least he is online because I bug him all the day :D
15:11:57 <mhroncok> dcantrell: you said in the ticket "later in the day works for me but that does not seem ideal for Europe"
15:12:00 <zbyszek> If you mouse-over the names list, the times should show up in green.
15:12:05 <mhroncok> dcantrell: yet you filed in only 2 hours a day
15:12:05 <contyk> So I would proposed keeping this slot for another week and have another vote.
15:12:11 <ignatenkobrain> let me open that table again
15:12:17 <King_InuYasha> ignatenkobrain: I don't have to focus when you bug me :)
15:12:19 <contyk> Rather than solving it now.
15:12:19 <mhroncok> did everybody put all possible time slots in?
15:12:26 <dcantrell> I just updated mine
15:12:29 <King_InuYasha> I did
15:12:38 <King_InuYasha> even some less comfortable ones
15:12:47 <cverna> I can look again at it and update my slots
15:13:18 <cverna> But probably after this meeting since I need to look at my calendar closely
15:13:20 * nirik could try a bit earlier... but 6 or 7am meetings are anoying. not sure it helps tho...
15:13:26 <dcantrell> ok....I have to step away for some minutes
15:13:31 <mhroncok> nirik: I don't think ti would
15:13:41 <sgallagh> Proposal: Everyone votes by 23:59 UTC Wed. and we hope to find some commonality by then for next week's meeting
15:13:41 <ignatenkobrain> btw, how do I update my selection?
15:13:44 <mhroncok> 1400 and 1500 monday has the best chance
15:13:58 <sgallagh> ignatenkobrain: If you are logged in, you can find it on the main page
15:14:10 <cverna> +1
15:14:14 <mhroncok> sgallagh: +1
15:14:17 <zbyszek> ignatenkobrain: or if you go from the result page, there's a link to update under your name
15:14:22 <sgallagh> Or 1400 on Wed.
15:14:22 <ignatenkobrain> sgallagh: I'm not :/
15:14:32 <decathorpe> Igor Raits: if you're not logged in, there's probably a link to it in your browser history.
15:14:35 <King_InuYasha> I'm literally splitting this with my morning ceremonies meeting for work
15:14:47 <King_InuYasha> it's not going to work out once WFH ends for me
15:14:50 <mhroncok> 1400 wednesday as well
15:14:51 <nirik> non fri/monday is good to avoid hoilidays and people gone for long weekends. ;)
15:14:53 <King_InuYasha> if it's at 1500 UTC
15:15:31 <sgallagh> nirik, cverna: Could you make 1400 on Wed work?
15:15:41 <nirik> I could do wed at 14... thats 7am, but I could do it for others
15:16:08 * sgallagh will send you some coffee beans
15:16:10 <mhroncok> nirik: 6am in winter?
15:16:12 <cverna> Let me quickly check
15:16:34 <nirik> mhroncok: yeah.
15:16:37 <sgallagh> mhroncok: He might not win reelection again next time, so let's worry about that later :)
15:16:55 <ignatenkobrain> updated my responses
15:17:01 <cverna> So 1400 Wednesday works for me
15:17:02 <mhroncok> sgallagh: heh. we change the time slot for nonDST months
15:17:13 <zbyszek> sgallagh: I'm pretty sure they'll cancel DST first ;)
15:17:15 <sgallagh> \o/
15:17:32 <sgallagh> OK, so we have a slot, then
15:17:42 <mhroncok> now, as a courtesy for nirik...
15:17:47 <mhroncok> would 1500 not work?
15:17:50 <contyk> What's the slot?
15:18:00 <mhroncok> contyk: wed 1400
15:18:02 <King_InuYasha> mhroncok: it works on any day except Monday and Friday
15:18:06 <contyk> UTC?
15:18:09 <mhroncok> yes
15:18:12 <contyk> Okay.
15:18:33 <contyk> #info The new meeting time is Wednesday, 1400 UTC, starting June 24.
15:18:36 <cverna> Newbie question but the meeting is 1 hour, correct ?
15:18:37 <mhroncok> wed 1500 was nacked by nirik, cverna, King_InuYasha, sgallagh
15:18:43 <mhroncok> cverna: up to 2
15:18:49 <King_InuYasha> works for me
15:19:03 <sgallagh> mhroncok: I can make that work if we run long occasionally
15:19:05 <King_InuYasha> doesn't collide with Workstation WG on Tuesday :D
15:19:15 <cverna> Ok so I think nirik and I have a call wed at 1500 UTC
15:19:16 <contyk> Okay, that only took 20 minutes.
15:19:22 * King_InuYasha has meetings basically all day every day now :(
15:19:30 <nirik> oh yeah, thats right.
15:19:38 <sgallagh> King_InuYasha: Welcome to my life.
15:19:39 <contyk> So that won't work?
15:19:47 <King_InuYasha> contyk: Wed 1400 UTC works for me
15:19:53 <nirik> 14 will work, but 15 spills into that call.
15:19:57 <King_InuYasha> it fits one of the few slots I have left
15:20:00 * contyk nods.
15:20:18 <King_InuYasha> at least in the morning, that is
15:20:18 <sgallagh> So we'll have to be pickier about resolving as much as possible in tickets.
15:20:19 <cverna> How often do we need the 2 hours slot ?
15:20:23 <sgallagh> Can we all commit to that?
15:20:32 <nirik> the only times we usually run that long is when there's a ton of features. Perhaps we could resolve more in ticket or do a special session
15:20:33 <contyk> From time to time.
15:20:34 <ignatenkobrain> Wed 1400 UTC works for me
15:20:38 <contyk> Depends on how much we talk about modularity.
15:20:44 <nirik> ha
15:20:45 <King_InuYasha> my standup is at 11:45am EDT
15:20:46 <sgallagh> .fire contyk
15:20:46 <zodbot> adamw fires contyk
15:20:48 <cverna> Lol
15:21:07 <contyk> Great, you'll manage. Let's go to the next topic.
15:21:09 <cverna> I am +1 to wed 1400 utc
15:21:17 <contyk> #topic Council Engineering Representative
15:21:33 <sgallagh> I nominated dcantrell in the ticket.
15:21:33 <contyk> #link https://docs.fedoraproject.org/en-US/fesco/Fedora_Council_Engineering_Rep/
15:21:42 <contyk> .fesco 2405
15:21:43 <mhroncok> dcantrell: has +5
15:21:43 <zodbot> contyk: Issue #2405: New FESCo rep to Fedora Council needed - fesco - Pagure.io - https://pagure.io/fesco/issue/2405
15:21:57 <decathorpe> +1 from me as well.
15:21:59 <dcantrell> ok, I'm back
15:22:04 <contyk> The policy states the nomination should run for a week, though.
15:22:08 <nirik> +1 here too
15:22:21 * nirik can vote in ticket
15:22:37 <mhroncok> contyk: good point
15:22:39 * cverna votes in the ticket too
15:22:46 <zbyszek> dcantrell: please either vote or state that you'll recuse yourself, so we don't wait for your vote.
15:22:48 <nirik> FYI, I didn't see any of this, because this meeting is right after I got up...
15:23:07 <dcantrell> vote in 2405?
15:23:18 <zbyszek> dcantrell: yes
15:23:19 <sgallagh> If we have a unanimous vote, we can probably waive the week nomination period
15:23:29 <dcantrell> just voted
15:23:30 <contyk> Well, I'll step down from that position and you guys figure it out within the week as the policy says.
15:23:35 <zbyszek> nirik: yeah, the 14:00 meeting is going to be tough. I feel your pain.
15:24:20 <contyk> #info contyk will step down from the Council Engineering representative position; FESCo will process the nominations in #2405 over the next week.
15:24:47 <contyk> Alright, let's start with the new business, it will be quicker.
15:24:55 <contyk> #topic #2400 F34 System-Wide Change: NSS CK_GCM_PARAMS change
15:24:56 <sgallagh> Including nirik, we actually have +9
15:25:00 <contyk> .fesco 2400
15:25:01 <zodbot> contyk: Issue #2400: F34 System-Wide Change: NSS CK_GCM_PARAMS change - fesco - Pagure.io - https://pagure.io/fesco/issue/2400
15:25:02 <dcantrell> thanks, everyone, for the nomination on 2405.  mhroncok, I responded to your email but I think it was after sgallagh pinged me
15:25:20 <contyk> sgallagh: Yeah, but this has its own policy.
15:25:28 <sgallagh> Fair
15:25:54 <contyk> I voted in the ticket but it no longer counts.
15:26:17 <mhroncok> dcantrell: np. I wasn't sure your reply was exactly "yes" :)
15:26:30 <dcantrell> mhroncok: it was a "before coffee" yes  :)
15:26:54 <sgallagh> I can answer Bob's question in the ticket
15:27:30 <sgallagh> Give me a minute and I'll actually do it for him.
15:27:31 <dcantrell> re: 2400, why is this a change proposal if it doesn't break backwards compatibility and doesn't require a rebuild of packages built against older NSS versions?
15:27:45 <nirik> I guess I'm +1 here...
15:27:59 <mhroncok> dcantrell: changes don't need to bre always breaking :)
15:28:02 * zbyszek finds the Change proposal unusally hard to read.
15:28:02 <nirik> dcantrell: I guess to raise awareness for things that build against it that are out of tree?
15:28:16 <dcantrell> both reasonable points
15:28:38 <decathorpe> so, do we defer a decision until we have a list of affected packages?
15:28:39 <dcantrell> I guess with that, what are the drawbacks to taking the newer NSS?
15:28:57 * mhroncok was waiting for the concerns zbyszek had on the devel list to be resolved
15:29:07 <zbyszek> Hmm, is there someone who knows the change owner and could work with them on the text?
15:29:14 <sgallagh> It doesn't require a rebuild, but it will break rebuilds
15:29:37 * cverna will not vote on this one since I have read the Change proposal
15:29:45 <zbyszek> "It doesn't require a rebuild, but it will break rebuilds" — that's a much better description than anything in the page...
15:29:45 <sgallagh> It's a source-level incompatibility, but the resulting compiled binary will be ABI-compatible
15:30:00 <sgallagh> At least, that's how I'm reading it
15:30:43 <dcantrell> yes, this text could use some rephrasing
15:30:43 <sgallagh> Yeah, that's probably how this is going to play out.
15:30:45 <mhroncok> I'm -0 at this point. I don't want to oppose his, but it really needs to be described better
15:31:16 <sgallagh> There are 46 packages that BR: nss-devel
15:31:25 <sgallagh> Not an insurmountable number
15:31:40 <zbyszek> Same here. I think the change is good, but this is read by our users, and quoted by phoronix, etc, and right now it's very hard to interpret.
15:31:44 <dcantrell> I agree with mhroncok here
15:31:51 <dcantrell> I added a comment in the ticket asking for some stuff
15:31:52 <sgallagh> I added the list to the ticket
15:32:24 <contyk> So let's give it more time and let the change proposal owner rewrite it?
15:33:12 <cverna> contyk: +1
15:33:13 <sgallagh> Proposal: Ask rrelyea to rephrase the request and add details about the expected impact, particularly on rebuilds and revisit in a week
15:33:24 <zbyszek> sgallagh: +1
15:33:28 <mhroncok> sgallagh: +1
15:33:28 <ignatenkobrain> +1
15:33:35 <decathorpe> +1
15:33:35 <cverna> +1
15:33:40 <dcantrell> +1
15:33:42 <nirik> +1
15:34:38 <contyk> #agreed FESCo asks rrelyea to rephrase the request and add details about the expected impact, particularly on rebuilds and revisit in a week (+8, 0, -0)
15:34:55 <contyk> Okay; the next topic is basically three tickets.
15:35:03 <contyk> #topic What is the scope of Modularity?
15:35:08 <contyk> .fesco 2114
15:35:10 <zodbot> contyk: Issue #2114: What is the scope of Modularity? - fesco - Pagure.io - https://pagure.io/fesco/issue/2114
15:35:13 <contyk> .fesco 2390
15:35:16 <zodbot> contyk: Issue #2390: Request to permit module default streams in ELN - fesco - Pagure.io - https://pagure.io/fesco/issue/2390
15:35:17 <contyk> .fesco 2406
15:35:19 <zodbot> contyk: Issue #2406: Ban default module streams and module-only packages in Fedora - fesco - Pagure.io - https://pagure.io/fesco/issue/2406
15:35:32 <contyk> It's all fairly connected at this point.
15:35:38 <ignatenkobrain> let the party begin :)
15:35:53 <mhroncok> may I ask that we discuss the proposals in 2406 separate from the proposal in 2390?
15:35:59 <sgallagh> The conversation is active in the tickets, do we need to have it here today too?
15:36:41 <contyk> We wanted to discuss those after the Council presentation. That can definitely happen in the tickets if you all prefer.
15:36:51 <sgallagh> right...
15:36:51 <mhroncok> there is a proposal, people vote, there is a -1 vote, the discussion never ends...
15:37:03 <mhroncok> I'd rather get it sorted out eventually. do we set a deadline?
15:37:17 <sgallagh> mhroncok: Well, the proposal is always "kill off modularity", rephrased.
15:37:20 <dcantrell> I am ok with a deadline, yes.  Right now I am not caught up on the tickets.
15:37:30 <mhroncok> sgallagh: no, only on eprops
15:37:32 <mhroncok> sorry
15:37:42 <sgallagh> huh?
15:37:50 <mhroncok> sgallagh: no, only one part of the proposla effectively kills it  and that has multiple -1s
15:37:59 <sgallagh> ok
15:38:05 <mhroncok> the proposla is to kill default modular streams and modular only packages
15:38:14 <sgallagh> "Death by a thousand cuts" is much better :-/
15:38:24 <mhroncok> keep reapating that, it helps
15:38:38 <mhroncok> *repeating
15:38:45 <mhroncok> I do not wish to kill modularity
15:38:51 <mhroncok> I wish to kill default modular streams
15:39:06 <mhroncok> if modularity cannot succeed without default modular streams, so be it, but I don't agree
15:39:28 <sgallagh> I am not asking for default module streams in Fedora at this time. I'm asking for them in Fedora ELN.
15:39:43 <mhroncok> that's why I ask to discuss 2406 separate from the proposal in 2390
15:39:57 <King_InuYasha> At this point, I'm okay with granting basically everything for ELN
15:40:19 <ignatenkobrain> Let's start voting with 2406 and then get to 2390?
15:40:24 <mhroncok> ignatenkobrain: +1
15:41:00 <cverna> I read 2406 and it sounds reasonable with -1 on the last part.
15:41:17 <cverna> So that we keep the modular repo installed by default
15:41:38 * nirik doesn't really want to vote when he's not read the flurry of comments this morning.
15:41:54 <mhroncok> zbyszek: the numbering got screwed up in the initial post
15:42:36 <zbyszek> mhroncok: oops, fixed.
15:42:50 <sgallagh> I don't see the point of 2. at all
15:42:58 <zbyszek> sgallagh: it's there now.
15:43:00 <sgallagh> FESCo can always revise any ruling in the future
15:43:15 <sgallagh> No, I mean it's a meaningless proposal
15:43:31 <mhroncok> sgallagh: if it is meaningless, I wonder why block it
15:44:08 <mhroncok> apparently, it is meaningful for others
15:44:17 <decathorpe> Different question: Does point 2 doesn't actually change anything? I mean, it's already "no default streams until FESCo revises that decision"
15:44:27 <sgallagh> The phrasing is such that it sounds like it's recommending that future FESCo members should not revisit it.
15:44:48 <sgallagh> mhroncok: I just don't like the addition of the word "permanent"
15:44:59 <sgallagh> And without that, it's already equivalent to the status quo
15:45:02 <mhroncok> sgallagh: I juts don't like the word temporary
15:45:11 <ignatenkobrain> sgallagh: I think there is a confusion from people that we've banned them until some specific issues will be fixed.
15:45:24 <zbyszek> sgallagh: would you prefer "non-temporary" ?
15:45:34 <mhroncok> it has been repeatedly used in agruments, that the current ban is temporary until XYZ is fixed
15:45:43 <mhroncok> where XYZ was always changing
15:45:51 <mhroncok> once, it was the "upgrade path"
15:46:07 <zbyszek> I guess we could phrase this as "Default streams are banned in Fedora.". Would this work for sgallagh?
15:46:07 <sgallagh> It was always two things. The upgrade path and the policy around what was permissible.
15:46:10 <dcantrell> I have caught up on 2406 and added my comment
15:46:15 <sgallagh> zbyszek: I'm fine with that
15:46:36 <sgallagh> I'd slightly prefer "disallowed", but I'm not going to fight over it.
15:46:40 <dcantrell> I feel it's fine, I am +1 on all except the last point.  I do want to see some changes to the Fedora Packager guidelines and expectations around maintenance
15:46:45 <mhroncok> disallowed is fine
15:46:50 <contyk> It was the upgrade path and making the content available in the non-modular buildroot.
15:46:58 <mhroncok> contyk: no, it was not
15:47:25 <mhroncok> hence, this time, we make sure such confusion is not created
15:47:49 <sgallagh> I think we're in agreement here that we're not asking for defaults at this time.
15:47:50 <contyk> What else was it then?
15:47:54 <mhroncok> nirik: can we vote, or do you prefer to wait for the next meeting?
15:48:03 <mhroncok> contyk: a policy
15:48:04 <sgallagh> contyk: Can we take that outside the meeting?
15:48:22 <mhroncok> and we now propose a policy: no default streams
15:48:24 <zbyszek> Changed now to "Default streams are not allowed in Fedora." ("not allowed" sounds more like normal English.)
15:48:25 <contyk> Sure. I was just wondering.
15:48:36 <sgallagh> zbyszek: +1
15:48:51 <nirik> mhroncok: have been reading... I guess I can vote... could you clarify in the proposal point 4
15:49:03 <mhroncok> nirik: clarify how?
15:49:17 <mhroncok> I've basically done point 4 in https://fedoraproject.org/wiki/Changes/ModularReposSubpackage
15:49:22 <nirik> ie, make *modular*.repo optional by splitting them into a separate package and not installing that package by default
15:49:29 * mhroncok still waits for bcotton to announce it
15:49:42 <sgallagh> nirik: 5 is whether to not install it.
15:49:51 <sgallagh> 4 is just the subpackage
15:49:52 <bcotton> mhroncok: shortly :-)
15:49:54 <mhroncok> nirik: point 4 is splitting them into a separate package (and installing that package by default if 5 is not also approved)
15:50:08 <sgallagh> It opens a path to disabling it in the future or manually removing it.
15:50:13 <zbyszek> nirik: the idea is that they'll be split, but will still be installed by default (using comps or such.)
15:50:19 <sgallagh> I'm 0 on that so long as it's still installed by default for now
15:50:24 <King_InuYasha> I'm okay with splitting it *and* shipping it by default
15:50:24 <nirik> so, if 5 is not approved, it will be a seperate package, installed by default and enabled?
15:50:24 <mhroncok> so users/admins can decided to uninstall it
15:50:38 <sgallagh> nirik: Correct
15:50:39 <zbyszek> nirik: yes, that how I understand this.
15:50:42 <mhroncok> nirik: installed by default, but removable
15:51:07 <nirik> sure, it's just unclear if it's enabled / installed by default based on point 4 only... but sure.
15:51:21 <mhroncok> nirik: that depnds on point 5
15:51:21 <decathorpe> 4 without 5: easy opt-out (by removing the package)
15:51:34 <decathorpe> 4 with 5: opt-out by default (by not shipping the package)
15:51:37 <nirik> so, I am +1 to 1,2 (revised by this meeting), 3, 4, and -1 to 5
15:52:20 <sgallagh> -1, +1, +1, 0, -1
15:52:26 <decathorpe> If we vote now, can we go through the points individually please, to not make this more complicated than it needs to be?
15:52:35 <mhroncok> decathorpe: +1
15:52:40 <King_InuYasha> +1
15:52:52 <mhroncok> contyk: do you want to propose the points one by one as currently in the ticket?
15:52:58 <sgallagh> (My votes are based on the current version at the top)
15:53:14 <mhroncok> contyk: or shall we vote in batches?
15:53:15 <sgallagh> If we adopt mhroncok's alterations for 1. I can probably see my way to agreeing.
15:53:30 <contyk> I think it would make sense to vote on individual points.
15:53:35 <mhroncok> sgallagh: what alterations?
15:53:48 <ignatenkobrain> mhroncok: the exceptions that can be given by FESCo
15:53:51 <mhroncok> sgallagh: There is an exception to this rule...? that has been incorporated
15:53:53 <sgallagh> mhroncok: https://pagure.io/fesco/issue/2406#comment-658235
15:54:07 <sgallagh> Oh, I guess I needed to refresh the page.
15:54:09 <ignatenkobrain> oh, it was already put there
15:54:13 <sgallagh> +1, +1, +1, 0, -1
15:54:57 <zbyszek> Hmm, I'd prefer not to go point by point again. Voting in a row like sgallagh just did seems much simpler.
15:55:00 <ignatenkobrain> contyk: let's go 1 by 1 🙂 Otherwise there is just too much confusion
15:55:07 <contyk> If you guys can vote like sgallagh did, it will be easy to count.
15:55:14 <contyk> Or one by one, yes.
15:55:16 <contyk> So.
15:55:22 <ignatenkobrain> ok
15:55:24 <zbyszek> +1, +1, +1, +1, -1
15:55:25 <contyk> Proposal: Modular-only packages are not allowed and modular versions are only be allowed as alternatives to non-modular packages. There is an exception to this rule: if the package does not function in non-modular Fedora (with reasonable amount of work), it is permitted to have it in module only. As an example if non-modular Fedora has dnf 4, and there is module with dnf 5, a package that
15:55:27 <contyk> only works with dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora. For the time being, such exceptions can be granted by FESCo.
15:55:37 <nirik> +1, +1, +1, +1, -1
15:55:41 <mhroncok> contyk: +1 (sans some typos)
15:55:43 <cverna> +1, +1, +1, +1, -1
15:55:43 <contyk> Guys.
15:55:54 <mhroncok> :D
15:56:10 <nirik> I think one by one will take too long, but sure, if we want to...
15:56:11 <nirik> +1
15:56:24 <dcantrell> contyk: +1
15:56:31 <ignatenkobrain> +1
15:56:33 <decathorpe> contyk: +1
15:56:38 <zbyszek> contyk: +1
15:56:43 <cverna> +1
15:57:05 <dcantrell> (brb, coffee)
15:57:08 <King_InuYasha> +1
15:57:23 <sgallagh> +1
15:57:51 <contyk> #agreed Modular-only packages are not allowed and modular versions are only be allowed as alternatives to non-modular packages. (+8, 0, -0)
15:58:06 <contyk> #info There is an exception to this rule: if the package does not function in non-modular Fedora (with reasonable amount of work), it is permitted to have it in module only. As an example if non-modular Fedora has dnf 4, and there is module with dnf 5, a package that only works with dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora. For the time being, such
15:58:08 <contyk> exceptions can be granted by FESCo.
15:58:08 <ignatenkobrain> contyk: I think it was +9
15:58:35 <contyk> Right.
15:58:38 <contyk> #undo
15:58:38 <zodbot> Removing item from minutes: INFO by contyk at 15:58:06 : There is an exception to this rule: if the package does not function in non-modular Fedora (with reasonable amount of work), it is permitted to have it in module only. As an example if non-modular Fedora has dnf 4, and there is module with dnf 5, a package that only works with dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora. For the time being, such
15:58:38 <mhroncok> it was
15:58:40 <contyk> #undo
15:58:40 <zodbot> Removing item from minutes: AGREED by contyk at 15:57:51 : Modular-only packages are not allowed and modular versions are only be allowed as alternatives to non-modular packages. (+8, 0, -0)
15:58:47 <contyk> #agreed Modular-only packages are not allowed and modular versions are only be allowed as alternatives to non-modular packages. (+9, 0, -0)
15:58:54 <contyk> #info There is an exception to this rule: if the package does not function in non-modular Fedora (with reasonable amount of work), it is permitted to have it in module only. As an example if non-modular Fedora has dnf 4, and there is module with dnf 5, a package that only works with dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora. For the time being, such
15:58:56 <contyk> exceptions can be granted by FESCo.
15:59:05 <contyk> Proposal: Default streams are not allowed in Fedora. This may be revised in the future, especially if the functionality of default streams is improved.
15:59:12 <mhroncok> +1
15:59:14 <zbyszek> +1
15:59:29 <decathorpe> +1
15:59:30 <ignatenkobrain> +1
15:59:43 <sgallagh> +1
15:59:55 <cverna> +1
16:00:04 <King_InuYasha> +1
16:00:05 <dcantrell> +1
16:00:12 <nirik> +1
16:00:26 <contyk> #agreed Default streams are not allowed in Fedora. This may be revised in the future, especially if the functionality of default streams is improved. (+9, 0, -0)
16:00:36 <contyk> Proposal: Encourage compatibility packages rather than modules wherever reasonable (e.g., libraries, language interpreters, …, and anything that can benefit from parallel installability).
16:00:41 <mhroncok> +1
16:00:43 <nirik> +1
16:00:43 <dcantrell> +1
16:00:43 <zbyszek> +1
16:00:51 <decathorpe> +1
16:00:51 <ignatenkobrain> +1
16:00:55 <King_InuYasha> +1
16:01:22 <cverna> +1
16:01:40 <contyk> sgallagh: ?
16:01:56 <sgallagh> +1
16:02:07 <contyk> #agreed Encourage compatibility packages rather than modules wherever reasonable (e.g., libraries, language interpreters, …, and anything that can benefit from parallel installability). (+9, 0, -0)
16:02:17 <contyk> Proposal: Make *modular*.repo optional by splitting them into a separate package.
16:02:21 <mhroncok> +1
16:02:23 <sgallagh> 0
16:02:25 <zbyszek> +1
16:02:25 <ignatenkobrain> +1
16:02:31 <dcantrell> +1
16:02:34 <cverna> +1
16:02:35 <decathorpe> +1
16:02:49 <nirik> +1
16:03:04 <contyk> King_InuYasha: ?
16:03:10 <King_InuYasha> +1
16:03:12 <mhroncok> contyk: (I have a technical question after the voting ends before we dive into ELN)
16:03:24 <contyk> #agreed Make *modular*.repo optional by splitting them into a separate package. (+8, 1, -0)
16:03:27 <contyk> Sure.
16:03:31 <King_InuYasha> (sorry, juggling two meetings is hard)
16:03:36 <contyk> Proposal: Disable *modular*.repo by default in new installations.
16:03:40 <mhroncok> -1
16:03:41 <King_InuYasha> -1
16:03:45 <nirik> -1
16:03:46 <dcantrell> -1
16:04:02 <decathorpe> +1
16:04:03 <sgallagh> -1
16:04:09 <cverna> -1
16:04:10 <ignatenkobrain> +1
16:04:32 <zbyszek> -1
16:04:34 <contyk> zbyszek: ?
16:04:58 <contyk> #agreed Disable *modular*.repo by default in new installations. (2, 0, -7)
16:05:05 <contyk> #info Modular repo will remain enabled.
16:05:22 <contyk> Okay, mhroncok.
16:05:24 <mhroncok> wrt https://fedoraproject.org/wiki/Changes/ModularReposSubpackage
16:05:39 <mhroncok> shall I withdraw or shall we use it to track 4?
16:05:57 <King_InuYasha> we can use it to track 4
16:06:07 <ignatenkobrain> I'd prefer latter, yes
16:06:14 <contyk> Yeah, that would make sense.
16:06:14 <ignatenkobrain> so essentially we just approve it now
16:06:29 <zbyszek> Yeah, I think you should approve it now by vote
16:06:30 <mhroncok> well I recoon not everybody read it all, so I'd rather avoid saying it is pre-approved
16:06:34 <mhroncok> the spriiti of the change is
16:06:43 <mhroncok> *spirit
16:07:13 <nirik> lets use it to track and just approve it in the normal course of business.
16:07:19 <sgallagh> nirik: +1
16:07:20 <contyk> That proposal is a way to implement #4 but people should read it first in case there's something that needs clarification or something they disagree with.
16:07:46 <contyk> Onwards with the ELN discussion?
16:07:51 <mhroncok> contyk: sure
16:07:53 <cverna> nirik: +1
16:08:07 * mhroncok has put the approval of 4 into the feedback section
16:10:11 <contyk> Anything?
16:10:20 <mhroncok> Onwards with the ELN discussion
16:10:26 <King_InuYasha> let's go into that :)
16:10:26 <mhroncok> is anything for that?
16:11:04 <decathorpe> which ticket are we discussing?
16:11:10 <zbyszek> .fesco 2390
16:11:11 <zodbot> zbyszek: Issue #2390: Request to permit module default streams in ELN - fesco - Pagure.io - https://pagure.io/fesco/issue/2390
16:11:29 <decathorpe> zbyszek: thanks
16:11:46 <ignatenkobrain> I think sgallagh put some PR for the policy of such modules
16:12:06 <sgallagh> I have a PR of a WIP: https://pagure.io/fedora-docs/modularity/pull-request/83
16:12:10 <sgallagh> It is by no means final
16:12:16 <nirik> I think we need to allow eln to experement and try out things...
16:12:20 <contyk> I think the question is whether the decision to disallow default streams in Fedora affects ELN or not.
16:12:20 <sgallagh> I just wanted it somewhere that people could easily comment on it inline
16:12:29 <mhroncok> sgallagh: so this shall be now read as a policy for ELN, right?
16:12:35 <King_InuYasha> we should permit this for ELN
16:12:36 <decathorpe> At this point, I'm fine with letting people experiment in ELN. However: I don't want a "temporary" experiment in ELN to turn into "default streams are definitely a thing in RHEL 9" into "we need default streams in fedora now, too".
16:12:47 <King_InuYasha> precisely, +1 to that
16:12:48 <mhroncok> contyk: if nothing special is approved, I'd argue that it does
16:12:54 <dcantrell> decathorpe: +1
16:13:20 <zbyszek> sgallagh and bookwar were arguinging very strongly in the initial discussion about ELN that having separate branches for ELN would make it very hard for ELN to keep up with Fedora.
16:13:20 <ignatenkobrain> <decathorpe "At this point, I'm fine with let"> +1
16:13:28 <nirik> well, we aren't making rhel 9, so that decision isn't up to us. ;)
16:13:44 <dcantrell> a concern I have is that this is diverging from what we all just agreed on for Fedora.  the request is to experiment in ELN with default streams and I don't understand what default streams gets you that just having modules enabled doesn't
16:13:50 <ignatenkobrain> nirik: to some extent we are :)
16:14:02 <nirik> default streams is just a yaml file no?
16:14:03 <zbyszek> And a few weeks after that, the proposal is to actually not only make separate branches, but to pick a different delivery format.
16:14:30 <decathorpe> I'm just saying, it should be a separate decision, not inherit this from ELN automatically. But I recognise that this is not in the FESCo domain.
16:14:35 <mhroncok> also, the argument that we need to experiment with default streams in eln to see if they are usable seem rather weird to me
16:14:36 <bookwar> zbyszek: this argument is two -sided
16:14:39 <zbyszek> nirik: the yaml file picks what is built, so it's a yaml file, but a pretty powerful one.
16:14:42 <dcantrell> I do not want to end up in a place where ELN is (a) the upstream for RHEL and (b) so divergent from Fedora that Fedora developers now have to "get things in to ELN"
16:15:09 <sgallagh> decathorpe: default streams *are* definitely a think in RHEL 9.
16:15:14 <sgallagh> *thing
16:15:17 <zbyszek> The second argument against the proposal is that the same reasons that apply against default streams in Fedora also apply in ELN.
16:15:23 <mhroncok> we have heard nothing in the council meeting about the modularity team beiang able to actually dedicate time to fix issues with default streams in fedora
16:15:56 <dcantrell> this is a very valid point
16:15:57 <sgallagh> mhroncok: The remaining technical issue is the upgrade path
16:16:00 <decathorpe> sgallagh: Well that's unfortunate but if that's already the case, then I'm fine with allowing ELN to have default streams too
16:16:08 <mhroncok> sgallagh: one of the plenty reainign tehcnical issues?
16:16:09 <zbyszek> The third agument is that RHEL maintainers will work to fix things in streams, and not in rawhide, because that'd be doubling their work. We have seen this numerous times in Fedora.
16:16:13 <sgallagh> They *did* commit to fixing that by F34 (hopefully F33)
16:16:48 <zbyszek> Right, so if there are some concrete developments, they should be taken into account when they happen, not now.
16:16:53 <sgallagh> mhroncok: You keep saying that without actually listing any.
16:16:59 <sgallagh> That's not helpful, it's just misleading.
16:17:08 <mhroncok> sgallagh: I've listed plenty
16:17:18 <mhroncok> sgallagh: you've asked for them on the mialing list, I've listed them
16:17:19 <dcantrell> sgallagh: default streams may be a thing for RHEL 9, but as tbowling said on the call--PM doesn't really care about the implementation.  these discussions seem to always come back to "this implementation has to exist"
16:17:24 <mhroncok> you'Ve aksed for tickets, I've opened them
16:17:32 <mhroncok> there was no response what so ever to my problems
16:17:44 <zbyszek> sgallagh: just look at today's fedora-devel thread about eclipse
16:17:58 <sgallagh> I haven't seen fedora-devel yet today.
16:18:18 <ignatenkobrain> zbyszek: I think this should not be a huge concert, their package will just disappear from rawhide or somebody else will work on it. But definitely something to take in consideration.
16:18:20 <King_InuYasha> mhroncok, I'm already aware of work they are doing right now towards this
16:18:22 <mhroncok> we still don't even know how to properly query the modular content
16:18:42 <King_InuYasha> iirc, they were waiting for their proposal to be approved (which I think it recently was?)
16:18:47 <nirik> Do we know of any maintainers that won't maintain rawhide packages, but will maintain modules if there's default streams only? wouldn't it be better to reassign those packages anyhow if they care so little?
16:18:53 <zbyszek> ignatenkobrain: how would that happen? The owners of the module will still be owners of the package. They cannot work on the module otherwise.
16:18:53 <mhroncok> a miantainer approached me that they weren't aware that their buil depndency is going to be retired
16:19:01 <ignatenkobrain> I listed my main concerns here: https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122681
16:19:10 <King_InuYasha> nirik: this happened with Java
16:19:11 <mhroncok> why? because the query does not take modulaes into account
16:19:29 <mhroncok> nirik: we can reassign them, we did
16:19:36 <nirik> King_InuYasha: and all the java packages have been moved to the stewardship sig? and the new java sig?
16:19:46 <King_InuYasha> yes, now
16:19:52 <mhroncok> but I'd like the RH managers to go and say: fix your broken package sin Fedora
16:19:53 <ignatenkobrain> So what if we allow default modular streams in ELN but set some expectations and deadlines for the ELN SIG? If those can't be met within the time we give, we revert the ban.
16:20:06 <mhroncok> rigth now, it's Ok if the fixes are in modules only
16:20:11 <nirik> mhroncok: so, I don't see the last point as bad. In fact its a plus... if they won't maintain packages we know it and can reassign them
16:20:12 <zbyszek> sgallagh: so sorry, I want ELN to succeed, so I'll be voting -1 on this proposal.
16:20:28 <bookwar> zbyszek: The branching provided by modularity is indeed a concern, but we do have some power to prevent that. It is not the desire of Red Hat to diverge from Fedora to the technology which doesn't work. So RH won't create modules unconditionally just because someone wants that. RHEL has limited scope and doesn't want to maintain modules beyond that, so it will be in RH benefit to find a way the modularized content can coexi
16:20:28 <bookwar> ith non modular one.
16:21:04 <mhroncok> bookwar: how is that different form the mayhem that was in Fedora 30 and 31?
16:21:16 <bookwar> mhroncok: it has no impact on Fedora releases
16:21:25 <zbyszek> ignatenkobrain: "set some expectations" — I don't see that working. Who will do the work to undo the damage if it needs to be done? Doing that in Fedora took months.
16:21:35 <mhroncok> it has impact on the red hat paid maintainers
16:21:48 <mhroncok> zbyszek: it has not yet been undone
16:21:52 <nirik> zbyszek: what dammage?
16:22:08 * decathorpe spent the past year merging changes from modular Java branches into rawhide, just saying
16:22:15 <zbyszek> Various non-installable packages and upgrade issues.
16:22:28 <mhroncok> entire abandoned package stacks
16:22:34 <ignatenkobrain> zbyszek: ELN SIG? I mean we are not promoting that, if it breaks - ELN SIG will have to fix it
16:22:41 <sgallagh> decathorpe: I'm perfectly willing to entertain a proposal to kick the Java module as it exists today out of Fedora
16:22:52 <sgallagh> It's so far out of compliance with any policy we have as to be a disaster.
16:22:54 <nirik> but by forbidding default streams in eln, you think these people will maintain the rawhide stacks?
16:22:54 <mhroncok> sgallagh: and out of ELN?
16:23:00 <sgallagh> mhroncok: yes
16:23:13 <mhroncok> nirik: they did when it was the onyl way to miantain the packages
16:23:22 <decathorpe> That would definitely help, a lot
16:23:23 <sgallagh> mhroncok: They can reintroduce it when it's compliant with the policy I'm trying to expand on
16:23:28 <mhroncok> sgallagh: why did it not happen before and what makes this time different?
16:23:36 <zbyszek> nirik: I think it's at least as likely.
16:23:37 <nirik> I find that surprising, but then people are surprising sometimes. ;)
16:23:48 <sgallagh> mhroncok: Because we didn't have a policy to point to before.
16:24:06 <sgallagh> Which we acknowledged as a problem at the time
16:24:25 <bookwar> mhroncok: abandoned software stack is not the problem of modularity, it is the problem of unmaintained software stack in Fedora, which is hard to package in rpms. You can not hold ELN hostage so that Fedora packagers package things the way you want it to be packaged
16:24:40 <mhroncok> we had default modular streams in Fedora for several releases. it was a perfect opportunity to fix things (both technology and content)
16:24:48 <mhroncok> it didn't happen
16:24:51 <sgallagh> mhroncok: I'm not denying that.
16:24:53 <King_InuYasha> here's the thing: I *fully* expect ELN to be considered the upstream for RHEL in the future
16:25:01 <mhroncok> now we need the thign in ELN to have the oportunity to fic things?
16:25:15 <mhroncok> *fix
16:25:20 <King_InuYasha> that means that people will expect to be able to contribute and use ELN to help evolve RHEL
16:25:24 <sgallagh> We need a place to test the fixes outside of a lab setting
16:25:38 <King_InuYasha> the fact that it's a layer on Fedora is icing on the cake
16:25:48 <sgallagh> And to make sure that we don't break things *further* in the process
16:26:10 <King_InuYasha> but the reality is: we almost *never* see RHEL PMs interact with Fedora, so this arguing here is not going to lead to any changes in RHEL
16:26:13 <sgallagh> And if we break things in Fedora ELN while leaving Fedora alone... isn't that an all-around win?
16:26:18 <zbyszek> bookwar: I remember the history of the java stack completely differently.
16:26:18 <bookwar> mhroncok: we had no modules in the buildroot, which was the solution for the problem with java stack. FESCo didn't allow this solution to happen because it wasn't tested and good enough. We now trying to make this solution in a properly tested way
16:26:37 <nirik> If we had a bunch more personpower, I'd suggest we try and move all existing modules into packages and test that in eln... but that seems unlikely from a work needed / drivers.
16:26:41 <mhroncok> bookwar: this is not how I remember the thing
16:26:45 <sgallagh> bookwar: That's actually not true
16:26:54 <sgallagh> The problem with the Java stack was worse than that
16:27:28 <sgallagh> They were also cutting down the available features to the set that RHEL 8 was using. So even once it was in the buildroot, it still couldn't build a lot of packages.
16:27:34 <mhroncok> a modular packages in buildroot solution was approved for couple modules (for testing)
16:27:43 <mhroncok> as far as I recall it wa snot deployed at all
16:27:43 <zbyszek> sgallagh, bookwar: I think this should be tested in a private setup, and not in ELN which is now supposed to be the official place where RHEL maintainers can cooperate with upstream.
16:27:51 <sgallagh> Which I didn't realize at first or I'd probably have advocated kicking it out sooner.
16:27:56 <bookwar> zbyszek: i don't understand this requirement
16:28:01 <mhroncok> there was a place to test it outside of a lab
16:28:40 <zbyszek> bookwar: I completely don't understand the requirement to test the package installer by delivering a full distro compose.
16:28:43 <ignatenkobrain> Generally I'm not opposed to allow default streams in ELN, but I don't want it to be just some spherical cow. This project should have some expectations and deadlines.  Just allowing it and see what's going to explode in 1yr is not acceptable to me.
16:29:09 <mhroncok> when we approved ELN
16:29:26 <mhroncok> it was marked as curated rawhide content with different build options etc.
16:29:27 <bookwar> zbyszek: i don't understand the package installer part
16:29:33 <ignatenkobrain> as long as ELN is Fedora.
16:30:15 <zbyszek> bookwar: "package installer" = "way to install packages". My phrasing wasn't the best.
16:30:19 <mhroncok> was it expected form before ELN was approved that it will need default modular streams?
16:30:23 <mhroncok> *from
16:31:00 <nirik> perhaps before branching for f33 would be a realistic timeline ? enable until then, then ask progress and disable if none/no plan?
16:31:11 <sgallagh> mhroncok: It was expected that this was going to be a further ask, yes. Can we do ELN without them? Yes. Will it be as valuable a preview of RHEL 9 without it? No.
16:31:39 <sgallagh> nirik: ELN doesn't branch, it stays with Rawhide. But as a deadline, that's probably reasonable
16:31:58 <bookwar> mhroncok: it was expected by me at least that default modules streams can be configured on the side in whatever configuration possible, and as a developer I can play with this feature as long is it doesn't prevent other goals of ELN SIG
16:32:18 <mhroncok> "then ask progress" what shall be the progress we are looking for?
16:32:26 <ignatenkobrain> let me lookup when is the branching point
16:32:30 <nirik> sgallagh: right, but other things depend on those milestones... so it's a good checkin
16:32:33 <ignatenkobrain> Tue 2020-08-11
16:32:37 <mhroncok> RH maintainers going backt to maintain their packages in nonmodular Fedora?
16:32:56 <mhroncok> that won't happen over couple months
16:33:21 <King_InuYasha> mhroncok: I'm pretty sure it was
16:33:22 <cverna> I am generally +1 to allow default streams in ELN. As I understand it is a playground and we should let people play in it
16:33:23 <mhroncok> if we set a deadline, I'd rathe know what shall be expected to happen by that deadline
16:33:36 <King_InuYasha> I'm +1 to allowing ELN to do this
16:33:55 <mhroncok> (we can vote, maybe my opinion is a minority)
16:34:02 <sgallagh> mhroncok: Could I ask one more question of you?
16:34:10 <mhroncok> sgallagh: sure
16:34:27 <sgallagh> What, in specific terms, do you see as the risks involved with enabling default streams on ELN?
16:34:41 <dcantrell> I am -1 on default streams in ELN.  Three reasons:  1) We still lack a proposal around making non-modular software stacks continue to be maintained.  2) The dnf team has co\
16:34:45 <dcantrell> mmitted to maintenance of module support which to me means it's feature complete.  3) There is no way to do this in ELN without branching in dist-git for ELN, which I fear \
16:34:49 <dcantrell> will lead to a too divergent ELN which will mean we have two rawhide's to serve leading up to RHEL-9.
16:35:10 <sgallagh> 2) The statement by DNF is more nuanced than it sounds, unfortunately.
16:35:43 <nirik> why is 3 the case?
16:35:49 <sgallagh> 3) That's entirely wrong. Defaults are not managed in the dist-git repo for the module
16:35:51 <nirik> I guess for new modules you mean?
16:36:16 <sgallagh> They're maintained in the repodata
16:36:17 <dcantrell> my understanding is that branching is required in dist-git for this
16:36:25 <sgallagh> Your understanding is incorrect
16:36:29 <nirik> I don't see how. ;)
16:36:40 <dcantrell> bookwar: what were we talking about regarding branching and modules then?
16:36:56 <sgallagh> While 1) is true, I'm not sure it's necessarily our responsibility.
16:36:59 <bookwar> dcantrell: it is not required, but it is possible
16:37:00 <nirik> unless eln wants to add more modules... but thye would also be in rawhide (I would sure hope)
16:37:11 <ignatenkobrain> I think dcantrell means that people will want to not use master branch, but for something else what they see better fit in their opinion
16:37:17 <sgallagh> We don't have a policy in non-modular Fedora requiring dependency stacks to continue to be maintained.
16:37:18 <mhroncok> sgallagh: currently, I see a pressure to "put all RHEL things into Fedora first". with ELN I expect the meaning of this will shift to "...into Fedora ELN first". If ELN content is Fedora non-modular rawhide content, such improvements will benefit Fedora. If ELN content is modular streams, such improvement will only be available from modules and community maintainers will play Whac-A-Mole backportign the changes to Fedora (or th
16:37:18 <mhroncok> e stacks will die out)
16:37:25 <sgallagh> That's why we have the non-responsive maintainer policy
16:37:34 <mhroncok> sgallagh: this is my primary probem with this
16:37:43 <bookwar> mhroncok: the choice we are making is not whether RH maintainers going to maintain modular or non-modular packages in Fedora. FESCo doesn't have power over this. The choice is: if we work together with downstream maintainers on integrating modules with Fedora via ELN, or we push downstream maintainers outside of the project.
16:37:43 <mhroncok> there are also secondary problems
16:37:44 <dcantrell> ignatenkobrain: yes
16:38:17 <sgallagh> mhroncok: OK, I can understand and respect that.
16:38:58 <bookwar> mhroncok: you are trying to force RH maintainers to work on non-modular packages in Fedora. Blocking modularity development won't help in that. I think this is not in the power of FESCo. I'd rather see this as a concern Fedora raises to RH through Council
16:39:01 <ignatenkobrain> sgallagh: are those default streams expected to be API compatible to the fedora non-modular content?
16:39:10 <zbyszek> bookwar: another way to look at this: RH maintainers will work on the content in ELN. The choice we are making is whether they'll be primarly working on modules, which means that rawhide doesn't benefit, or on normal packages, which means that rawhide will immediately benefit.
16:39:23 <cverna> I kind of agree with bookwar. I am not here to decide where RH employees should work
16:39:23 <ignatenkobrain> in the sense if rawhide ships libgit2 1.x, the default modular stream in ELN will be 1.x and not something else.
16:39:25 <bookwar> zbyszek: no, again, this is not our choice
16:39:42 <sgallagh> ignatenkobrain: That's what I wrote in the WIP policy, yes
16:39:42 <bookwar> zbyszek: fesco can not force anyone to work on things they don't want to work
16:39:57 <ignatenkobrain> (and built from master branch of course)
16:40:22 <sgallagh> ignatenkobrain: Not necessarily.
16:40:26 <mhroncok> bookwar: what you say makes sense... if ELN is a RHEL project
16:40:31 <zbyszek> bookwar: yes, but fesco can (to some extent) decide what should be part of Fedora.
16:40:34 <sgallagh> But for most cases that will be the most expedient approach
16:40:47 <mhroncok> if ELN is a Fedora project, or a joint RHEL-Fedora project... we have a say about this
16:41:21 <bookwar> mhroncok: no, it doesn't matter. You have fedora community which wants to work on modules. You can allow this, or push that community outside of the project. But you can not force anyone to do things your way.
16:41:34 <dcantrell> so trying to follow the principle of least astonishment, a package joining a module that is a BR for another package becomes an unexpected change for that other package.  now that other maintainer has to either take on ownership of the abandoned one -or- become a module, which may or may not work for them.  why is this not a concern for everyone?
16:41:56 <zbyszek> dcantrell: it is
16:42:04 <ignatenkobrain> If the content of those default streams will be built from master branch, in a timely manner which essentially means fixes will be contributed to rawhide and also there will be many restrictions on what default streams can be, I can be convinced... but the WIP PR provided sgallagh does not restrict even half of the use-cases
16:42:05 <bookwar> dcantrell: it is a limiting factor for modues in RHEL, which is a good thing
16:42:10 <mhroncok> I want ELN to succeed. I want ELN to be  a place where Red hat driven content and technology innovation (that cannot happen in Fedora proper) happens. If we make default ELN content different from default ELN content, this is (in my opinion) a doomed goal
16:42:13 <sgallagh> dcantrell: That's not true if default streams are permitted... But we're not asking for that in Fedora right now
16:42:29 <zbyszek> bookwar: I haven't seen this community. If there are maintainers who fall into this category, they need to make their needs public.
16:42:29 <mhroncok> bookwar: "You have fedora community which wants to work on modules" where?
16:42:40 <sgallagh> ignatenkobrain: You know what WIP means, right?
16:42:42 <bookwar> mhroncok: me, petr, stephen
16:43:03 <sgallagh> It's there specifically so you can provide feedback and help us figure out what cases aren't covered
16:43:04 <dcantrell> sgallagh: except no?  because default streams is what pushed an old version of protobuf on to my system which unexpectedly broke something else.  all because the "module version" was newer
16:43:05 <ignatenkobrain> sgallagh: sure 🙂 I was just saying that if we can incorporate those things there..
16:43:32 <sgallagh> ignatenkobrain: I'd appreciate your inpuit
16:43:32 <contyk> RH employees are also community members, just saying.
16:43:50 <sgallagh> I'm trying my best to get to a place we can all be comfortable with
16:44:00 <sgallagh> Or at least tolerate without too much grumbling
16:44:10 <mhroncok> contyk: "RH employees are also community members, just saying" as one of them, I can relate to that
16:44:11 <dcantrell> additionally, modules make it appealing to not care about things that depend on you as a BuildRequires, so you get in these weird situations where the answer ends up being "you can't"
16:44:13 <King_InuYasha> look, at this point, I'm happy to approve ELN doing things
16:44:29 <zbyszek> contyk: of course RH employees are imporant, but so far we haven't heard anything from them here.
16:44:31 <King_InuYasha> what *I* want out of this is a stronger feedback loop between Red Hat and Fedora
16:44:43 <contyk> If those people want to maintain modules, because it works for them or because it's their job, they will; like bookwar is saying, you cannot force them to do other things as well.
16:44:45 <cverna> King_InuYasha: +1
16:44:50 <contyk> You can let them do that or push them away.
16:44:57 <King_InuYasha> I'm happy to sit here and approve changes, but only because I expect them to actually *show* up
16:45:03 <decathorpe> I thought the ELN SIG was going to de
16:45:05 <mhroncok> contyk: we cannot force them, I know
16:45:11 <mhroncok> but we can set expectations
16:45:33 <bookwar> dcantrell: this is a short term benefit, which has a long term downsides. Both Fedora and RHEL acknowledge that. So in ELN case, noone will rush into creating more and more modules just because they don't fit
16:45:35 <sgallagh> mhroncok: And that is something I am going to be pushing internally too
16:45:45 * nirik wonders if we could get feedback from module owners in fedora...
16:45:49 <decathorpe> (me pressed enter too early, sorry) I thought the ELN SIG was going to decide upon modular branches and which things to make default streams?
16:45:58 <zbyszek> nirik: +1
16:46:06 * contyk is a module owner in Fedora.
16:46:10 <sgallagh> nirik: The internal maintainers literally don't want to get drawn into the conversation because it's too hostile for them.
16:46:17 <sgallagh> I've heard this from two different SST leads
16:46:18 <ignatenkobrain> sgallagh: sure, I'll try to sum up my requirements in that PR. in short 1) it must be beneficial for rawhide - aka changes that are made for default streams in ELN must be made in rawhide first 2) we need to restrict those default streams as much as we can 3) define criterias that needs to be met by F33 branching in terms of repoquery, upgrade problems and whatnot.
16:46:34 <decathorpe> sgallagh: what's SST?
16:46:41 <King_InuYasha> decathorpe: subsystem team
16:46:51 <ignatenkobrain> SubSystem Team I guess
16:46:52 <decathorpe> ah.
16:46:52 <King_InuYasha> it's RH's weird agile thingy for dividing up RHEL resources
16:46:57 <nirik> sgallagh: I don't want to draw them into a hostile thing, I just would like to know why they maintain modules, if they maintain non modular also, if they would be willing to move their modules to compat packages, etc...
16:47:01 <zbyszek> contyk: yes, I know you and bookwar and sgallagh support this. Are there others?
16:47:26 <mhroncok> I want to say that *if* this happens, I am happy that sgallagh is trying to set some expectations and rules for the default modular streams
16:47:31 <ignatenkobrain> sgallagh: if what I said makes sense, I would propose to defer decision by a week and work together with you during this time on improving that PR.
16:48:33 <contyk> zbyszek: I can't name others; we actually maintain modules and nirik asked for module owners' feedback.
16:48:39 <sgallagh> I'm willing to work with you on that, sure
16:48:42 <bookwar> the conversation on how far modules can go is a valid conversation for both Fedora and RHEL and it is far from done. I think it is a council conversation more that it is fesco. I literally submitted Integrate First concept to Fedora Council half a year ago for this particular reason. But I believe it shouldn't prevent us from testing and developing the technology stack on the side.
16:48:50 <mhroncok> contyk: when we do this, we ar ejust 4 loud individuals
16:48:51 <contyk> If you discard our opinions and need others, approach those other owners.
16:49:12 <King_InuYasha> :/
16:49:46 <mhroncok> it is hard to have a conversation when we don't actually get the same treatment you expect us to give you
16:50:50 <ignatenkobrain> Proposal: Defer to the next meeting. Meanwhile sgallagh will work on improving policy for those modules with feedback from FESCo members .
16:50:51 <zbyszek> contyk: I'm not disacarding your opinion. I'm looking for a wider opinion from people who are using the stack and are not immediately involved in the development.
16:51:23 <zbyszek> ignatenkobrain: sure, +1
16:51:31 <sgallagh> ignatenkobrain: +1
16:51:46 <mhroncok> ignatenkobrain: +1
16:51:47 <nirik> +1, I don't think we are going to solve it today (again)
16:51:47 <dcantrell> ignatenkobrain: +1
16:51:52 <decathorpe> Igor Raits: +1
16:51:59 <cverna> +1
16:52:19 <contyk> King_InuYasha: ?
16:52:27 <King_InuYasha> +1
16:52:36 <contyk> #agreed Defer to the next meeting. Meanwhile sgallagh will work on improving policy for those modules with feedback from FESCo members. (+9, 0, -0)
16:52:38 <zbyszek> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EJD3V43ONMVE37DQO6RVQ5ZGN6PJXDBC/ is the case on fedora-devel today.
16:52:56 <contyk> #topic Next week's chair
16:53:10 <ignatenkobrain> I will do it
16:53:17 <contyk> That's for the new slot already, Wednesday next week.
16:53:25 <contyk> #action ignatenkobrain will chair the next meeting.
16:53:27 <contyk> Thank you.
16:53:32 <contyk> #topic Open Floor
16:53:41 <contyk> We have seven minutes. Anything for the open floor?
16:53:48 <sgallagh> Thank you contyk for chairing this meeting despite no longer being a voting member
16:54:00 <ignatenkobrain> contyk++
16:54:00 <zodbot> ignatenkobrain: Karma for psabata changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:06 <zbyszek> contyk++
16:54:06 <zodbot> zbyszek: Karma for psabata changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:07 <sgallagh> contyk++
16:54:09 <zodbot> sgallagh: Karma for psabata changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:10 <decathorpe> yes, thanks! contyk++
16:54:13 <mhroncok> contyk++
16:54:13 <zodbot> decathorpe: Karma for psabata changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:16 <zodbot> mhroncok: Karma for psabata changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:19 <nirik> thanks contyk++
16:54:19 <zodbot> nirik: Karma for psabata changed to 9 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:26 <dcantrell> contyk++
16:54:27 <zbyszek> I have a minor thing (possibly for bcotton)
16:54:30 <contyk> So many cookies.
16:54:39 <contyk> Go ahead, zbyszek.
16:54:54 <ignatenkobrain> contyk: you deserved it :)
16:55:06 <zbyszek> https://docs.fedoraproject.org/en-US/fesco/ is not getting updated.
16:55:15 <zbyszek> Is this because of the data center move?
16:55:17 <cverna> contyk++
16:55:17 <zodbot> cverna: Karma for psabata changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:55:40 <bcotton> zbyszek: i think it may be because the translations were blowing up the disk usage
16:56:23 <bcotton> not sure if all docs were disabled or if it was just set to publish en-US
16:56:26 <zbyszek> I just wanted to raise awareness, we'll need to fix this at some point.
16:56:28 <bcotton> asamalik may know better
16:56:54 <bcotton> https://pagure.io/fedora-infrastructure/issue/8964
16:57:04 <contyk> Oh, by the way, I'll send out the notes and add comments to the tickets but I don't have the permissions to update tags or close anything. I'll need someone else to do it.
16:57:14 <contyk> Probably ignatenkobrain since he's the next chair.
16:57:30 <ignatenkobrain> will do.
16:58:07 <contyk> Thanks.
16:58:14 <contyk> Okay, closing in a minute.
16:58:20 <nirik> yes, thats known and on the list...
16:58:36 <nirik> and yes, it's because 100GB won't fit in 25GB. ;)
16:59:06 <mhroncok> that's unexpected
16:59:12 <ignatenkobrain> depends what those 100G is :D
16:59:17 <contyk> :)
16:59:21 <contyk> 3, 2, 1...
16:59:23 <mhroncok> bye
16:59:24 <contyk> #endmeeting