14:00:19 <zbyszek> #startmeeting FESCO (2020-07-15)
14:00:19 <zodbot> Meeting started Wed Jul 15 14:00:19 2020 UTC.
14:00:19 <zodbot> This meeting is logged and archived in a public location.
14:00:19 <zodbot> The chair is zbyszek. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:19 <zodbot> The meeting name has been set to 'fesco_(2020-07-15)'
14:00:19 <zbyszek> #meetingname fesco
14:00:19 <zodbot> The meeting name has been set to 'fesco'
14:00:19 <zbyszek> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
14:00:19 <zodbot> 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 <zbyszek> #topic init process
14:00:25 <zbyszek> .hello2
14:00:26 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
14:00:28 <dcantrell> .hello2
14:00:28 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
14:00:47 <King_InuYasha> .hello ngompa
14:00:48 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
14:00:49 <decathorpe> .hello2
14:00:51 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
14:01:03 <nirik> morning
14:01:13 * King_InuYasha groans awake...
14:01:21 <zbyszek> That's quorum, but let's wait a sec for the others.
14:01:52 <zbyszek> 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 <bcotton> .hello23
14:02:00 <bcotton> whoops
14:02:01 <bcotton> .hello2
14:02:02 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
14:02:20 <zbyszek> Hmm, should we start?
14:02:24 <dcantrell> 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 <zbyszek> I have the feeling in recent weeks that Fedora is on fire
14:03:14 <zbyszek> The amount of threads on fedora-devel and elsewhere has been just incredible.
14:03:21 <decathorpe> zbyszek: in a good way or in a bad way?
14:03:26 <zbyszek> In a good way!
14:03:29 <King_InuYasha> :D
14:03:32 <zbyszek> Things are happening.
14:03:37 <dcantrell> I agree, it's good, but definitely a lot of keep track of
14:03:42 <King_InuYasha> my brain hurts reading the rpm macro tickets
14:03:53 <King_InuYasha> which is kind of bad, since I think I'm supposed to understand this stuff
14:03:54 <zbyszek> #topic #2429 F33 System-Wide Change: Make btrfs the default file system for desktop variants
14:03:55 <dcantrell> King_InuYasha: you are not the only one :)
14:03:57 <zbyszek> .fesco 2429
14:03:59 <zodbot> 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 <decathorpe> King_InuYasha: you're not the only one
14:04:06 <zbyszek> dcantrell: you had some doubts iirc?
14:04:15 <zbyszek> (re 2429)
14:04:21 <dcantrell> yes, I'd like to mention my comments here.  give me a sec
14:04:53 <dcantrell> 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 <dcantrell> 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 <dcantrell> 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 <dcantrell> for the most part, I see the change as a positive improvement to the user experience for Fedora workstation users
14:06:05 <dcantrell> King_InuYasha did do a good job explaining those details to me, so thank you
14:06:13 <King_InuYasha> :)
14:06:15 <dcantrell> but what I keep coming back to are two concerns for Fedora overall
14:06:42 <dcantrell> 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 <dcantrell> 2) there are numerous CVEs for btrfs and other bugs that are in our bugzilla that are unresolved
14:07:13 <dcantrell> now, these might not seem like a major problem, but my concern is regarding the what-if scenario for the project
14:07:33 <dcantrell> 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 <dcantrell> what if it's bad enough that we find ourselves back here in a fesco meeting voting to revert the change
14:08:14 <dcantrell> 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 <zbyszek> That is a valid concern, but there is a long list of knowledgable people on the owners list.
14:08:33 <dcantrell> *unless* we have more test results from non-virt users or long time users
14:08:43 <zbyszek> So in the short term we can hope to have a fairly quick response for any bugs raised.
14:08:46 <dcantrell> I agree, there are a lot of knowledgeable users on the list
14:08:52 <dcantrell> I hope so too
14:08:56 <zbyszek> And if the experiment is successfull, I hope we can grow more "in-house" expertise.
14:09:03 <dcantrell> also agreed
14:09:17 <King_InuYasha> so let me see if I can try to answer some of this from my perspective
14:09:24 <zbyszek> But in a way I see this a good development — a major initiative in Fedora driven mostly by outside contributors.
14:09:37 <zbyszek> This is something many of us have been hoping for for a long time.
14:09:43 <dcantrell> that's true
14:09:59 <zbyszek> King_InuYasha: go ahead
14:10:17 <King_InuYasha> 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 <decathorpe> 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 <King_InuYasha> 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 <zbyszek> (I shouldn't have said "outside", I should have said "non-rh", above.)
14:11:17 <nirik> 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 <King_InuYasha> and they have taken bug reports seriously and addressed them very timely
14:11:31 <King_InuYasha> as for (2), I have never seen these, ever
14:11:41 <jforbes> 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 <King_InuYasha> 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 <King_InuYasha> 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 <zbyszek> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=kernel&product=Fedora&product=Fedora%20EPEL
14:13:01 <King_InuYasha> now that we're actively testing it, we *are* finding some, and those are being worked on upstream
14:13:11 <King_InuYasha> so I'm reasonably happy with the responsiveness
14:13:18 <jforbes> CVE-2019-19448 CVE-2019-19378
14:14:44 <zbyszek> CVE-2019-19448 requires a crafted image, which doesn't seem to important...
14:14:49 <dcantrell> 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 <King_InuYasha> 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 <King_InuYasha> which was something he requested multiple times over the years
14:15:14 <dcavalca> 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 <jforbes> 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 <King_InuYasha> jforbes: so perhaps the problem is simply lack of awareness?
14:15:44 <King_InuYasha> jforbes: hmm, okay... again, I defer to josef
14:15:48 <jforbes> King_InuYasha: more importantly, those are CVEs, we got them from upstream
14:16:24 <King_InuYasha> yeah, I get those all the time too
14:16:32 <King_InuYasha> from other projects I maintain
14:16:33 <jforbes> Now, one of them is a fairly crap CVE, I will admit, but CVEs still matter
14:16:51 <zbyszek> 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 <King_InuYasha> 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 <decathorpe> dcavalca: that sounds promising. thanks!
14:16:57 <zbyszek> 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 <josef> 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 <josef> i've already re-organized my entire half's work around fedora issues, so i'm committed to addressing these issues
14:17:35 <King_InuYasha> 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 <King_InuYasha> I think at this point that's the core of the issue
14:18:07 <King_InuYasha> and at least from my perspective a fairly easy fix
14:19:01 <jforbes> 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 <josef> i have the red hat bugzilla alias and there's nothing in it related to btrfs
14:19:21 <josef> i mean i'm fine with looking at CVE's if it helps you with your TPS reports
14:19:21 <King_InuYasha> yeah, it hasn't been used on these bugs
14:19:46 <josef> 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 <zbyszek> josef: see the long link I pasted above, it shows the two CVEs
14:19:53 <jforbes> Yeah, we stopped assigning after it was said the alias wasn't looked at during Plumbers a couple of years ago
14:19:55 <josef> yup i've put them on my list
14:20:10 <josef> yeah at the time fedora wasnt serious about btrfs, and i was deploying it internally inside fb to millions of machines
14:20:10 <King_InuYasha> jforbes: is there a way to make sure btrfs bugs get that CC auto-added?
14:20:17 <josef> so that work took priority
14:20:31 <King_InuYasha> iirc, rhel kernel does this with rules engine or something
14:21:16 <jforbes> 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 <King_InuYasha> jforbes: okay
14:21:39 * King_InuYasha wonders how rhel does it then... must be black magic
14:21:58 <nirik> well, they use subcomponents, so much of that is done by the reporter.
14:22:10 <dcantrell> 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 <jforbes> 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 <jforbes> dcantrell: absolutely
14:22:45 <King_InuYasha> jforbes: ah
14:23:12 <dcantrell> jforbes: ok, that would be great then.  josef, does that work for you and btrfs kernel work for fedora specific bugs?
14:24:52 <dcantrell> 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 <King_InuYasha> sounds like it
14:26:07 <nirik> well, I am not sure we have an unknown number of bugs...
14:26:25 <dcavalca> yeah that works; on our end we'll make sure these get surfaced and prioritized accordingly
14:26:27 <King_InuYasha> it really hasn't been that bad, bug-wise
14:26:28 <dcantrell> I say unknown because jforbes said he stopped adding CC at some point to btrfs-specific bugs
14:26:30 <cmurf> 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 <nirik> 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 <decathorpe> nirik: maybe unknown, but not unknowable :)
14:27:21 <King_InuYasha> and fwiw, I did file a proposal for a flock talk about btrfs
14:27:39 <zbyszek> dcantrell: are your concerns allayed?
14:27:41 <King_InuYasha> and I'm going to try to do fedora magazine writeup as well
14:27:48 <bcotton> 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 <dcantrell> zbyszek: yes, thank you
14:28:11 <nirik> we could do it, but it would require changing our sync scripts.
14:28:20 <nirik> it's not a trivial change
14:28:45 <zbyszek> So... we have +8, 0, -1 votes in the ticket... Does anyone want to adjust?
14:29:53 <jforbes> 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 <King_InuYasha> jforbes: sounds good, thanks for doing that! :)
14:30:23 <zbyszek> Because if not, I think it's reasonable to say that this approved with that vote count.
14:30:50 <decathorpe> jforbes++
14:30:50 <zodbot> decathorpe: Karma for jforbes changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:31:02 <dcantrell> 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 <Conan_Kudo> jforbes++
14:31:10 <zodbot> Conan_Kudo: Karma for jforbes changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:31:22 <zbyszek> Yep, that's certainly a good step.
14:31:46 <Conan_Kudo> josef++
14:31:47 <zodbot> Conan_Kudo: Karma for josef changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:31:47 <zbyszek> OK, any last comments?
14:32:00 <King_InuYasha> I'm good :)
14:32:09 <jforbes> OH
14:32:30 <King_InuYasha> ....?
14:33:01 <jforbes> 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 <King_InuYasha> jforbes: I did expect that, which is why the change proposal is very minimal in terms of anaconda stuff
14:33:41 <jforbes> meaning, I would expect that any anaconda patches required for this will probably need to be developed by someone else
14:33:48 <King_InuYasha> we're already doing this ;)
14:33:55 <dcavalca> so far the only anaconda change required has been https://github.com/rhinstaller/anaconda/pull/2720
14:34:02 <dcavalca> which I wrote and was merged the other day
14:34:07 <jforbes> Cool, just wanted to bring it up as I know sbueno is on pto
14:34:13 <King_InuYasha> and I've got a PR stuck in limbo to fix Fedora IoT...
14:34:25 <King_InuYasha> https://github.com/rhinstaller/anaconda/pull/2728
14:34:32 <dcavalca> as long as anaconda has bandwidth to review and merge PRs, I think we should be good on that front
14:34:37 <King_InuYasha> mostly waiting on figuring out what's broken with compose process to fix it
14:35:12 <King_InuYasha> jforbes: yeah no worries, we accounted for that with this change :)
14:35:39 <zbyszek> #agree APPROVED (+8, 0, -1)
14:35:44 <zbyszek> josef++
14:35:46 <zodbot> zbyszek: Karma for josef changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:35:50 <zbyszek> dcavalca++
14:35:52 <zodbot> zbyszek: Karma for dcavalca changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:35:57 <Conan_Kudo> dcavalca++
14:35:57 <zodbot> Conan_Kudo: Karma for dcavalca changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:36:02 <zbyszek> Conan_Kudo++
14:36:02 <zodbot> zbyszek: Karma for ngompa changed to 11 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:36:25 <zbyszek> I'll ++ the rest of change owners later on, there's too many :)
14:36:30 <King_InuYasha> haha :D
14:36:41 <Conan_Kudo> cmurf++
14:36:46 <Conan_Kudo> chrismurphy++
14:36:50 <Conan_Kudo> mmm
14:36:57 <zbyszek> cmurf++
14:36:58 <zodbot> zbyszek: Karma for chrismurphy changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:37:02 <zbyszek> ignatenkobrain++
14:37:15 <Conan_Kudo> ignatenkobrain++
14:37:30 <Conan_Kudo> I must have given them karma already
14:37:30 <zbyszek> Anyway...
14:37:33 <zbyszek> #topic #2441 F34 System-Wide Change: RPM-level auto release and changelog bumping
14:37:36 <zbyszek> .topic 2441
14:37:38 <King_InuYasha> oh man
14:37:38 <ignatenkobrain> .hello2
14:37:40 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Raits' <igor.raits@gmail.com>
14:37:42 <King_InuYasha> this one hurts my brain
14:37:45 <ignatenkobrain> sorry, I was too late
14:38:00 <zbyszek> Yeah, I'm not ready to engage meanigfully on this one at all. Sorry.
14:38:24 <ignatenkobrain> seems I
14:38:29 <King_InuYasha> does anyone have any idea how this is supposed to work?
14:38:29 <nirik> 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 <ignatenkobrain> I've missed all the fun
14:38:33 <decathorpe> .fesco 2441
14:38:34 <zodbot> 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 <zbyszek> decathorpe: thanks
14:39:20 <zbyszek> So... let's continue the discussion in the ticket and on the mailing list, return to this next week?
14:39:25 <King_InuYasha> yeah
14:39:29 <dcantrell> I don't really understand the benefit of this one compared to the giant FAQ
14:39:31 <nirik> 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 <dcantrell> ok, list it is
14:39:35 <decathorpe> yeah ...
14:39:48 <King_InuYasha> I'm just not prepared to argue for or against it
14:39:54 <nirik> 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 <King_InuYasha> what?
14:40:14 <King_InuYasha> so wait, that means a build has now two manual steps?
14:40:28 <King_InuYasha> before and after?
14:40:47 <nirik> well, the idea was that we get something automatied to do the second part.
14:40:54 <ignatenkobrain> well, nim mentioned on mailing list that this could be done by infrastructure automatically...
14:40:55 <nirik> koji or bodhi.
14:41:01 <ignatenkobrain> except that he is not going to work on it
14:41:14 <King_InuYasha> doesn't that violate some backwards flow thing?
14:41:22 <King_InuYasha> wait... he's not going to implement it?
14:41:27 <nirik> I personally don't like that at all.
14:41:31 <King_InuYasha> then what are we even doing here?
14:41:40 <nirik> but I could be misunderstanding how this works.
14:41:56 <ignatenkobrain> King_InuYasha: well, he implemented the framework, but integration bits are not going to be done.
14:41:58 <nirik> King_InuYasha: he has implemented the macros for this... but not any auto commit stuff
14:41:59 <ignatenkobrain> that's my understanding
14:42:03 <nirik> yeah.
14:42:04 <dcantrell> I'm not really crazy about the part where it says it breaks reproducible builds unless you add "%reproducible_build = true"
14:42:05 <decathorpe> King_InuYasha: I have no idea
14:42:05 <King_InuYasha> I see
14:42:30 <decathorpe> dcantrell: yeah that too
14:42:32 <King_InuYasha> 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 <nirik> so, proposal: push out to next week, try and look it over in more detail before then?
14:42:51 <dcantrell> +1
14:42:52 <zbyszek> nirik: +1
14:42:53 <King_InuYasha> sounds good to me
14:42:54 <King_InuYasha> +1
14:43:08 <decathorpe> +1
14:43:17 <ignatenkobrain> nirik: +1
14:43:34 <nirik> 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 <zbyszek> #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 <King_InuYasha> I need someone to give me "change proposal concept and mechanics for idiots"
14:44:05 <zbyszek> nirik: I took the liberty to paraphrase your proposal :]
14:44:17 <zbyszek> #topic #2440 F33 System-Wide Change: Patches in Forge macros - Auto macros - Detached rpm changelogs
14:44:20 <zbyszek> .fesco 2440
14:44:21 <zodbot> 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 <decathorpe> same as 2441 for me.
14:44:39 <ignatenkobrain> this one is actually prerequisite for the previous one
14:44:41 <King_InuYasha> this one was even more confusing and actually somewhat terrifying
14:44:55 <dcantrell> so this one is more confusing except the title makes sense to me
14:45:09 <dcantrell> I already do this one one package, but not in the manner described (at least as I try to understand this)
14:46:00 <zbyszek> proposal: continue discussion, revisit next week?
14:46:03 <dcantrell> 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 <nirik> yeah, didn't get to this one either
14:46:07 <dcantrell> yeah, next week is better
14:46:11 <King_InuYasha> yup
14:46:29 <King_InuYasha> warning bells about not being able to support srpm generation at the beginning of a mock build scare me
14:46:30 <ignatenkobrain> yeah, I can repeat my -1 next week too :)
14:46:54 <zbyszek> #info We'll continue the discussion in the ticket and on the mailing list and return to this next week
14:47:04 <zbyszek> #topic #2445 Proposal: Make the "shortcut" decision process require a specific request and assent
14:47:04 <dcantrell> King_InuYasha: agreed, don't break mock for me
14:47:07 <zbyszek> .fesco 2445
14:47:08 <zodbot> 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 <zbyszek> bcotton^
14:47:43 * bcotton waves
14:47:46 * nirik wonders if this is just getting too rulesy.
14:48:28 <bcotton> nirik: no such thing as "too rulesy" ;-) (that's a lie, there is such a thing)
14:48:29 <King_InuYasha> probably
14:48:31 <zbyszek> Well, at least in the btrfs case lack of understanding of the rules lead to a disagreement
14:48:31 <dcantrell> I think it clarifies the intent of fast track, which I feel is really best for more procedural things
14:48:57 <nirik> :)
14:49:10 <zbyszek> I think if bcotton adjust the proposal based on the latest comments it would be good improvement.
14:49:19 <ignatenkobrain> I'll abstain, esp. when we do not apply it for -7 votes
14:49:30 * nirik shrugs, sure.
14:50:15 <King_InuYasha> I'm -1 if we don't apply symmetry here
14:50:35 <King_InuYasha> we can't be okay with fast-track-kill and not okay with fast-track-approve
14:50:42 <bcotton> i think we can
14:50:55 <decathorpe> King_InuYasha: actually I do think that -7 votes has different weight than +7 votes
14:50:56 <zbyszek> King_InuYasha: well, OK, I guess it's OK to make symmetrical
14:50:56 <dcantrell> not every ticket is in the same category
14:51:48 <bcotton> 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 <nirik> 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 <King_InuYasha> :P
14:52:21 <zbyszek> bcotton: I accept King_InuYasha's argument. We don't want to seem to hasty with rejecting either.
14:52:29 <ignatenkobrain> nirik: well, infra is faster these days, people can do things faster :D
14:52:31 <King_InuYasha> 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 <zbyszek> 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 <dcantrell> 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 <King_InuYasha> 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 <King_InuYasha> on the negative side
14:53:35 <bcotton> 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 <dcantrell> 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 <King_InuYasha> we could do that, that would satisfy my issue with getting backlogged
14:54:51 <zbyszek> Do we want to add a rule that +9/-9 finishes the vote without futher delay?
14:54:55 <King_InuYasha> yes
14:54:59 <dcantrell> I'm fine with that
14:55:15 <King_InuYasha> if it's unanimous then I think it wouldn't really matter one way or another
14:55:26 <nirik> now you're legislating common sense. ;)
14:55:39 <zbyszek> Yeah, but without such a rule we need to wait another 6 days.
14:55:40 <bcotton> but we don't want +8/-1, for example, to trigger an early decision?
14:55:42 <decathorpe> zbyszek: I was about to suggest this. unanimous votes shouldn't be controversial :)
14:55:49 <bcotton> asking for clarity
14:56:01 <King_InuYasha> I guess that's pretty much it
14:56:15 <zbyszek> +8/-1 means that there's some disagreement, and a potential for the dissenter to convince other people.
14:56:22 <zbyszek> It's quite different from +9/0.
14:56:22 <dcantrell> 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 <bcotton> well nothing prevents an issue from going on the agenda sooner
14:57:00 <zbyszek> dcantrell: We can do that already I think.
14:57:04 <bcotton> (other than being closed already, of course)
14:57:22 <King_InuYasha> and we can always tag stuff for meeting regardless
14:57:27 <dcantrell> zbyszek: should that override fast track approval?
14:58:09 <zbyszek> 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 <decathorpe> 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 <King_InuYasha> yeah
14:58:20 <zbyszek> Yeah, exactly.
14:58:24 <dcantrell> zbyszek: yeah
14:58:38 <King_InuYasha> fwiw, I thought that's how it always worked :)
14:58:44 <bcotton> okay, so let me recap to make sure i understand. we want to:
14:58:46 <King_InuYasha> since nobody tagged meeting, I went with it
14:58:54 <bcotton> 1. keep the symmetry
14:59:11 <bcotton> 2. close unanimous tickets
14:59:26 <bcotton> 3. explicitly say that tagging with 'meeting' is a nack to the fast-track process
14:59:37 <bcotton> is that correct and complete?
14:59:38 <dcantrell> King_InuYasha: you might be assuming we're more organized than we actually are :)
14:59:44 <King_InuYasha> bcotton: yup
14:59:47 <zbyszek> bcotton: yup
14:59:49 <dcantrell> bcotton: correct
14:59:54 <decathorpe> bcotton: sounds good!
15:00:02 <ignatenkobrain> +1
15:00:06 <King_InuYasha> dcantrell: indeed :P
15:00:40 <zbyszek> bcotton: so can you adjust the PR and then we'll approve it in the ticket?
15:00:40 <King_InuYasha> so the "patch" then is that setting meeting deactivates fasttrack
15:01:00 <bcotton> zbyszek: will do. expect an updated PR by the end of my workday
15:01:11 <Conan_Kudo> bcotton++
15:01:20 <zbyszek> #action bcotton to adjust the PR based on discussion
15:01:23 <zbyszek> bcotton++
15:01:24 <zodbot> zbyszek: Karma for bcotton changed to 25 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:01:36 <zbyszek> #topic Next week's chair
15:01:43 <ignatenkobrain> I can do it
15:01:49 <King_InuYasha> awesome :)
15:01:53 <dcantrell> ignatenkobrain++
15:01:54 <zbyszek> #action ignatenkobrain will chair next meeting
15:01:57 <zbyszek> Thanks.
15:02:01 <zbyszek> #topic Open Floor
15:02:58 <zbyszek> nirik: another status update, or are we done with those?
15:03:33 <nirik> I can if you like... the hard part is over, but there's still work to be done.
15:03:45 <zbyszek> Please go ahead.
15:03:54 <nirik> https://fedoraproject.org/wiki/Infrastructure/2020-post-datacenter-move-known-issues
15:04:09 <nirik> so, we are busy reinstalling stuff so we can bring staging back up...
15:04:13 <King_InuYasha> yay
15:04:28 <nirik> we have still to do the rdu2 datacenter parts... hopefully we can unstall that soon.
15:04:47 <nirik> build capacity should be back up to what it was in phx2, or perhaps even better
15:04:47 <jforbes> nirik: I don't see kernel03 on that list, but it doesn't seem up either
15:05:06 <King_InuYasha> wiki looks down, do you know anything about retrace-server and abrt stuff?
15:05:23 <nirik> 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 <King_InuYasha> I found out yesterday in Workstation WG that it's all down?
15:05:26 * nirik can add it.
15:05:50 <nirik> yes, the retrace server is in rdu2... so it's down until we can get those items back online.
15:05:53 <jforbes> thanks
15:05:55 <nirik> the wiki is down? seems fine here?
15:06:04 <King_InuYasha> I'm getting HTTP 503 errors
15:06:16 <decathorpe> hm. it's fine here too.
15:06:21 <King_InuYasha> lovely :(
15:06:44 <King_InuYasha> huh it loaded this time
15:06:57 <nirik> 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 <King_InuYasha> sure
15:07:30 <zbyszek> Let's move on...
15:07:32 <zbyszek> Anyone else?
15:07:37 <zbyszek> nirik++
15:07:37 <zodbot> zbyszek: Karma for kevin changed to 29 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:07:49 <zbyszek> If not, I'll close in a minute.
15:08:00 <zbyszek> nonamedotc++
15:08:00 <zbyszek> rdieter++
15:08:00 <zbyszek> zsun++
15:08:00 <zbyszek> raveit65++
15:08:00 <zbyszek> eeickmeyer++
15:08:01 <zodbot> zbyszek: Karma for nonamedotc changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:08:02 <zbyszek> salimma++
15:08:04 <zodbot> zbyszek: Karma for rdieter changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:08:08 <zodbot> zbyszek: Karma for zsun changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:08:11 <zodbot> zbyszek: Karma for raveit65 changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:08:14 <zodbot> zbyszek: Karma for eeickmeyer changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:08:17 <zodbot> zbyszek: Karma for salimma changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:08:39 <King_InuYasha> nirik: do you know when armv7 test builders will come back?
15:08:47 <decathorpe> I have to admit, it's an impressive list of Change owners
15:08:55 <King_InuYasha> err dev/test packager machines
15:09:16 <King_InuYasha> decathorpe: I think it's our longest owner list on a change :)
15:09:48 <King_InuYasha> though since it's wikitext, I'm not going to dig through and figure that out :P
15:10:01 <zbyszek> Hi Miro!
15:10:07 <King_InuYasha> mhroncok: hey!
15:10:11 <zbyszek> Thank you all, see you next week!
15:10:16 <zbyszek> #endmeeting