15:00:02 #startmeeting FESCO (2020-06-01) 15:00:02 Meeting started Mon Jun 1 15:00:02 2020 UTC. 15:00:02 This meeting is logged and archived in a public location. 15:00:02 The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:02 The meeting name has been set to 'fesco_(2020-06-01)' 15:00:02 #meetingname fesco 15:00:02 #chair nirik, ignatenkobrain, decathorpe, zbyszek, bookwar, sgallagh, contyk, mhroncok, dcantrell 15:00:02 The meeting name has been set to 'fesco' 15:00:02 Current chairs: bookwar contyk dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek 15:00:05 #topic init process 15:00:05 .hello2 15:00:06 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:09 .hello2 15:00:10 .hello2 15:00:10 bookwar: bookwar 'Aleksandra Fedorova' 15:00:11 .hello psabata 15:00:13 dcantrell: dcantrell 'David Cantrell' 15:00:16 contyk: psabata 'Petr Šabata' 15:00:22 .hello churchyard 15:00:23 mhroncok: churchyard 'Miro Hrončok' 15:00:34 .hello2 15:00:35 decathorpe: decathorpe 'Fabio Valentini' 15:00:36 morning 15:00:39 .hello2 15:00:40 ignatenkobrain: ignatenkobrain 'Igor Raits' 15:00:45 We have quorum. 15:01:01 We have just one ticket, so this should be quick ;) 15:01:04 .hello2 15:01:05 sgallagh: sgallagh 'Stephen Gallagher' 15:01:09 #topic #2114 What is the scope of Modularity? 15:01:09 .fesco 2114 15:01:12 zbyszek: Issue #2114: What is the scope of Modularity? - fesco - Pagure.io - https://pagure.io/fesco/issue/2114 15:01:35 I am going to produce a policy document, though I haven't had an opportunity to do so yet 15:02:22 OK. So do we want to just wait for that? Is there something we should discuss here? 15:02:33 I think we should wait for sgallagh's document 15:02:38 ideally we can have some time to read it before the meeting 15:02:40 * nirik is fine waiting 15:02:50 sgallagh: thank you, btw, for taking that on 15:02:50 so, no votin on the current proposals? 15:02:56 Also, contyk told me this morning that the Council is also discussing this topic on Wednesday 15:03:14 there has been 0 input form the new modularity team 15:03:15 mhroncok: I don't think we should vote today if there's the document in preparation 15:03:45 mhroncok: Yeah, I've been talking with them since last week. They're preparing a formal statement which I'd hoped would be ready before this meeting, but it's still being edited. 15:03:53 Yeah, the software management / modularity team is going to present the plan at the Wednesday meeting. 15:04:13 contyk: counil meeting? is it public? 15:04:23 Yes, they're all public. 15:04:56 bcotton: It's this Wednesday, right? 15:05:04 next week 15:05:18 Okay, I stand corrected. And that statement delay is on me. 15:05:20 #link https://fedoraproject.org/wiki/Council/Video_Meetings 15:05:30 thanks 15:05:40 I don't want to get ahead of things, but the Council will be talking about module policy and coming to a decision? What then is FESCo's role? 15:05:49 or should I just wait until the meeting? 15:06:05 i don't think Council intends to set a policy here, at least not at this point 15:06:06 The Council doesn't provide technical direction. 15:06:07 dcantrell: I don't want to put words in their mouths 15:06:24 ok 15:06:29 But the Council is responsible for the overall direction of Fedora. FESCo is then responsible for executing on that vision. 15:06:54 If the Council tells us "Modularity was a nice try, but we're going in another direction", I'll abide by that. 15:07:05 ok, I'll wait for the meeting 15:07:35 I would like to discuss a related question though 15:07:36 It does feel strange to have this statement before the Council, since FESCo is the place to discuss technical aspects, and in fact we've been discussing this particular one for months/years, but OK. 15:08:03 Specifically, the request to allow default streams for ELN 15:08:05 zbyszek: I feel modules have become political enough to require the Council to discuss it 15:08:16 dcantrell: that is a good argument 15:08:25 dcantrell++ 15:08:25 sgallagh: Karma for dcantrel changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:09:04 sgallagh: I think we should wait until after Wednesday next with this too then. 15:09:23 I agree. 15:09:35 Yes, thank you. 15:09:36 zbyszek: Could I have a couple minutes to make my case? We can defer any decisions as you see fit. 15:09:43 sgallagh: go ahead 15:09:48 Thanks 15:10:02 I should clarify, this is touching on two interrelated topics: 15:10:31 The presence of default streams in ELN and the larger question of "who makes decisions for ELN"? 15:11:09 Since the (valid) question was raised as to whether ELN is a Fedora project or a Red Hat project using Fedora's infrastructure. 15:11:48 I think calling it a Red hat project using Fedora infrastructure is sentencing it to failure 15:11:57 we should consider ELN a part of Fedora 15:12:05 My perspective on this topic is that I want it to be a Fedora project, ultimately beholden to FESCo 15:12:19 sgallagh++ 15:12:29 * nirik nods. 15:12:31 I think you've been telling us that "ELN is fedora", but ELN is also what will become RHEL at some point, so there's definitely overlapping interests here. 15:12:32 But I also want FESCo to grant it a measure of leeway that classic Fedora doesn't have 15:12:44 Does the ELN SIG "formally exist" yet? 15:13:00 What does that mean? 15:13:11 https://fedoraproject.org/wiki/SIGs/ELN 15:13:23 Since it's an entirely non-default set of repositories, I'd like to have FESCo's permission to have greater reign to experiment 15:13:35 decathorpe: Insofar as any SIG formally exists, yes 15:13:51 I think it would be sensible to defer some decisions to the members of the ELN SIG 15:13:52 The primary members at this moment are bookwar, contyk and myself. 15:14:05 sgallagh: the wiki says otherwise 15:14:32 So it does; I forgot to add contyk's name and it seems that Justin added his own :) 15:14:43 how do we defer some decisions to the members of the ELN SIG, when we don'T have an established process of being the member? how does the sig take the decision? 15:14:44 I will correct that 15:15:07 sigs are not formal groups... they are functional groups that do things. 15:15:08 a problem I have with granting ELN special exceptions from the process is we lose the ability to hold groups accountable. on the topic of default streams, we keep talking about a module policy. the group owning modules now has not commented. should we not hold them accountable for this requirement in order to proceed rather than proceed without it? 15:15:22 mhroncok: I am not aware of other SIGs that are required to have formal governance 15:15:33 Unless you're suggesting we should treat ELN as an Edition? 15:15:39 sigs do not have any formal governenace. 15:15:40 mhroncok: the same way as it works with other SIGs, people who do the work decide on what this work is going to be about 15:15:52 sgallagh: becasue they don't have the freedom you advocate for here 15:16:11 We could make ELN an edition. 15:16:12 dcantrell: i don't see a special exception in this 15:16:19 It would actually make sense, I think. 15:16:29 contyk: I disagree, honestly. 15:16:31 editions are/were more a council thing... 15:16:31 mhroncok: freedom of what? 15:16:32 ELN as an edition does make more sense to me 15:16:43 if I want default modular stream enabled in say, Python Classroom Lab, who do i go for? FESco or Python SIG? 15:16:47 dcantrell: i disagree 15:16:52 (and I'm thinking in terms of making ELN more accessible to developers) 15:16:56 Editions have to be approved by the Council and they're intended to be things that we're actively promoting to users. 15:17:18 mhroncok: whoever maintains classroom lab... is that python sig? 15:17:21 ok, so something slightly more formal than a SIG but not as formal as an Edition then 15:17:28 Whereas ELN is really intended as a developer space 15:17:37 we haven't proposed ELN as edition, we proposed ELN as experimental development playground 15:17:40 nirik: yes. so if I maintain the classrrom lab, can I have default modular streams there, just becasue I want to? 15:17:59 nirik: w/out fesco approval taht is? 15:18:02 *that 15:18:09 mhroncok: nope, not default ones... because they build on the fedora infra that has modular stream set 15:18:21 eln builds on fedora infra 15:18:28 mhroncok: *technically* there's actually a way to do that, but we've never pushed for it in Fedora. 15:18:36 And I probably wouldn't. 15:18:41 I don't understand why the Fedora policy for default modular streams should nto apply to eln, sorry 15:18:46 mhroncok: if you have a spin, you can add whatever you want from Fedora to that spin as default set of packages, and fesco is not involved in that decision 15:18:52 yes, but it's not the same to me at least... it's a seperate development stream. 15:19:10 mhroncok: Because ELN's stated purpose is to more closely match RHEL. RHEL has (and needs) default streams. 15:19:40 sgallagh: what rhel are you talking about? 15:19:42 nirik: I think you're making his point: Spins don't get to make that decision, ergo ELN is asking for more privileges than a Spin 15:19:43 also in fedora we say you shouldn't override opt flags, but we allow eln to change those? 15:19:53 mhroncok: "The next one" 15:20:01 closely match RHEL, not mirror it 15:20:02 sgallagh: isn't EL what is supposed to be next RHEL that is somewhat managed by Fedora? 15:20:03 perhaps. 15:20:13 sgallagh: the next rhel has (and needs) default streams? 15:20:26 to em ELN should be the next rhel 15:20:30 now I get this backwards 15:20:36 *me 15:20:47 mhroncok: Sorry, I think you lost me 15:20:53 I think I had 15:21:00 Are you suggesting we should use ELN to force RHEL not to use module default streams? 15:21:10 sgallagh: no 15:21:11 Because I'm pretty sure that wouldn't fly. 15:21:12 Yeah, what mhroncok said. If Fedora doesn't have default streams, then it's at least likely that next RHEL should not have either. 15:21:29 Fedora doesnẗ ahve (not it needs) default modular streams 15:21:31 sgallagh: perhaps? What zbyszek said basically 15:21:32 well, my understanding (I could be wrong) is not that ELN requires default streams, but that in order to experement and see if default streams are going to be something used, they need to be able to enable them and experement 15:21:46 there's no technical requirement for modules, it's a business requirement. if Fedora is where we're building the next RHEL, then we should improve on the ideas that went in to RHEL8. if that's modules, fine, but it might not be. 15:21:49 nirik: +1 15:21:55 nirik: That's roughly what I'm trying to say, yes. 15:21:58 nirik: we have already experimented. the answer is no 15:22:18 I'm with dcantrell 15:22:29 nirik: also pretty much all experimentation with streams can be done without default streams. There's plenty of stuff to fix before the question of default streams is reached. 15:22:33 but now there's a new group (dnf team) that would like to do so in a less disruptive place than fedora. 15:22:35 wither Fedora wants and needs default modular streams, hence ELN needs and wants them and hence RHEL needs and wants them 15:22:49 or there is a split somewhere, a "fork", downsytream only behavior 15:23:11 I will also add that if it's modules, FESCo needs to see the policy for modules and what the modularity owners plan to do 15:23:12 mhroncok: no, we have broken Fedora, so the we decided that we shouldn't experiment on Fedora release, ELN allows us to experiment without breaking anything but ELN 15:23:14 nirik: the dnf team wants default mdoular streams in eln? 15:23:28 zbyszek: That statement is not true, but there are enough workarounds that we can make it *mostly* true if we had to 15:23:35 mhroncok: that is not at all what I said. And I don't speak for them 15:23:57 bookwar: not correct. if we enbale default modualr streams in eln, some RH maintainers will only maintain their modules, not fedora nonmodular content (we have seen that happen before) 15:24:12 exactly, this is my worry too. 15:24:12 mhroncok: There are several internal teams that want modules in ELN 15:24:23 Because they intend to ship them that way for RHEL 9 15:24:29 yeah, thats a definite worry 15:24:45 And they do not want to be maintaining things differently in Fedora and RHEL. 15:24:58 sgallagh: Then it would be great if those teams explained their cases and reasoning and needs in the ticket. 15:25:03 (Which is to be read as: if they can't build their modules in Fedora, they will not do their work in Fedora) 15:25:08 this goes back to there needing to be a policy and accountability for maintenance 15:25:29 Right now they are completely invisible in the public discussion that we're having. 15:25:35 if they don't want to maintain things differently in Fedora and RHEL, they have basically 2 options: don't do modules, or help modules succeed in Fedora 15:25:39 zbyszek: I will not list names, but at least one of those people has told me they refuse to do so because there are too many angry voices shouting things down in Fedora. 15:25:43 mhroncok: you are trying to force something on RHEL maintainers. You think that if you don't allow streams in ELN you dictate RHEL to stop using modules. This is not what's going to happen. 15:25:54 since modularity had moved nowhere since at least November, it seems liek we ar ekickign a dead hore here 15:26:01 We are not choosing for RHEL where the contribution goes. We are choosing for Fedora, either we accept downstream to work with Fedora, or force downstream to diverge further. 15:26:07 bookwar: I couldn't care less 15:26:18 bookwar: I care about Fedora here 15:26:30 why is there apprehension to a module policy and holding the modularity team accountable for that? 15:26:38 is there some way to engage with these folks and see if we can find some way for them that isn't modularity? 15:26:42 mhroncok: But not enough to allow us a place to fix bugs and get things working? 15:26:54 nirik: eln is the way 15:26:58 bookwar: Every time we set a policy for Fedora, you could say that we turn away potential contributors who don't like the rule. That's just how it is. 15:27:02 bookwar: allowing default modular stream for ELN now will hurt Fedora. that is my opinion. you might have a different opinion, but don't tell me what i want please 15:27:36 sgallagh: what things? 15:27:50 mhroncok: that's not true, allowing default streams in ELN may allow us to fix modularity in Fedora 15:28:00 mhroncok: Things like how default streams actually work. How they upgrade. How they interact with other default streams. 15:28:02 bookwar: who's fixing it? how? 15:28:07 The question if Fedora needs Modularity. 15:28:08 mhroncok: ELN SIG 15:28:29 So your thinking is if those teams can't maintain modules in Fedora at all, be it Fedora proper or ELN, they will be forced to develop something they won't ultimately be able to consume? 15:28:36 bookwar: re " allowing default streams in ELN may allow us to fix modularity" — there's no evidence of that whatsoever. 15:28:39 bookwar: ELN SIG is going to fix modularity? 15:28:39 ignatenkobrain: no, the question is - can we get a working prototype of Modulrity on the side, so that we can actually decide if Fedora needs it 15:29:02 bookwar: sure, but why would it be called next RHEL? 15:29:07 zbyszek: There's also no evidence that allowing default streams in ELN would harm Fedora, but that's the cornerstone of your counter-argument. 15:29:15 mhroncok: yes, if modules break ELN compose, it is up to ELN SIG to resolve it or to remove the modules from ELN 15:29:18 contyk: they can maintain modules just fine 15:29:23 contyk: not default streams 15:29:29 Why not to provide 3rd party builds and such to prove that we have a working aolution 15:29:35 sgallagh: history suggests that this is what will happen 15:29:56 zbyszek: HOW? 15:30:06 History suggests that the one stack that tried default streams imploded 15:30:09 No one will be running ELN without knowing what they are doing. 15:30:19 ignatenkobrain: that's exactly what ELN can do 15:30:24 It's not going to appear on anyone's machine without their opt-in 15:30:45 ignatenkobrain: You literally just described replacing ELN with... ELN 15:31:00 I assume the decision that ELN needs default modular streams is already set, right? 15:31:05 decathorpe: In Fedora, sure. In RHEL we have a dozen, all working fine. 15:31:09 is the core of the issue the fact that ELN is perceived as RHEL next? 15:31:24 sgallagh: yes, that's the problem. they work in RHEL but they imploded in fedora. 15:31:25 again, my concern is the policy. what we've seen already is that things go modular-only which then forces the hand of non-modular packages with regards to dependencies (either build time or run time) and there's no policy that says what happens to regular packages if a module is created that consumes those packages 15:31:28 mhroncok: to make EL-like compose we need modules in ELN 15:31:36 would the discussion be different if the target was: module-experimentation? 15:31:37 talking to the maintainers who you say want default modules, asking what they atually want, is not going to happen? 15:31:40 right now the policy is up to the maintainer and everyone picks the minimal amount of work 15:31:48 decathorpe: And a large part of that was due to insufficient documentation and communication. That's known and understood 15:32:11 mhroncok: we can go without it, but then the usefullness of ELN will be reduced by 50% and we won't get the chance to work on modularity in Fedora 15:32:32 * decathorpe wonders where those RH package maintainers disappeared to ... 15:32:39 much like BSD calling the GPL "viral", dependency problems make modules "viral" 15:32:41 bookwar: but you can have non default modules no? what more does default get you? 15:32:43 I'm worried that without defaults and the unneccessary divergence of ELN and RHEL, ELN becomes somewhat pointless and the efforts will move elsewhere, such as CentOS. 15:32:53 nirik: modules in buildroot 15:32:55 bookwar: if 50 % usefulness of ELN is in default modular streams, I feel kinda tricked that this was not proposed in the ELN change roposal 15:32:58 Which might result in exactly what you're trying to avoid. The maintainers not working on Fedora. 15:32:58 bookwar: Which, of course, is the actual goal here: death by a thousand cuts to remove Modularity rather than fix it. 15:32:58 *proposal 15:33:00 pingou: I think so, and in that case I would like it to happen outside of fedora build infrastructure and then once ready, we can go case by case and see if it is good fit for Fedora 15:33:47 It is also possible that there are RHEL maintainers who would like to bring non-modular packages to rawhide, and ELN would allow them to do this. 15:33:54 mhroncok: that's why we discuss it here 15:33:58 mhroncok: No deception was intended there. 15:34:01 No one's stopping them from doing that. 15:34:04 well, not without more work, but ok... 15:34:08 Both groups right now are purely hypothetical and anecdata. 15:34:15 But the argument against defaults even in ELN is that those maintainers will not work on non-modular packages. 15:34:20 I would love to see things like FreeIPA and other build-related fixes to work as part of ELN, being tested carefully in advance. That's why I voted for ELN. 15:34:45 ignatenkobrain: they need modules for that too 15:35:19 bookwar: why? 15:35:39 bookwar: so we're back to "Red Hat wants Modularity w/ default streams for RHEL 9, so ELN must have it"? 15:35:46 * nirik suspects we aren't going to come up with consensus on this here today. 15:35:55 * contyk agrees with nirik 15:36:04 I'd like to wait on sgallagh's policy document 15:36:09 * zbyszek too 15:36:26 I will try to work on that between meetings today 15:36:27 And on the stmt next wednesday 15:37:14 I'd also like to hear from all the RHEL maintainers who need default modular streams. 15:37:37 mhroncok: could we ask the dnf team for that info? possibly overlaps with their survey data 15:37:41 i repeat mey statement: RHEL 9 may or may not use modules, Fedora may or may not use modules, but to make this decision we need to unblock modules and try them on the side. ELN is "the side", it was proposed as such, and we'd like to use it as such, and we have people interested in ELN who willing to work on resolving issues there 15:37:44 it's a difficult situation I fear... on the one hand I would like ELN to be able to experement and work on things... 15:37:55 Actually ignatenkobrain's example of FreeIPA and bookwar response shows that the worry about harm to rawhide is real: to fix packages in rawhide those maintainers should be prepared to work on non-modular packages. 15:38:06 dcantrell: the survey data shows that the need for default modular streams and modularity is basically nonexistent 15:38:10 if modules will prove wrong for ELN it will prove them wrong for future RHEL 15:38:22 on the other, if we want alternatives to modules it may be hard to do that if modules are already decided on/being worked on more. 15:38:35 if modules work on ELN - it will make it possible to use them in Fedora 15:38:43 nirik +1 15:39:13 bookwar: but if it will prove them good for RHEL, doesn't mean they will be good fit for Fedora. 15:39:15 RHEL should gradually take the good stuff form Fedora, trough ELN 15:39:19 nirik++ 15:39:19 ignatenkobrain: Karma for kevin changed to 18 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:39:19 mhroncok: noted 15:39:22 that is the realitonship I like to see 15:39:55 what we see here is "RHEL 9 will have modular defaults streams, hence ELN needs them" 15:40:19 proposal: move on the next item 15:40:23 it is is "RHEL 8 will have modular defaults streams, hence Fedora will have them" all over again 15:40:26 zbyszek: +1 15:40:36 RHEL arguments aside, I'd like to see a list of technical points of why Fedora needs or can benefit from modules. So far it's all been about "because RHEL" 15:40:45 dcantrell: +1 15:41:02 dcantrell: +1 15:41:19 mhroncok: we see here "Modularity exists and stuck", and we suggest the opportunity to move forward with it, and get resources to work on it 15:41:59 bookwar: that's the wrong order: first it needs to improve, then it needs to be cemented in by adding default streams. 15:42:01 and every time we suggest to do this - you suggest to do it on the side, and it is what we are proposing 15:42:14 zbyszek: we can not improve things without people working on them 15:42:30 Once default streams are in, technical improvements and any real discussion are over. 15:42:41 ideally in the open, and exposed to latest Fedora, rather than hidden 15:42:56 bookwar: sure, so let people work on this. 15:43:01 perhaps there could be some goal or requirements/test? 15:43:51 also, on the side can mean the modularity group could set up their own koji hub and builders to experiment with this 15:43:59 that is not beyond the realm of possibilities 15:44:02 zbyszek: WE. ARE. NOT. TALKING. ABOUT. DEFAULTS. IN. FEDORA. 15:44:06 dcantrell: why? 15:44:10 We are talking about defaults only in ELN 15:44:18 we had default streams in Fedora, problems existed, were not fixed 15:44:18 Please, no more shadow kojis. 15:44:20 I find the argument that people cannot work on modularity without default stream (in ELN or elsewhere) to have no technical merit. 15:44:21 so we removed it 15:44:36 now you argue that if we enable this in eln, we could fix the problems. 15:44:37 bookwar: to experiment with modules and streams outside of the production fedora koji. it's a suggestion 15:44:42 We removed it, and not much changed since then. 15:44:46 I don't see why it would be any different than last time 15:44:48 zbyszek: Because you elect to ignore all of the technical reasons we provide. 15:45:02 dcantrell: you are pushing out fedora contributors outside of Fedora 15:45:15 bookwar: no, stop, you're missing my point 15:45:36 bookwar: I'd rather leave some contributors out rather than thousands of users 15:45:42 mhroncok: We argue that if we enable it in ELN, we can fix it in ELN. 15:45:46 my suggestion is that dnf and modules need to figure out what they are doing so they don't screw up people's systems. that's what that "needs to be fixed" which means modules need a playground to figure all that out 15:45:48 Again, not bothering the rest of Fedora. 15:45:51 that was tried in fedora and messed up...twice 15:45:55 So your arguments *do not make sense* to me 15:46:17 sgallagh: we were not able to fix it in Fedora when it was enabled in Fedora. what's different now? 15:46:24 zbyszek: again, default stream is the feature which removes the viral nature of Modularity, that very "viral" thing which is the key problem of modularity as technology 15:46:36 mhroncok: Time and a greater understanding of the problems 15:46:53 We backed it out because we couldn't solve those problems in a timeframe that was acceptable to Fedora 15:46:54 if we test modularity without default stream we don't do anything to resolve the main problem 15:47:13 sgallagh: but we are able to fix this in timeline acceptable to ELN/RHEL? 15:47:16 bookwar: I think default streams handling is not only one major problem 15:47:24 bookwar: you get _all of that working_ and then the feature proposal for fedora becomes "we'd like to integrate this working demonstrable thing with production koji because of benefits A, B, and C" 15:47:29 sgallagh: with no changes in modularity for half a year? 15:47:40 ignatenkobrain: it what makes it impossible to work on modularity without breaking things 15:47:51 mhroncok: That's not entirely accurate. 15:47:59 The changes that have been going in are going into DNF 5 15:48:06 if the proposal included a sibling to ELN, would it be viewed differently? 15:48:09 sgallagh: what changes? 15:48:09 They' 15:48:24 pingou: We're not adding yet another build 15:48:25 Can we move to the next topic? 15:48:26 It's unnecessary 15:48:32 contyk: +1 15:48:33 dcantrell: i have that, in ELN, so you are proposing having a second ELN 15:48:35 contyk++ 15:48:35 dcantrell: Karma for psabata changed to 3 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:48:37 mhroncok: The module obsoletes, for one 15:49:38 mhroncok: And we actually fixed the modules-in-the-non-modular-buildroot issue almost a year ago 15:49:39 bookwar: that thing with default streams is a good argument. 15:49:59 Anyway, let's move on. 15:50:08 #topic Next week's chair 15:50:13 volunteers? 15:50:19 I can. 15:50:23 Thanks. 15:50:28 #action contyk to chair next meeting 15:50:48 #topic Open Floor 15:51:08 bcotton: When does this round of elections end? 15:51:23 sgallagh: voting ends at 23:59 UTC on 11 June 15:51:24 I have 1 small (hopefully) item and a dc move update. 15:51:32 nirik: go 15:51:57 #info Please remember to vote (and encourage others to vote) in the FESCo elections before June 11 15:52:13 first... if you all have been following the list, there's a discussion about doing some handling on the review queue tickets. 15:52:28 sgallagh: +1 15:52:38 the author of the new review stats site has submitted a pr to enable his proposal 15:52:41 https://pagure.io/fedora-infra/review_stats/pull-request/6# 15:52:53 I'm not sure if we just want to do this, or have fesco look and approve or ? 15:53:33 IMHO, the things are all good to do... but there was at least one -1 on the list 15:53:48 * mhroncok wasn't following this closely 15:54:10 I think the -1 vote didn't read the whole proposal because I think their objections were actually addressed 15:54:14 I think the policy for mass bug update would work here. In past I have done that, but not remember whether somebody was putting a stamp on it. 15:54:32 But if it needs voting, they get my huge +1 15:54:34 reading now, but I think this is a reasonable improvement 15:54:57 Just wanted to raise awareness mostly. ;) and let someone yell if they saw issues... 15:55:18 I give it a +1 15:55:26 I think the proposed actions are reasonable so +1 from me as well 15:55:37 I'd give it +1 too, but haven't looked into the details. 15:56:17 #action everyone to look at https://pagure.io/fedora-infra/review_stats/pull-request/6 and raise comments if necessary 15:56:18 I don't have time right now to do the deep-dive it would warrant, so I vote 0 (in the "I trust the rest of you" sense) 15:56:21 ok. I'll wait until later today to merge it if anyone wants to comment, please feel free to comment on the PR? 15:56:30 zbyszek: +1 15:56:56 ok, on dc move. we are coming down to the wire. ;) Migration is next week. 15:57:02 nirik: maybe give it two days? It's already evening for many contributors. 15:57:10 zbyszek: sure. 15:57:16 no hurry. 15:58:34 OK, anything else? 15:58:36 We have a detailed plan now... https://hackmd.io/Eqsf5wFoQRGYhAVwSKJvIA starting around like 240ish... I hope to send out a email later today to devel-announce and infrastructure going over that in more general steps 15:59:04 but basically next week there will be outages. Especially tuesday as thats the day we move src/koji/bodhi/etc 15:59:21 we will try and do things as fast as we can, but there will be downtime. ;( 15:59:48 What does "240ish" mean? 16:00:03 line 328. 16:00:05 238 16:00:10 god, can't type today. 16:00:15 I don't see any line numbers ;( 16:00:26 ah, thats in edit mode only. 16:00:26 Are there any mass rebuilds that are still ongoing? 16:00:43 Ah, right, in edit mode I see it. Sorry for the noise. 16:00:44 decathorpe: eln rebuild was kinda stopped in the middle 16:00:47 search 2020-06-01 16:00:51 decathorpe: boost is +- done 16:01:01 decathorpe: python is after the "mass" phase 16:01:12 as far as I know they are all done... 16:01:14 decathorpe, mhroncok I restarted it 16:01:17 decathorpe: nodejs wait for change update 16:01:22 not sure baout perl 16:01:25 (this morning) 16:01:35 sgallagh: is the pytohn 3.9 thing resolved? 16:01:44 mhroncok: It's merged in, isn't it? 16:02:00 sgallagh: yes, but some of eln builds were built with 3.8 already 16:02:09 sgallagh: by the way I've seen a lot of Java builds fail on ELN today, do you know why? 16:02:12 Right, but it should pick those up 16:02:21 decathorpe: I haven't looked at the failures yet 16:02:32 decathorpe: yes, an the java rebuilds 16:02:34 I've been in meetings for four hours straight so far 16:03:16 sgallagh: same, it's a long day 16:03:38 True, let's wrap this up. 16:03:43 Anything else for open floor? 16:03:48 mhroncok: Yeah, I owe an update on the Node.js Change 16:03:48 If not, I'll close in a minute. 16:03:54 I'll add it to the pile 16:04:10 * nirik has nothing else. 16:04:13 * sgallagh looks uncertainly up at it 16:04:45 Actually, I have a small thing: 16:05:21 https://bodhi.fedoraproject.org/updates/FEDORA-2020-dd43dd05b1 failed openqa with an error about obsoletes and provides. 16:05:50 Some help would be appreciated, I'm not sure if I understand what is going on. 16:06:14 I'll check it zbyszek 16:06:14 #endmeeting