19:00:16 #startmeeting FESCO (2021-08-16) 19:00:16 Meeting started Mon Aug 16 19:00:16 2021 UTC. 19:00:16 This meeting is logged and archived in a public location. 19:00:16 The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:16 The meeting name has been set to 'fesco_(2021-08-16)' 19:00:16 #meetingname fesco 19:00:16 The meeting name has been set to 'fesco' 19:00:16 #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, defolos, mboddu, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 19:00:16 #topic init process 19:00:16 Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe defolos mboddu mhroncok nirik sgallagh zbyszek 19:00:19 .hello2 19:00:20 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 19:00:28 .hello sgallagh 19:00:29 .hello ngompa 19:00:29 sgallagh: sgallagh 'Stephen Gallagher' 19:00:32 Eighth_Doctor: ngompa 'Neal Gompa' 19:00:33 .hello2 19:00:35 bcotton: bcotton 'Ben Cotton' 19:00:39 * Eighth_Doctor is getting a sandwich 19:00:41 .hello churchyard 19:00:43 mhroncok: churchyard 'Miro Hrončok' 19:00:43 morning 19:00:46 .hello kevin 19:00:47 nirik: kevin 'Kevin Fenzi' 19:01:38 We have quorum. Do we expect anyone else? 19:01:47 .hello2 19:01:48 dcantrell: dcantrell 'David Cantrell' 19:01:53 what's this ritual? 19:02:12 asosedkin: thanks for joining. I was looking up your nick to ping you ;) 19:02:26 dwmw2: we'll be discussing 2659 next. 19:02:37 asosedkin: it summons the good spirits of IRC to be with us 19:02:41 .hello2 19:02:44 decathorpe: decathorpe 'Fabio Valentini' 19:02:58 #topic #2659 Arbitration request: Crypto policy prevents VPN connections 19:02:58 .fesco 2659 19:03:04 zbyszek: Issue #2659: Arbitration request: Crypto policy prevents VPN connections - fesco - Pagure.io - https://pagure.io/fesco/issue/2659 19:03:05 asosedkin: it's for the chair to know if we have quorum and for the logs to be clear who's who 19:03:30 as usually, I don't think fesco tickets are good discussion forum 19:03:38 this should be discussed on devel mailing list 19:03:47 * nirik nods in agreement 19:04:20 * asosedkin hopes there ain't much left to discuss on 2659 19:04:24 as for emergency stop gap solution I think we should revert and then discuss of devel of what the nexts steps should be 19:04:28 Morning 19:04:45 I've just put a final response in the ticket; sorry for being late 19:04:49 it's much less heated when things are not broken 19:05:50 sure. I think I've understood the need for revert well enough now 19:05:57 * zbyszek is reading the latest comments on the ticket 19:06:25 Allowing DTLS0.9 *only* in GnuTLS should be fine. Let's make sure ocserv has it disabled by default too, and there are no other applications that would even try to use it. 19:06:45 I was previously under the impression that openconnect's gonna opt out with an envvar trick anyway and we'll need to win their hearts back when we have a better solution =) 19:06:48 Don't care about OpenSSL; although you *can* build OpenConnect against OpenSSL that isn't the preferred configuration and isn't what Fedora does 19:07:15 I did that for upstream. As noted, it's too incoherent to do it in *Fedora*; I didn't think that was right. 19:07:17 dwmw2: can we tighten that to "not hard-disabling DTLS0.9 should be fine"? 19:07:21 Yeah, I think we should revert as a stop gap solution, both in F35 and rawhide, until we have a better option. 19:07:26 asosedkin: yes. 19:07:47 zbyszek: +1 19:07:48 Users of other protocols will care about DTLS1.0 in similar ways but it's Cisco AnyConnect which is the major user base 19:08:03 So they can wait for the prio-string based solution 19:08:11 .hello2 19:08:12 defolos: defolos 'Dan Čermák' 19:08:13 ok, is reverting a general agreement or do we need to put our subber stamp on it? 19:08:13 dwmw2: cool, this way it's not enabled by default unless apps enable it with a prio-string 19:08:18 sorry for being late 19:08:21 mhroncok: +1 19:08:28 *rubber 19:08:30 asosedkin: Indeed. It never was anyway, was it? 19:08:35 mhroncok: +1 for reverting to not-hard-disabling in both f35 and rawhide 19:08:48 dwmw2: I'm new to this, I can't answer 19:08:51 asosedkin: you are the one who can do that? 19:09:08 mhroncok: yes 19:09:13 This protocol never existed for anything but Cisco. I added it to OpenSSL and worked with nmav to put it in GnuTLS too. 19:09:14 asosedkin++ 19:09:14 mhroncok: Karma for asosedkin changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:09:17 thanks asosedkin 19:09:22 Thanks 19:09:24 I don't think fesco needs to vote 19:09:31 mhroncok: agreed 19:09:58 Always best when such things sort themselves out, indeed 19:10:17 asosedkin: I would *love* to be able to handle older protocols like we handle bad certs. At *negotiation* time, we realise we're in that situation and we ask the user to confirm acceptance. 19:10:44 OK, any last comments, or can we close the fesco ticket, and asosedkin and dwmw2 will take it from here? 19:10:46 In some cases when we realise we only get DTLS1.0 when we wanted DTLS1.2 we can't know any earlier. We want to do it just like a cert verify. 19:11:18 dwmw2: that'd be quite a revamp to all gnutls algorithm selection, basically a third or fourth override to the existing mechanisms, but feel free to file a ticket upstream 19:11:53 Yeah. We should take the implementation discussion elsewhere, I suppose. zbyszek no further comments in FESCo context; thanks. 19:12:16 OK, thank you both. 19:12:19 dwmw2++ 19:12:19 zbyszek: Karma for dwmw2 changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:12:22 asosedkin++ 19:12:25 zbyszek: Karma for asosedkin changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:12:28 thanks guys 19:12:48 #2660 F35 incomplete changes: Code complete (testable) deadline 19:12:49 .fesco 2660 19:12:50 zbyszek: Issue #2660: F35 incomplete changes: Code complete (testable) deadline - fesco - Pagure.io - https://pagure.io/fesco/issue/2660 19:13:07 sorry, very quick question since you're probably the right folks 19:13:16 zbyszek: how do you want to dicuss this? one by one? 19:13:21 #undo 19:13:21 Removing item from minutes: 19:13:28 what's the deadline to fixing things the right way, if it requires a F36 system-wide change? 19:13:44 like, change filing deadline and change implementation deadlines? 19:13:48 asosedkin: https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html 19:13:49 I thought this was about F35? 19:13:52 if it's only about one package, then it's self contained 19:14:08 asosedkin: Change Checkpoint: Proposal submission deadline (Self Contained Changes) Tue 2022-01-18 19:14:24 Or do you mean doing the deprecation in 36? 19:14:32 asosedkin: I guess for F35 this would be handled like a bug, i.e. no Change page. For F36, there's plenty of time as others said. 19:14:34 I think that's what asosedkin is talking about 19:14:39 * mhroncok needs to reconnect, brb 19:14:52 I want a better fix in f36 as well, switching everything gnutls to soft-disabling from hard-disabling 19:15:45 asosedkin: I guess this could be considered a system-wide change, the deadline for that is Tue 2021-12-28. 19:16:04 zbyszek: filing or implementing? 19:16:29 That was filing. 19:16:34 Implementing is Change Checkpoint: Completion deadline (testable) Tue 2022-02-08. 19:16:50 zbyszek: awesome, and sorry for derailing the meeting a bit 19:17:03 But the important part is getting the necessary changes to the code done. The bureacracy in Fedora is adaptable. 19:17:42 OK, let's move to the other Changes. 19:17:49 #2660 F35 incomplete changes: Code complete (testable) deadline 19:17:49 .fesco 2660 19:17:50 zbyszek: Issue #2660: F35 incomplete changes: Code complete (testable) deadline - fesco - Pagure.io - https://pagure.io/fesco/issue/2660 19:17:53 Let's go one by one. 19:18:40 #topic #2660 F35 incomplete changes: Code complete (testable) deadline 19:18:41 .fesco 2660 19:18:42 zbyszek: Issue #2660: F35 incomplete changes: Code complete (testable) deadline - fesco - Pagure.io - https://pagure.io/fesco/issue/2660 19:19:02 Hmm, I think messed up the minutes. Sorry. 19:19:20 Not a big deal. 19:19:23 #topic GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) 19:19:29 It's all good, no? 19:20:06 I think it's done yeah... 19:20:11 binutils has some issues, but otherwise I think so 19:20:11 no idea if there are more minor versions to update to 19:20:15 iirc, it's all implemented except the glibc ABI stability hasn't been done 19:20:24 looks done, I think 19:20:33 unrelistic to revert anyway 19:20:40 *unrealistic 19:20:45 oh that landed last week 19:20:46 looks good then 19:20:50 OK, let's move on. 19:21:00 Should I go over the ones that are "most done" too? 19:21:13 (or just the "mostly not done ones?) 19:21:24 no preference 19:21:45 OK, I'll go over all, maybe we'll have some insights. 19:21:48 #topic CompilerPolicy Change 19:22:17 mhroncok: you are on the FPC, right? Can we get this done more quickly? 19:22:49 zbyszek: yes I am 19:23:06 zbyszek: until your comment on the ticket I was unaware this is blocked on fpc 19:23:33 fpc unfortunatelly does not deal with tickets the way fesco does 19:23:41 they tend to... wait 19:24:02 I can certainly try to get it done, do you have a link? 19:24:08 I think it's two steps: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/138 19:24:14 https://pagure.io/packaging-committee/pull-request/1066 19:24:20 redhat-rpm-config is not maintained by FPC 19:24:23 … and what decathorpe linked. 19:24:28 lately, it feels like it is not maintained 19:24:37 Yeah the redhat-rpm-config change should probably be merged first. 19:24:39 well, that's because it's not 19:24:43 the packaging guidelines PR looks fine 19:24:46 it's "get a provenpackager to merge stuff" maintained 19:24:55 redhat-rpm-config hasn't been properly maintained for years 19:25:05 A volunteer to proven-packager this? 19:25:21 I just merged it 19:25:26 * defolos isn't one 19:25:27 I have proven packager fwiw, but I never know what the process is for getting redhat-rpm-config chanages approved. 19:25:29 Eighth_Doctor: thanks! 19:25:47 I can't trigger builds right now (probably later), but it's merged now 19:25:51 tstellar: I think it's better style if somebody else presses the merge button ;) 19:26:03 tstellar: there is no process 19:26:08 it's no man's land 19:26:10 OK, so now we only need to do the FPC ticket. 19:26:21 I'm doing builds now 19:26:46 * bcotton will be mobile for a few minutes to get the kids from the school bus 19:26:46 building for f35 and rawhide now 19:26:47 mhroncok, zbyszek: This is a discussion for another day, but I think we need to find official mantainers for this package. It's pretty important for the distro. 19:26:55 * nirik considers if we should assign/get some folks to actually maintain that package 19:27:09 #info The redhat-rpm-config pull request has been merged. We still need FPC#1066 to be merged. 19:27:19 tstellar: definitely 19:27:37 the wording is fine 19:27:38 mhroncok or I can merge the FPC PR later 19:28:00 #action mhroncok or Eighth_Doctor to handle the FPC ticket 1066 19:28:00 it's tagged with meeting, so I won't do it today 19:28:03 Eighth_Doctor: I guess we should bring it up on Thursday's meeting 19:28:07 yep 19:28:18 zbyszek: ack 19:28:27 sorry for being so slow at fpc 19:28:48 tstellar: note that you'll need to sync it to rhel yourself 19:28:49 (I've considered resigning, but for a lack of other volunteers, i haven't) 19:28:55 and like in fedora, redhat-rpm-config is essentially unmaintained in rhel 19:29:02 #action zbyszek to open a ticket to discuss redhat-rpm-config maintanance 19:29:13 zbyszek: no tickets please 19:29:13 (as in, it has maintainers, but they don't do anything) 19:29:17 zbyszek: threads 19:29:33 #undo 19:29:33 Removing item from minutes: ACTION by zbyszek at 19:29:02 : zbyszek to open a ticket to discuss redhat-rpm-config maintanance 19:29:43 it's been in the past the rpm maintainer(s), but they don't actually do much maintaining on it. 19:29:44 #action zbyszek to open a thread to discuss redhat-rpm-config maintanance 19:29:55 zbyszek++ 19:29:55 mhroncok: Karma for zbyszek changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:30:04 #topic Autoconf-2.71 19:30:15 Nothing to see here, I think bcotton will reassign it. 19:30:21 (to F36). 19:30:25 ack 19:30:26 hasn't that been deferred? 19:30:26 This was deferred, right? 19:30:46 it is being deferred 19:30:48 Yeah, by the change owners. 19:30:58 I only mentioned it for completeness. 19:31:15 #topic Golang 1.17 19:31:56 Copr builds are happening. I think we can expect this to be done in 1–2 weeks. 19:32:01 yep 19:32:03 this is... sort of done 19:32:11 we just talked about it an hour ago in the Go SIG meeting 19:32:14 do we want this in f35? 19:32:29 well, it's getting pretty late 19:32:38 beta freeze is in 1 week 19:32:44 mhroncok: I think the general answer is yes, if the change seems stable. 19:32:51 done in 1-2 weeks would land after beta 19:32:55 Conan Kudo: any big/maportant packages that could be impacted by this? 19:32:57 beta freeze is likely the deadline 19:33:06 s/maportant/important 19:33:09 * Eighth_Doctor shrugs 19:33:21 the container circus packages are the main ones anyone cares about 19:33:35 I'd be more likely to say "push to f35 before beta freeze" if this was already in rawhide without causing trouble 19:34:11 well, they're doing the build in copr right now, so it's really not a huge deal 19:34:15 Proposal: the change can be done in F35 if it can be finished before the beta freeze. 19:34:20 proposal: if this lands by beta freeze, it will be in f35. if not, don't do it 19:34:28 zbyszek: +1, same as mine 19:34:30 zbyszek: +1 19:34:35 is there anything we absolutely want from golang 1.17? if not, I say it missed the deadline and just postpone it 19:34:44 well ... I have experience with golang stuff failing on ppc64le and s390x, which are both not going to get caught in COPR 19:35:11 so build it in a side tag and merge it before the beta freeze? 19:35:13 copr does have ppc64le now 19:35:13 dcantrell: I'd leave that to the maintainers… 19:35:15 zbyszek: +1 19:35:50 defolos: I'd only do that side tag after rawhide was succesfull 19:35:52 zbyszek: +1 19:35:52 ok, then what I'm reading in the change proposal doesn't look like something that can't be postponed. 19:36:19 I think the plan was to update golang and a few things, but not mass rebuild everything go... 19:36:42 dcantrell: one aspect is if we need the distro packages to be rebuilt with new go 19:36:52 most packages only ship sources so that should be fine 19:36:55 dcantrell: I say we don't necessarily 19:37:17 dcantrell: the other aspect is that we want f35 developers to have new go compiler 19:37:26 mhroncok: right, which was a concern I have and it seems like we've run out of time for that. all I'm saying 19:37:46 * Eighth_Doctor shrugs 19:37:58 good thing is that packages that won't build will still function 19:38:05 dcantrell: I think our an important part of the Fedora appeal is that you get the recent version of various development packages. I think we should strive to have latest stable versions, when reasonable. 19:38:32 I agree with that, but if we're cutting out our time window to validate that then it's a gamble. 19:38:40 if only there was a way to offer new go to users without impacting the distro... 19:38:42 * mhroncok hides 19:38:45 and if this isn't something that is urgent then I say why worry and just postpone it 19:38:59 If only we had a technology in Fedora that would allow us to ship multiple versions of Go... 19:39:01 but if no one seems to care, I don't really care 19:39:09 sgallagh: exactly 19:39:12 if only our infrastructure didn't suck for this kind of thing... 19:39:24 mhroncok: I see we are on the same page here :-D 19:39:42 sgallagh, mhroncok: maybe two sides of the same page? 19:39:43 anyhow, I'm fine giving folks until freeze to get it in... 19:39:44 * zbyszek ducks 19:39:47 yeah, see Python :) 19:39:58 count the votes? 19:40:01 * Eighth_Doctor is not bitter at all... 19:40:05 dcantrell, decathorpe: vote? 19:40:19 give it until the freeze +1 19:40:25 +1 give it until the freeze 19:40:25 +1 to let them get it done before beta freeze 19:40:41 * mboddu 's browser died, fixing it... 19:41:01 +1 give until freeze 19:41:32 #agreed The change can be done in F35 if it can be finished before the beta freeze. 19:41:34 #undo 19:41:34 Removing item from minutes: AGREED by zbyszek at 19:41:32 : The change can be done in F35 if it can be finished before the beta freeze. 19:41:42 #agreed The change can be done in F35 if it can be finished before the beta freeze (+7, 0, 0) 19:42:09 #topic LLVM 13 19:42:19 #info https://fedoraproject.org/wiki/Changes/LLVM-13 19:42:35 tstellar: are you still around? 19:42:39 zbyszek: Yeah. 19:43:11 Oh, I missed this in the ticket: 19:43:12 I have 13 of the 16 packages built in f35-build-side-43964, and I expect to finish the rest this week. 19:43:24 So… it's all good? 19:43:29 cool. +1 to wait on that 19:43:42 Yeah, this is in good hands 19:43:45 +1 to wait 19:43:54 +1 to wait for the rest to finish 19:43:56 zbyszek: I ran into some issues with annobin, that set me back a little, but I have that resolved now and have resumed doing builds today. 19:43:56 oviously, until the beta freeze 19:43:56 ack, I don't think we need an explicit vote. 19:44:11 mhroncok: f35 beta freeze ;) 19:44:19 explicit +1 to let tstellar do his job anyway :) 19:44:29 Ok, ok 19:44:38 zbyszek: yeah, that one 19:44:55 #agreed let tstellar do his job (+6, 0, 0) 19:45:02 * Eighth_Doctor sighs about annobin 19:45:11 it continues to haunt us 19:45:32 Eighth_Doctor: well, a discussion for another time. 19:45:39 #topic Adding Selected Flathub Applications 19:46:01 Eighth_Doctor: heh 19:46:31 that's all done, we're waiting for GNOME 41 to land 19:46:34 #info https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications 19:46:54 Fedora specific work is complete, upstream work is complete, it'll be part of GNOME 41 alpha 19:46:58 I see that bcotton wrote "Adding Selected Flathub Applications — set to MODIFIED" 19:47:28 Eighth_Doctor: ack, so I think we don't need to worry about this. 19:47:49 #topic Introduce Module obsoletes and EOL 19:47:52 yep 19:47:59 dmach is not here… 19:48:17 my understanding here is that dnf supports this, but our infra does not 19:48:29 #info https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL 19:48:29 and there has been no work in infra to support that 19:48:53 I'm not sure DNF support for this landed either. 19:49:02 or maybe even that 19:49:05 😩 19:49:07 And there's no packaging guidelines for how to use it. 19:49:07 it looks overall pretty stalled 19:49:17 iirc this was discussed at some point a year ago? 19:49:20 also, this has been driven by some rhel needs, and at the end I think they say it will not be done in rhel that way 19:49:21 well, it's just a document, hosting that should not be a problem if it existed. 19:49:24 So I'd have to assume this is not happening in F35 19:49:47 .bugzilla 1834844 19:49:51 nirik: What's just a document? 19:50:04 Hmm, what's the magic phrase to link to a bug? 19:50:04 nah, it's not happening. and I'd propose to reject instead of deferring, resumbitting if wanted 19:50:09 .bz 19:50:15 .bz 1834844 19:50:18 sgallagh: the module obsoletes 19:50:19 .bug , I think. 19:50:19 decathorpe: Error: That URL raised 19:50:36 .bug 1834844 19:50:38 decathorpe: 1834844 – Introduce module Obsoletes and EOL - https://bugzilla.redhat.com/1834844 19:50:44 yeah that did it. 19:50:49 mea culpa 19:50:51 mhroncok: What infra work is needed? I thought it will be all part of module metadata file? 19:51:14 mboddu: I don't know about specifics 19:51:25 sgallagh: the document that describes the eol ? the thing dnf could download/parse? 19:51:49 OK, I was just making sure I knew what you meant. 19:51:58 and a way for maintainers to sumbit chnages to that thing 19:52:03 "Proposed new modulemd document: " 19:52:20 I was assuming it would be in a git repo with the other modular defaults 19:52:30 modular obsoletes are implemented in libdnf already, from what I can tell 19:52:31 I haven't followed this effort, so I don't know whether it landed (other than that the module document format is handled by libmodulemd now) 19:52:37 No idea if it's actually consumed anywhere 19:52:42 OK, maybe it is 19:52:53 it was already implemented in January 19:52:54 it's been deferred once already and there doesn't appear to be any real movement, so maybe reject and let them resubmit it? 19:52:56 nirik: that would require a group of people in Fedora that would maintain it 19:53:06 defolos: +1 19:53:14 mhroncok: I think the idea was that it wouldn't be centralized 19:53:18 at least based on this: https://github.com/rpm-software-management/libdnf/commits/dnf-4-master/libdnf/module 19:53:23 well, the change says when eoling or obsoleting a module, maintainers of that module would submit this 19:53:25 defolos: -0, there *has* been movement. It seems most of the work is done. 19:53:32 But would be part of the stream 19:53:34 But I'm not sure. 19:54:03 how about we delegate someone to ask change owners and revisit next week? 19:54:12 Proposal: Defer decision one week. Email mcurlej and find out its status 19:54:17 I think we want this at some point. But it seems rather late to introduce changes to dnf/repos/module structure right before beta. 19:54:21 sgallagh: +1 19:54:40 dmach is the chnage owner 19:54:47 not mcurlej 19:54:52 the bigger problem is nobody maintains MBS right now 19:55:03 with no maintainer of MBS, the server side components can't get implemented 19:55:18 my understanding was that this is exactly the blocker 19:55:23 sgallagh: +1, but I expect to postpone this to F36 unless it's all done are ready now. 19:55:40 sgallagh: +1, but I think it will be moved to F36 19:55:52 iirc, all the DNF work was done, but nobody is there to do MBS stuff 19:55:54 mhroncok: mcurlej seems to be doing the implementation, he's assigned on the ticket. 19:56:13 mbs is maintained by the koji team now 19:56:26 oh dear 19:56:44 They got our mbs upgraded eariler this year... 19:57:15 mhroncok, defolos, decathorpe, dcantrell: vote? 19:57:23 I have no idea how active they are on implementing new features, etc 19:57:25 0 19:57:32 nirik: vote? 19:57:39 0 19:57:41 sgallagh: +1 19:57:56 -1, reject, resubmit, if needed 19:58:10 (Sorry folks for missing one or another person. It's close to 22:00 here, and only a constant stream of very dark tee is keeping me awake.) 19:58:31 decathorpe: I'd +1 that 19:58:40 I'm changing my vote to -1 19:58:58 yeah, save room for me on that bandwagon -1 19:59:04 So I'll follow Fabio Valentini (decathorpe) 's lead 19:59:11 i'm for rejecting 19:59:15 * Eighth_Doctor shrugs 19:59:23 accepting or rejecting basically has no impact 19:59:32 at this point, it's an out-of-band change 19:59:43 we get it whenever MBS gets updated, whether anyone likes it or not 19:59:45 rejecting menas they would need to resumbit to show there is some interest 20:00:15 * zbyszek counts 20:00:17 Eighth_Doctor: is it that rady? 20:00:20 *ready 20:00:30 yep 20:00:39 libmodulemd and dnf already know what to do, more or less 20:00:44 what was the mbs update needed? 20:01:09 well, MBS generates the modules.yaml documents for repodata, and it needs to handle the new fields and validate them 20:01:23 So, we're at +4 to wait one week, and -4 to reject now. 20:01:28 huh, oddly, it's not listed even once on the change page 20:02:13 oh hold up 20:02:19 it's actually done in MBS too 20:02:21 https://pagure.io/fm-orchestrator/pull-request/1667 20:02:28 modulemd v3 is supported 20:03:09 uh, so this thing is done now? 20:03:24 apparently? 20:03:33 I don't think it is "done" 20:03:41 can module maintainers use this? 20:03:51 MBS 3.6.1 was released 4 months ago 20:03:57 if that's in prod, then I guess yeah they can 20:04:18 mmd v3 was added in 3.6.0 20:04:26 This would be nice to know... or have some documentation about it... 20:04:26 well, there still needs to be files somewhere and docs on how to use it, and such 20:04:42 and policies :/ 20:04:45 we are running 3.6.1 since eariler this year. 20:04:55 sgallagh: I think your original proposal was good. We need some input from dmach and mcurlej to make an informed decision. 20:04:55 yeah, so I'd be inclined to say this needs poking for a comprehensive update 20:05:02 because it looks like it's code-complete 20:05:15