14:00:19 #startmeeting FESCO (2020-07-15) 14:00:19 Meeting started Wed Jul 15 14:00:19 2020 UTC. 14:00:19 This meeting is logged and archived in a public location. 14:00:19 The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:19 The meeting name has been set to 'fesco_(2020-07-15)' 14:00:19 #meetingname fesco 14:00:19 The meeting name has been set to 'fesco' 14:00:19 #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 14:00:19 Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek 14:00:22 #topic init process 14:00:25 .hello2 14:00:26 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 14:00:28 .hello2 14:00:28 dcantrell: dcantrell 'David Cantrell' 14:00:47 .hello ngompa 14:00:48 King_InuYasha: ngompa 'Neal Gompa' 14:00:49 .hello2 14:00:51 decathorpe: decathorpe 'Fabio Valentini' 14:01:03 morning 14:01:13 * King_InuYasha groans awake... 14:01:21 That's quorum, but let's wait a sec for the others. 14:01:52 Before we start, I'll say up front that I didn't have time to catch up on the two rpm macro tickets :( 14:01:53 .hello23 14:02:00 whoops 14:02:01 .hello2 14:02:02 bcotton: bcotton 'Ben Cotton' 14:02:20 Hmm, should we start? 14:02:24 zbyszek: that is understandable, I have been reading up on them since yesterday myself 14:02:26 * cverna is around but in another meeting at the same time :( 14:02:49 * nirik definitely hasn't looked at anything added since last night my time 14:02:57 I have the feeling in recent weeks that Fedora is on fire 14:03:14 The amount of threads on fedora-devel and elsewhere has been just incredible. 14:03:21 zbyszek: in a good way or in a bad way? 14:03:26 In a good way! 14:03:29 :D 14:03:32 Things are happening. 14:03:37 I agree, it's good, but definitely a lot of keep track of 14:03:42 my brain hurts reading the rpm macro tickets 14:03:53 which is kind of bad, since I think I'm supposed to understand this stuff 14:03:54 #topic #2429 F33 System-Wide Change: Make btrfs the default file system for desktop variants 14:03:55 King_InuYasha: you are not the only one :) 14:03:57 .fesco 2429 14:03:59 zbyszek: Issue #2429: F33 System-Wide Change: Make btrfs the default file system for desktop variants - fesco - Pagure.io - https://pagure.io/fesco/issue/2429 14:04:05 King_InuYasha: you're not the only one 14:04:06 dcantrell: you had some doubts iirc? 14:04:15 (re 2429) 14:04:21 yes, I'd like to mention my comments here. give me a sec 14:04:53 so first, thanks everyone for bringing this back to the meeting. This one is a big deal to me and I had assumed we would discuss it in the meeting. 14:05:13 I have been talking to kernel people, users, other FESCo members, and really anyone who wanted to mention something about this change 14:05:32 I was pleased to see the test day take place and the number of participants, though it looks like the majority of the tests occurred on virt 14:05:50 for the most part, I see the change as a positive improvement to the user experience for Fedora workstation users 14:06:05 King_InuYasha did do a good job explaining those details to me, so thank you 14:06:13 :) 14:06:15 but what I keep coming back to are two concerns for Fedora overall 14:06:42 1) Fedora has no btrfs people or knowledge within the project; the plan is to defer to FB for support on issues 14:06:56 2) there are numerous CVEs for btrfs and other bugs that are in our bugzilla that are unresolved 14:07:13 now, these might not seem like a major problem, but my concern is regarding the what-if scenario for the project 14:07:33 what if there is a major problem in btrfs that affects Fedora users only. we don't have anyone who can work on that in the project. 14:07:47 what if it's bad enough that we find ourselves back here in a fesco meeting voting to revert the change 14:08:14 that's the concern I have. changing the filesystem should kind of go in one direction for the project and I don't think we have the committed resources in the project to safely make that decision now 14:08:21 That is a valid concern, but there is a long list of knowledgable people on the owners list. 14:08:33 *unless* we have more test results from non-virt users or long time users 14:08:43 So in the short term we can hope to have a fairly quick response for any bugs raised. 14:08:46 I agree, there are a lot of knowledgeable users on the list 14:08:52 I hope so too 14:08:56 And if the experiment is successfull, I hope we can grow more "in-house" expertise. 14:09:03 also agreed 14:09:17 so let me see if I can try to answer some of this from my perspective 14:09:24 But in a way I see this a good development — a major initiative in Fedora driven mostly by outside contributors. 14:09:37 This is something many of us have been hoping for for a long time. 14:09:43 that's true 14:09:59 King_InuYasha: go ahead 14:10:17 at least for (1) cmurf and myself have been doing this and interfacing with upstream linux-btrfs@ for years... Chris for 8+ years and I for the past four 14:10:18 dcantrell: well I have been using btrfs as / since fedora ... twenty-something? but that's outside the scope of the test day, so I didn't enter "been using it for years with zero issues, since ext4 crapped itself before I switched over" 14:10:53 In general I have found that the upstream linux-btrfs@ community has been super responsive to even my dumb user questions (there were quite a few when I started!) 14:11:05 (I shouldn't have said "outside", I should have said "non-rh", above.) 14:11:17 dcantrell: perhaps it's worth sending that cve and other bugs list to the change owners... perhaps they are not aware of them? I only see a few btrfs-progs bugs and like 3 kernel cve's that mention btrfs... might also be a good test... 14:11:18 and they have taken bug reports seriously and addressed them very timely 14:11:31 as for (2), I have never seen these, ever 14:11:41 knowledgable people is not the same as filesystem developers. Josef is on the list, though how he will prioritize fedora bugs and such remains to be seen. 14:12:14 I took over as owner of btrfs-progs in early 2019, and my understanding for the kernel stuff is that Josef (who has been part of Fedora longer than he's been at FB) doesn't generally get CC'd to the kernel ones 14:12:36 at least by the time I took over, I haven't seen many bugs beyond the regular "new version, please update" ones 14:12:49 https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=kernel&product=Fedora&product=Fedora%20EPEL 14:13:01 now that we're actively testing it, we *are* finding some, and those are being worked on upstream 14:13:11 so I'm reasonably happy with the responsiveness 14:13:18 CVE-2019-19448 CVE-2019-19378 14:14:44 CVE-2019-19448 requires a crafted image, which doesn't seem to important... 14:14:49 King_InuYasha: I appreciate you and cmurf's work on handling the btrfs questions and answers. my concern was specifically regarding the kernel bugs 14:15:01 jforbes: I'm going to defer to josef on those, but at least at a glance, I see no attempt to CC the fedora-linux-btrfs alias or josef directly 14:15:10 which was something he requested multiple times over the years 14:15:14 fwiw on the FB side we are committed on making this a good experience for Fedora, and have ramped up staffing to work on the issues that were brought up during the devel disussion and other threads so far 14:15:29 King_InuYasha: we used to do that, until he told us at Plumbers that he didn't even look at them, so we stopped 14:15:32 jforbes: so perhaps the problem is simply lack of awareness? 14:15:44 jforbes: hmm, okay... again, I defer to josef 14:15:48 King_InuYasha: more importantly, those are CVEs, we got them from upstream 14:16:24 yeah, I get those all the time too 14:16:32 from other projects I maintain 14:16:33 Now, one of them is a fairly crap CVE, I will admit, but CVEs still matter 14:16:51 That's a better link: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&classification=Fedora&component=kernel&f0=OP&f1=OP&f2=product&f3=component&f4=alias&f5=short_desc&f6=status_whiteboard&f7=CP&f8=CP&j1=OR&list_id=11221750&o2=substring&o3=substring&o4=s 14:16:54 sure, I'm not disregarding that concern, I just can't specifically speak on it because I don't monitor the kernel 14:16:54 dcavalca: that sounds promising. thanks! 14:16:57 ubstring&o5=substring&o6=substring&product=Fedora&query_format=advanced&short_desc=btrfs&short_desc_type=allwordssubstr&v2=btrfs&v3=btrfs&v4=btrfs&v5=btrfs&v6=btrfs 14:17:01 these cve's only get brought out for these discussions, and its usually teh first time i've seen them, if they are that important then i will add them to my list 14:17:19 i've already re-organized my entire half's work around fedora issues, so i'm committed to addressing these issues 14:17:35 josef, if you are now actively looking at the alias, could the kernel team rely on you seeing them if you're CC'd to them? 14:17:54 I think at this point that's the core of the issue 14:18:07 and at least from my perspective a fairly easy fix 14:19:01 josef: CVEs, even the crap ones are a metric by which things are measured. We track them religiously, as I would guess most distros do 14:19:02 i have the red hat bugzilla alias and there's nothing in it related to btrfs 14:19:21 i mean i'm fine with looking at CVE's if it helps you with your TPS reports 14:19:21 yeah, it hasn't been used on these bugs 14:19:46 historically i haven't paid much attention to it because there's been more pressing issues by people who actually deploy btrfs in production 14:19:46 josef: see the long link I pasted above, it shows the two CVEs 14:19:53 Yeah, we stopped assigning after it was said the alias wasn't looked at during Plumbers a couple of years ago 14:19:55 yup i've put them on my list 14:20:10 yeah at the time fedora wasnt serious about btrfs, and i was deploying it internally inside fb to millions of machines 14:20:10 jforbes: is there a way to make sure btrfs bugs get that CC auto-added? 14:20:17 so that work took priority 14:20:31 iirc, rhel kernel does this with rules engine or something 14:21:16 King_InuYasha: no, it is difficult to automate, but believe it or not, I look at every kernel bz that gets filed. I can assign them if I know it is not just wasting my time 14:21:30 jforbes: okay 14:21:39 * King_InuYasha wonders how rhel does it then... must be black magic 14:21:58 well, they use subcomponents, so much of that is done by the reporter. 14:22:10 jforbes, josef: could the reassignment start happening again so Fedora can hit a single easy BZ query to see open btrfs bugs in Fedora? 14:22:14 King_InuYasha: doing it by package is easy, doing it by kernel subsystem is supposedly not something we have the ability to do in Fedora 14:22:30 dcantrell: absolutely 14:22:45 jforbes: ah 14:23:12 jforbes: ok, that would be great then. josef, does that work for you and btrfs kernel work for fedora specific bugs? 14:24:52 so reading back through this, I feel like we have an unknown number of bugs over, say, the past year. josef has agreed to handle this with his other btrfs work and prioritize Fedora too. and we need to make sure bugs coming in to Fedora are seen by FB. is this right? 14:26:00 sounds like it 14:26:07 well, I am not sure we have an unknown number of bugs... 14:26:25 yeah that works; on our end we'll make sure these get surfaced and prioritized accordingly 14:26:27 it really hasn't been that bad, bug-wise 14:26:28 I say unknown because jforbes said he stopped adding CC at some point to btrfs-specific bugs 14:26:30 in our upcoming "how to file a bug" section in Fedora Btrfs docs we'll ask to use the btrfs alias. I'm on that alias also for a while now. 14:26:32 there's only a few that mention btrfs in the subject... I suppose others could be btrfs bugs we can't find 14:26:37 nirik: maybe unknown, but not unknowable :) 14:27:21 and fwiw, I did file a proposal for a flock talk about btrfs 14:27:39 dcantrell: are your concerns allayed? 14:27:41 and I'm going to try to do fedora magazine writeup as well 14:27:48 jforbes: let's talk later about the subsystem issue. i don't have any context about that, but it might be a glitch we can fix 14:28:07 zbyszek: yes, thank you 14:28:11 we could do it, but it would require changing our sync scripts. 14:28:20 it's not a trivial change 14:28:45 So... we have +8, 0, -1 votes in the ticket... Does anyone want to adjust? 14:29:53 So, all current kernel issues which show up with a simple search are assigned right now, and new ones will be assigned as they come in 14:30:22 jforbes: sounds good, thanks for doing that! :) 14:30:23 Because if not, I think it's reasonable to say that this approved with that vote count. 14:30:50 jforbes++ 14:30:50 decathorpe: Karma for jforbes changed to 3 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:31:02 zbyszek: I'm going to stay a -1. I appreciate the discussion and I like that we have connected up the kernel bug filing to the right people 14:31:10 jforbes++ 14:31:10 Conan_Kudo: Karma for jforbes changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:31:22 Yep, that's certainly a good step. 14:31:46 josef++ 14:31:47 Conan_Kudo: Karma for josef changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:31:47 OK, any last comments? 14:32:00 I'm good :) 14:32:09 OH 14:32:30 ....? 14:33:01 One more thing, which I can't speak for the anaconda team, but when I mentioned this briefly with the anaconda team manager, they don't really have cycles for any anaconda changes ATM 14:33:35 jforbes: I did expect that, which is why the change proposal is very minimal in terms of anaconda stuff 14:33:41 meaning, I would expect that any anaconda patches required for this will probably need to be developed by someone else 14:33:48 we're already doing this ;) 14:33:55 so far the only anaconda change required has been https://github.com/rhinstaller/anaconda/pull/2720 14:34:02 which I wrote and was merged the other day 14:34:07 Cool, just wanted to bring it up as I know sbueno is on pto 14:34:13 and I've got a PR stuck in limbo to fix Fedora IoT... 14:34:25 https://github.com/rhinstaller/anaconda/pull/2728 14:34:32 as long as anaconda has bandwidth to review and merge PRs, I think we should be good on that front 14:34:37 mostly waiting on figuring out what's broken with compose process to fix it 14:35:12 jforbes: yeah no worries, we accounted for that with this change :) 14:35:39 #agree APPROVED (+8, 0, -1) 14:35:44 josef++ 14:35:46 zbyszek: Karma for josef changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:35:50 dcavalca++ 14:35:52 zbyszek: Karma for dcavalca changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:35:57 dcavalca++ 14:35:57 Conan_Kudo: Karma for dcavalca changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:36:02 Conan_Kudo++ 14:36:02 zbyszek: Karma for ngompa changed to 11 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:36:25 I'll ++ the rest of change owners later on, there's too many :) 14:36:30 haha :D 14:36:41 cmurf++ 14:36:46 chrismurphy++ 14:36:50 mmm 14:36:57 cmurf++ 14:36:58 zbyszek: Karma for chrismurphy changed to 5 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:37:02 ignatenkobrain++ 14:37:15 ignatenkobrain++ 14:37:30 I must have given them karma already 14:37:30 Anyway... 14:37:33 #topic #2441 F34 System-Wide Change: RPM-level auto release and changelog bumping 14:37:36 .topic 2441 14:37:38 oh man 14:37:38 .hello2 14:37:40 ignatenkobrain: ignatenkobrain 'Igor Raits' 14:37:42 this one hurts my brain 14:37:45 sorry, I was too late 14:38:00 Yeah, I'm not ready to engage meanigfully on this one at all. Sorry. 14:38:24 seems I 14:38:29 does anyone have any idea how this is supposed to work? 14:38:29 I tried to look at this this weekend, but it was just confusing me... and I haven't had a chance to look at nim's reply yet 14:38:32 I've missed all the fun 14:38:33 .fesco 2441 14:38:34 decathorpe: Issue #2441: F34 System-Wide Change: RPM-level auto release and changelog bumping - fesco - Pagure.io - https://pagure.io/fesco/issue/2441 14:38:55 decathorpe: thanks 14:39:20 So... let's continue the discussion in the ticket and on the mailing list, return to this next week? 14:39:25 yeah 14:39:29 I don't really understand the benefit of this one compared to the giant FAQ 14:39:31 my understanding is that you submit a build with the macros in spec/redhat-rpm-macros and it reads in some .conf files and figures out what the release shoudl be and includes the changelog 14:39:33 ok, list it is 14:39:35 yeah ... 14:39:48 I'm just not prepared to argue for or against it 14:39:54 then you have to go back and commit the new config files to show that it was built for the next cycle 14:40:00 what? 14:40:14 so wait, that means a build has now two manual steps? 14:40:28 before and after? 14:40:47 well, the idea was that we get something automatied to do the second part. 14:40:54 well, nim mentioned on mailing list that this could be done by infrastructure automatically... 14:40:55 koji or bodhi. 14:41:01 except that he is not going to work on it 14:41:14 doesn't that violate some backwards flow thing? 14:41:22 wait... he's not going to implement it? 14:41:27 I personally don't like that at all. 14:41:31 then what are we even doing here? 14:41:40 but I could be misunderstanding how this works. 14:41:56 King_InuYasha: well, he implemented the framework, but integration bits are not going to be done. 14:41:58 King_InuYasha: he has implemented the macros for this... but not any auto commit stuff 14:41:59 that's my understanding 14:42:03 yeah. 14:42:04 I'm not really crazy about the part where it says it breaks reproducible builds unless you add "%reproducible_build = true" 14:42:05 King_InuYasha: I have no idea 14:42:05 I see 14:42:30 dcantrell: yeah that too 14:42:32 yeah, given how much flack we already get about appearing like we don't care about that (it's not true!), I don't want to make *actually* true 14:42:44 so, proposal: push out to next week, try and look it over in more detail before then? 14:42:51 +1 14:42:52 nirik: +1 14:42:53 sounds good to me 14:42:54 +1 14:43:08 +1 14:43:17 nirik: +1 14:43:34 I think there's a lot to like... but there may just be deal breakers... but we might be able to adjust it... 14:43:40 #agree We'll continue the discussion in the ticket and on the mailing list and return to this next week (+6, 0, 0) 14:44:02 I need someone to give me "change proposal concept and mechanics for idiots" 14:44:05 nirik: I took the liberty to paraphrase your proposal :] 14:44:17 #topic #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs 14:44:20 .fesco 2440 14:44:21 zbyszek: Issue #2440: F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs - fesco - Pagure.io - https://pagure.io/fesco/issue/2440 14:44:26 * King_InuYasha dies 14:44:38 same as 2441 for me. 14:44:39 this one is actually prerequisite for the previous one 14:44:41 this one was even more confusing and actually somewhat terrifying 14:44:55 so this one is more confusing except the title makes sense to me 14:45:09 I already do this one one package, but not in the manner described (at least as I try to understand this) 14:46:00 proposal: continue discussion, revisit next week? 14:46:03 I guess my big difference is I'm automating generating the SRPM file upstream and submitted that to koji as a build after checking it in to dist-git, but I do automate the changelog part 14:46:03 yeah, didn't get to this one either 14:46:07 yeah, next week is better 14:46:11 yup 14:46:29 warning bells about not being able to support srpm generation at the beginning of a mock build scare me 14:46:30 yeah, I can repeat my -1 next week too :) 14:46:54 #info We'll continue the discussion in the ticket and on the mailing list and return to this next week 14:47:04 #topic #2445 Proposal: Make the "shortcut" decision process require a specific request and assent 14:47:04 King_InuYasha: agreed, don't break mock for me 14:47:07 .fesco 2445 14:47:08 zbyszek: Issue #2445: Proposal: Make the "shortcut" decision process require a specific request and assent - fesco - Pagure.io - https://pagure.io/fesco/issue/2445 14:47:14 bcotton^ 14:47:43 * bcotton waves 14:47:46 * nirik wonders if this is just getting too rulesy. 14:48:28 nirik: no such thing as "too rulesy" ;-) (that's a lie, there is such a thing) 14:48:29 probably 14:48:31 Well, at least in the btrfs case lack of understanding of the rules lead to a disagreement 14:48:31 I think it clarifies the intent of fast track, which I feel is really best for more procedural things 14:48:57 :) 14:49:10 I think if bcotton adjust the proposal based on the latest comments it would be good improvement. 14:49:19 I'll abstain, esp. when we do not apply it for -7 votes 14:49:30 * nirik shrugs, sure. 14:50:15 I'm -1 if we don't apply symmetry here 14:50:35 we can't be okay with fast-track-kill and not okay with fast-track-approve 14:50:42 i think we can 14:50:55 King_InuYasha: actually I do think that -7 votes has different weight than +7 votes 14:50:56 King_InuYasha: well, OK, I guess it's OK to make symmetrical 14:50:56 not every ticket is in the same category 14:51:48 because, in honesty, the big harm of fast track approve is that it looks like we're not open to dissenting views. i don't think we'd nearly the amount of upset by saying -7 is never going to get to +5, let's just spike it 14:51:49 personally, I find everyone is in too much of a hurry, but thats likely just because I'm old. :) get off my lawn! 14:52:08 :P 14:52:21 bcotton: I accept King_InuYasha's argument. We don't want to seem to hasty with rejecting either. 14:52:29 nirik: well, infra is faster these days, people can do things faster :D 14:52:31 bcotton: my problem is that if we have something like nim's where it might be foundational and it gets -7 without a chance for discussion 14:52:52 And rejecting things generally doesn't require too much hastiness too. In most cases status quo is maintained until the vote is done. 14:52:52 bcotton: agreed, with fast track approve for everything then we converge fesco approval on all of the members that all work in the same time zone adding +1 (or awake at the same hours), which kind of defeats the whole purpose of discussion as a group and voting and meetings 14:53:06 if we're going to penalize my fast-track-approve on btrfs, we could equally do the same to nim's spec macro goop changes 14:53:10 on the negative side 14:53:35 i don't have a strong opinion on symmetry either way. so y'all decide which you like better and i can update my proposal accordingly :-) 14:54:15 we can still keep things out of the meeting agenda via fast track if we still adhere to the week minimum ticket open policy 14:54:43 we could do that, that would satisfy my issue with getting backlogged 14:54:51 Do we want to add a rule that +9/-9 finishes the vote without futher delay? 14:54:55 yes 14:54:59 I'm fine with that 14:55:15 if it's unanimous then I think it wouldn't really matter one way or another 14:55:26 now you're legislating common sense. ;) 14:55:39 Yeah, but without such a rule we need to wait another 6 days. 14:55:40 but we don't want +8/-1, for example, to trigger an early decision? 14:55:42 zbyszek: I was about to suggest this. unanimous votes shouldn't be controversial :) 14:55:49 asking for clarity 14:56:01 I guess that's pretty much it 14:56:15 +8/-1 means that there's some disagreement, and a potential for the dissenter to convince other people. 14:56:22 It's quite different from +9/0. 14:56:22 I think a "noise meter" should also be used. High profile issues that have generated a lot of traffic on devel should be put on the meeting agenda 14:56:47 well nothing prevents an issue from going on the agenda sooner 14:57:00 dcantrell: We can do that already I think. 14:57:04 (other than being closed already, of course) 14:57:22 and we can always tag stuff for meeting regardless 14:57:27 zbyszek: should that override fast track approval? 14:58:09 dcantrell: so maybe let's add a subrule that if 'meeting' is set, we don't fast-track even if there's +9? 14:58:11 if somebody tags a ticket with "meeting" I would assume that it would get discussed at the next meeting before a final decision is reached ... 14:58:18 yeah 14:58:20 Yeah, exactly. 14:58:24 zbyszek: yeah 14:58:38 fwiw, I thought that's how it always worked :) 14:58:44 okay, so let me recap to make sure i understand. we want to: 14:58:46 since nobody tagged meeting, I went with it 14:58:54 1. keep the symmetry 14:59:11 2. close unanimous tickets 14:59:26 3. explicitly say that tagging with 'meeting' is a nack to the fast-track process 14:59:37 is that correct and complete? 14:59:38 King_InuYasha: you might be assuming we're more organized than we actually are :) 14:59:44 bcotton: yup 14:59:47 bcotton: yup 14:59:49 bcotton: correct 14:59:54 bcotton: sounds good! 15:00:02 +1 15:00:06 dcantrell: indeed :P 15:00:40 bcotton: so can you adjust the PR and then we'll approve it in the ticket? 15:00:40 so the "patch" then is that setting meeting deactivates fasttrack 15:01:00 zbyszek: will do. expect an updated PR by the end of my workday 15:01:11 bcotton++ 15:01:20 #action bcotton to adjust the PR based on discussion 15:01:23 bcotton++ 15:01:24 zbyszek: Karma for bcotton changed to 25 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:01:36 #topic Next week's chair 15:01:43 I can do it 15:01:49 awesome :) 15:01:53 ignatenkobrain++ 15:01:54 #action ignatenkobrain will chair next meeting 15:01:57 Thanks. 15:02:01 #topic Open Floor 15:02:58 nirik: another status update, or are we done with those? 15:03:33 I can if you like... the hard part is over, but there's still work to be done. 15:03:45 Please go ahead. 15:03:54 https://fedoraproject.org/wiki/Infrastructure/2020-post-datacenter-move-known-issues 15:04:09 so, we are busy reinstalling stuff so we can bring staging back up... 15:04:13 yay 15:04:28 we have still to do the rdu2 datacenter parts... hopefully we can unstall that soon. 15:04:47 build capacity should be back up to what it was in phx2, or perhaps even better 15:04:47 nirik: I don't see kernel03 on that list, but it doesn't seem up either 15:05:06 wiki looks down, do you know anything about retrace-server and abrt stuff? 15:05:23 jforbes: ah yeah, thats on our list for this week... I sure hope we can bring it up. I think it had some failed drive or something, but we will get it working 15:05:25 I found out yesterday in Workstation WG that it's all down? 15:05:26 * nirik can add it. 15:05:50 yes, the retrace server is in rdu2... so it's down until we can get those items back online. 15:05:53 thanks 15:05:55 the wiki is down? seems fine here? 15:06:04 I'm getting HTTP 503 errors 15:06:16 hm. it's fine here too. 15:06:21 lovely :( 15:06:44 huh it loaded this time 15:06:57 King_InuYasha: can you curl or look at headers? it would say what proxy it was hitting... 15:07:04 * nirik can look for proxies with issues. 15:07:10 sure 15:07:30 Let's move on... 15:07:32 Anyone else? 15:07:37 nirik++ 15:07:37 zbyszek: Karma for kevin changed to 29 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:07:49 If not, I'll close in a minute. 15:08:00 nonamedotc++ 15:08:00 rdieter++ 15:08:00 zsun++ 15:08:00 raveit65++ 15:08:00 eeickmeyer++ 15:08:01 zbyszek: Karma for nonamedotc changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:08:02 salimma++ 15:08:04 zbyszek: Karma for rdieter changed to 6 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:08:08 zbyszek: Karma for zsun changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:08:11 zbyszek: Karma for raveit65 changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:08:14 zbyszek: Karma for eeickmeyer changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:08:17 zbyszek: Karma for salimma changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:08:39 nirik: do you know when armv7 test builders will come back? 15:08:47 I have to admit, it's an impressive list of Change owners 15:08:55 err dev/test packager machines 15:09:16 decathorpe: I think it's our longest owner list on a change :) 15:09:48 though since it's wikitext, I'm not going to dig through and figure that out :P 15:10:01 Hi Miro! 15:10:07 mhroncok: hey! 15:10:11 Thank you all, see you next week! 15:10:16 #endmeeting