15:02:08 #startmeeting FESCO (2018-04-27) 15:02:08 Meeting started Fri Apr 27 15:02:08 2018 UTC. The chair is jsmith. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:08 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:08 The meeting name has been set to 'fesco_(2018-04-27)' 15:02:09 #meetingname fesco 15:02:09 The meeting name has been set to 'fesco' 15:02:09 #chair maxamillion dgilmore nirik jsmith sgallagh bowlofeggs tyll jwb zbyszek 15:02:09 Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:02:09 #topic init process 15:02:16 .hello2 15:02:17 sgallagh: sgallagh 'Stephen Gallagher' 15:02:17 .hello2 15:02:18 .hello2 15:02:19 jsmith: jsmith 'Jared Smith' 15:02:20 .hello2 15:02:23 bowlofeggs: bowlofeggs 'Randy Barlow' 15:02:25 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:02:29 morning 15:02:37 We have quorum :-) 15:02:47 .hello2 15:02:48 i have a work meeting :\ 15:02:49 maxamillion: maxamillion 'Adam Miller' 15:03:06 Let's get started! 15:03:12 #topic #1883 Request for rebase of libdnf/dnf after Fedora 28 GA 15:03:13 .fesco 1883 15:03:13 https://pagure.io/fesco/issue/1883 15:03:15 jsmith: Issue #1883: Request for rebase of libdnf/dnf after Fedora 28 GA - fesco - Pagure - https://pagure.io/fesco/issue/1883 15:03:27 Figured we'd tackle the heavy issue first :-) 15:03:35 I think this was resolved last week? 15:03:40 I don't think there's anything to add. 15:03:49 That wasn't clear from the ticket :-( 15:04:02 jsmith: Yeah, we forgot to update with the resolution until today 15:04:02 Oh, now it is... 15:04:08 OK, moving on... 15:04:09 yeah i think we are waiting on it to go to rawhide and to have an update 15:04:20 #topic #1882 F28 Self Contained Change: java-openjdk 10 - rolling release for Short Term Support releases of OpenJDK 15:04:20 .fesco 1882 15:04:20 https://pagure.io/fesco/issue/1882 15:04:21 jsmith: Issue #1882: F28 Self Contained Change: java-openjdk 10 - rolling release for Short Term Support releases of OpenJDK - fesco - Pagure - https://pagure.io/fesco/issue/1882 15:04:21 i will say that some of the comments about the db format changing concern me 15:04:28 bowlofeggs: Me too... 15:04:43 Also covered last week, right? 15:04:48 I just closed this. 15:04:52 yeah 15:05:06 maxamillion: you forgot to update bugs 15:05:17 #topic #1877 large number of packages FTBFS in F28 15:05:17 .fesco 1877 15:05:17 https://pagure.io/fesco/issue/1877 15:05:20 jsmith: Issue #1877: large number of packages FTBFS in F28 - fesco - Pagure - https://pagure.io/fesco/issue/1877 15:05:25 zbyszek: He has a newborn at home. I think we can forgive him :) 15:05:29 OK, as far as I know, this one *hasn't* been resolved :-) 15:05:32 Oh, right. 15:06:02 I can volunteer to try to fix the nodejs-* packages in the list. 15:06:19 .hello till 15:06:20 tyll_: till 'Till Maas' 15:06:26 zbyszek: I did, I'm so sorry. Completely forgot, that's on me. 15:06:33 not too sure what we can do on this one... 15:06:37 jsmith: We need to have a conversation in the SIG about whether there is sense in having most of those in Fedora at all 15:06:51 Since that's not really how Node upstream works 15:07:06 sgallagh: I know, but.... yeah.... let's have the discussion offline 15:07:07 there was some actions we agreed to two weeks ago 15:07:08 maxamillion: no worries, it was two tickets anyway or something like that. 15:07:14 +1 15:07:16 Thanks 15:07:20 AGREED: till will create a list of FTBFS packages, post it to devel and announce that they will be retired in 6 weeks if not being worked on (+6, 0, -0) (tyll, 15:31:57) 15:07:20 * bowlofeggs till will send a list of FTBFS packages to devel and retire them in 6 weeks (tyll, 15:32:13) 15:07:35 (see zbyszek's comment from 13 days ago) 15:07:41 (the shorter one :)) 15:07:42 yes, this is still on my TODO 15:07:59 tyll: I think there was a releng ticket about the missing FTBFS tickets for F28... but I can't seem to find it. 15:08:08 well, now that f28 is released (almost) we can't really retire them can we? 15:08:11 do we have further need to discuss, or just wait for those proposed actions to take place? 15:08:16 I stand by my comments in https://pagure.io/fesco/issue/1877#comment-505844 15:08:21 yeah we can't retire in f28, but we can in f29 15:08:36 Step one is identifying the broken packages (and hopefully notifying the maintainers) 15:08:54 IMHO we can wait, I will follow-up on this 15:08:59 jsmith: +1 15:09:00 Step two is trying to identify packages with lots of dependencies, or common causes of failures 15:09:01 tyll: +1 15:09:12 zbyszek: yes, I also need to file that one 15:09:15 Step three is work with the SIGs for the language-specific problems 15:09:35 tyll: if you could use a hand in some way, i might be able to help a bit too :) 15:09:40 Proposal: Wait a week or two, tyll to follow up on this 15:09:45 jsmith: +1 15:09:47 sure, +1 15:09:52 +1 15:09:52 jsmith: +1 15:09:53 jsmith: +1 15:09:54 let's make it two weeks 15:09:58 ACK :-) 15:10:01 Ack. 15:10:03 there are a lot of public holidays here 15:10:17 https://pagure.io/fedora-infrastructure/issue/6859 is also related. 15:10:44 #agreed #1877 Wait two weeks, as tyll (perhaps with help from others) will follow up on this (+1:6,+0:0,-1:0) 15:11:01 #info Infra ticket 6869 is likely related 15:11:17 #undo 15:11:17 Removing item from minutes: INFO by jsmith at 15:11:01 : Infra ticket 6869 is likely related 15:11:26 #info Infra ticket 6859 is likely related 15:11:38 bowlofeggs: thank you for the offer, not sure how to properly split it as it does not make sense for each of us to work on 1000 pkgs or so ;-) 15:11:39 Thanks for fixing my typo :-) 15:11:46 #topic #1872 Disable Test Gating requirements until more UI is enabled 15:11:46 .fesco 1872 15:11:46 https://pagure.io/fesco/issue/1872 15:11:51 jsmith: Issue #1872: Disable Test Gating requirements until more UI is enabled - fesco - Pagure - https://pagure.io/fesco/issue/1872 15:11:52 bowlofeggs: Any update here? 15:12:00 bowlofeggs: I'm assuming you're waiting for the freeze to thaw? 15:12:14 jsmith: actually i sorta feel like this ticket is now a holding pattern 15:12:31 jsmith: it's not worth putting the effort into improving the batching UI unless i feel like fesco is going ot approve batching 15:12:42 but, fesco is waiting to vote on batching for those improvements 15:12:48 bowlofeggs: no no... this is not batching... 15:12:50 so... that's not ideal 15:12:54 oooh sorry 15:12:55 hahaha 15:12:59 uh, YES! 15:13:02 there are updates here 15:13:23 pingou and i have been working on a 3.7.0 bodhi release (this very day even) to fix four things 15:13:50 release notes: https://github.com/fedora-infra/bodhi/pull/2331/files 15:13:58 to summarize: 15:14:16 0) missing test names will be displayed in bodhi (useful for waiving) 15:14:43 1) existing waivers will be displayed on an update (there was previously no way to see waivers that had been submitted, not even with wavierdb cli) 15:15:11 2) the waiverDB API call in bodhi will be fixed - this will enable a bodhi UI for waiving updates which i think will help a lot 15:15:50 bowlofeggs: we voted to wait until bodhi-3.6.2 last week. Should we wait for 3.7.0 instead? 15:16:01 3) the cron job that polls greenwave can now run in ~15 minutes instead of 2-3 hours. pingou wants us to increase the polling frequency. this one i feel a little ont he fence about because it hammers our production db 15:16:30 zbyszek: 3.6.2 became 3.7.0 because technically two of these things are features - it's really the same patches just a different version string (bodhi uses semver) 15:16:36 Ah, OK. 15:16:43 so in spirit, it's the same release we discussed before 15:16:49 What about the integration with fedmsg to avoid polling? 15:17:13 zbyszek: we dont' haev that yet, but that is the right approach instead of #3 in my opinion 15:18:03 Even without that, things will be improved a lot. 15:18:04 Proposal: Wait a couple more weeks for the 3.7.0 release 15:18:08 +1 15:18:19 i do think points 0-2 will really help a lot. i'm not sure i'm convinced that we should poll very frequently, though i am glad that the script is more efficient nonetheless 15:18:39 even hourly would be better than now (6 hours) 15:18:40 jsmith: +1 - and i anticipate releasing it next week 15:18:53 nirik: yeah i think pingou was proposing hourly 15:19:13 anyhow, I am +1 to waiting for these... 15:19:18 I'm +1 as well 15:19:23 bowlofeggs: thanks for all the information 15:19:24 that would be a 25% hammering load on the db server. to be fair, we are doing like a 50% hammering load now since it takes 2-3 hours and runs every 6 15:19:37 so if we ran it hourly it would be an improvement over what we currently do 15:19:48 but i still think the fedmsg listener is the proper fix 15:19:56 +1 15:20:06 #agreed #1872 Wait a week or two for Bodhi release 3.7.0 to get the improvements outlined by bowlofeggs (+1:6,+0:0,-1:0) 15:20:18 #topic #1858 Proposed Fedora 29 schedule 15:20:18 .fesco 1858 15:20:18 https://pagure.io/fesco/issue/1858 15:20:20 jsmith: Issue #1858: Proposed Fedora 29 schedule - fesco - Pagure - https://pagure.io/fesco/issue/1858 15:21:43 i'm +1 to sgallagh's proposal 15:21:51 (one day after final freeze) 15:22:11 Hmm, "2018-10-11 (one day after Final Freeze)" is wrong, because freeze is on the 9th. 15:22:22 ah true 15:22:33 sgallagh: should we amend it to 2018-10-10? 15:22:43 uh... Can I blame timezones for that mistake? :) 15:22:50 sure! 15:22:51 haha 15:22:57 sgallagh: US dates, I'd guess 15:23:06 ah, the start of freeze. ok that makes more sense. 15:23:14 But yeah, I meant the 10th 15:23:25 * sgallagh retroactively edits the comment 15:23:44 Proposal: #1858 Use sgallagh's proposal of having AppStream data freeze one day after Final Freeze 15:23:45 +1 to 2018-10-10 for AppStream data 15:23:50 +1 15:23:55 +1 15:24:08 sure, +1... hopefully the people who do this will know to do it then. 15:24:22 nirik: The people who do it are kalev 15:24:26 So... I think we're good 15:25:16 sure, and hopefully he can hand it off if he moves to something else. :) (I like like roles for these things rather than specific people, but thats fine) 15:25:36 jsmith: +1 15:26:23 #agreed #1858 Use sgallagh's proposal of having AppStream data freeze one day after Final Freeze (+1:6, +0:0, -1:0) 15:26:26 Who can update https://fedoraproject.org/wiki/Releases/29/Schedule? 15:26:31 * jsmith assumes that sgallagh is +1 for his own proposal 15:26:43 Yes, I am 15:27:16 zbyszek: The FPM, I would imagine 15:27:18 zbyszek: I think any of us, but I'll do it if you want 15:27:26 Oh, I can do it. 15:27:30 #topic #1884 provenpackager request for itamarjp 15:27:30 .fesco 1884 15:27:30 https://pagure.io/fesco/issue/1884 15:27:33 I'll just update it now. 15:27:34 jsmith: Issue #1884: provenpackager request for itamarjp - fesco - Pagure - https://pagure.io/fesco/issue/1884 15:27:44 FPM can also add it to all the other schedules and such. 15:28:07 i should clarify on this ticket - i wasn't exactly -1'ing the proposal, but i did feel a bit concerned about the bz i linked 15:28:19 nirik: OK, so let's leave it FPM. 15:28:21 i want to be fair and note that that was one and only one example 15:28:25 without -1s I was just going to process this later today.... 15:28:30 it's also the only example i've experienced though 15:28:38 but i also dont' think one example should be a basis 15:28:44 so i'm +0 on this one 15:29:10 it seems like a lot of other people had different experiences than i did, so i'm happy to be outweighed, if that makes sense 15:29:14 While itamarjp can be frustrating at times to communicate with, I have no qualms about his packaging skills 15:29:21 I read the ticket, and I didn't think it was anything more than a simple omission. 15:29:24 OK, so if bowlofeggs isn't -1, then this is solved 15:29:36 right. 15:29:39 And I know he's been very frustrated at waiting for PRs to be acknowledged, let alone acted on 15:30:03 Any last-minute objections? 15:30:14 I think a lot of Fedora packagers still aren't used to that being part of the process either 15:30:30 sgallagh: Good point. 15:30:43 sgallagh: +1 15:30:54 #agreed itamarjp is approved as a Proven Packager 15:31:00 #topic Next week's chair 15:31:11 #1767? 15:31:28 I think there might be value in running a Packager Modernization workshop at Flock around PRs and CI stuff. 15:31:28 zbyszek: Sure... let's get next week's chair, and then we'll do that one next :-) 15:31:39 i can chair 15:31:39 sgallagh: Would love to help with that :-) 15:31:41 it's been a while 15:31:50 #action bowlofeggs to chair the next meeting 15:31:58 new docs would sure help too... but we are working on that. ;) 15:32:17 #topic #1767 F28 Self Contained Changes 15:32:23 .fesco 1767 15:32:23 I can probably take the chair on Star Wars day if we want to book that in advance 15:32:29 jsmith: Issue #1767: F28 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1767 15:32:33 * jsmith will be out on Star Wars day 15:33:01 Is there anything to do here? 15:33:03 proposal: FESCO acknowleges that the Noto Fonts changes were deferred 15:33:07 * nirik is fine that those were deferred. 15:33:08 zbyszek: Is there anything else in this ticket, other than just a note that the Google Noto font changes were deferred? 15:33:19 * jsmith is fine with it too, given the information about disk space required 15:33:20 effectively, they just activated their contingency plan 15:33:21 jsmith: no 15:33:51 +1 to deferral 15:34:14 OK, I think it's duly noted :-) 15:34:27 Or that. 15:34:50 #topic Open Floor 15:35:28 i have a question that i don't have an answer for: i've observed that we often try hard to seek for a unanimous vote even when we have a +5 - is that bad or good or neutral? 15:35:36 I had something, but I'm trying to remember what it was... 15:36:00 bowlofeggs: Seeking consensus is a good thing, IMHO 15:36:11 bowlofeggs: For the procedural items, it doesn't bother me that much. But for other bigger items ,I do like to see a little controversy :-) 15:36:30 maybe you are right, but i can think of three downsides 15:36:40 0) it takes us longer (maybe that's fine) 15:37:02 1) we might be making "weaker" decisions (does that make sense? like, less opinionated decisions i mean) 15:37:32 1) I think you mean "compromises" 15:37:43 2) i wonder if we might be each trying to have a "friendly feeling" group at the expense of voicing controversy sometimes, maybe? 15:37:51 sgallagh: yeah 15:37:55 maybe that's not bad 15:38:00 I think "weak" decisions are good. Almost no decisions are binary, yes/no, but something in between. The fact that everybody is +1 means that all concerns were solved or at least discussed in a satisfactory way. 15:38:01 i just have been thinking about it for a while 15:38:12 yeah true 15:38:24 I absolutely think that controversy should be voiced if it's believed 15:38:31 (And notjust for sake of argument) 15:38:32 yeah and maybe it is 15:38:40 bowlofeggs: I've long since given up on "friendly feelings" in FESCo meetings... If I have something to say, I say it :-) 15:38:46 Because that helps us *reach* a working compromise. 15:38:47 haha 15:38:48 cool 15:38:49 I think reaching concensus is much better 15:38:53 so maybe #2 isn't a real problem 15:39:20 For me it's not -- maybe it is for others. I don't want to put words in anyone else's mouth 15:39:21 cool, well that's all i had to say about that 15:39:38 And yeah, there are definitely places where compromise will never happen because things are truly binary 15:39:52 Even for stuff like "orphan all packages of x", if there's disagreement, this most likely means that something is off, maybe we didn't wait the prescribed time or whatever, and with additional delay everybody will be +1. In that case striving for consensus clearly results in a better outcome. 15:40:04 For example if we were to propose to stop blocking on KDE or Server Edition. 15:40:11 There's really no middle-ground there. 15:40:23 zbyszek: +1 15:40:33 sgallagh: What, no "soft blocks"? 15:40:36 * jsmith ducks and hides 15:40:41 .fire jsmith 15:40:41 adamw fires jsmith 15:40:52 OK, I deserved that :-) 15:41:10 I have something to discuss 15:41:24 tyll: Please, go ahead! 15:41:25 tyll: Go ahead (bowlofeggs said he was done) 15:41:44 Currently we are using one ticket for all Change requests instead of one ticket for each change 15:41:54 Not exactly 15:42:04 We have a single ticket for Self-Contained Changes 15:42:09 And individual ones for system-wide 15:42:14 IMHO this makes things more complicated because the ticket gets very long and it is hard to see what the actual status is 15:42:19 The idea being that Self-Contained ones are usually mass-approved. 15:42:22 ah, I did not realize this 15:42:35 Yeah, we should probably start a new ticket for each batch of self-contained changes. 15:42:42 hi 15:42:45 But yeah, what zbyszek said 15:42:56 Rather than reopening the same ticket every time 15:43:18 yeah i've also had this thought 15:43:25 i think it would be nice if they just each had their own ticket 15:43:38 because discussion in ticket can also be noisy if there ever needs to be any 15:43:49 the plan for self contained was that usually we could just say 'they all look fine' 15:44:00 but we do end up discussing some sometimes 15:44:01 Hey, time for a compromise! 15:44:16 NO! death before multiple tickets! 15:44:16 For any that we end up discussing individually, we split out into its own ticket. 15:44:20 * nirik kids 15:44:32 Leaving the mass-approval ticket as-is. 15:44:48 That will allow us to keep discussion (when warranted) associated with the right items 15:44:53 how do we get this implemented? Do we just need to ask jkurik or is there also some docs that need to be updated? 15:44:57 But then just have one ongoing ticket for rubber-stamped issues. 15:45:09 tyll: I think we just create a new ticket on the fly when debate occurs. 15:45:22 bad news: pagure implements the ticket number as int16_t, we need to conserve the numbers 15:45:34 zbyszek: You're joking, right? 15:45:39 yes ;) 15:45:41 haha 15:45:45 please don't do that! 15:45:57 zbyszek: You had us all worried :-) 15:46:01 zbyszek: Good one! 15:46:24 sgallagh: ok, this sounds good 15:46:35 * nirik is waiting for... now lets discuss ticket ⛄ 15:46:41 sgallagh: I don't think this is going to work, because by the time discussion occurs, there will be multiple comments on the original ticket 15:46:53 Then if we create a new one, discussion will be split. 15:47:37 Well, it's usually US making the comments. 15:47:56 Can't the nine of us remember to create a new issue and just link it in the original ticket? 15:48:25 But hey, if you want to just have separate tickets from the start, I'm not strongly opposed. 15:48:33 sgallagh: Actually, I think it's the FPM that usually creates the tickets :-) 15:48:46 jsmith: I meant when we dissent 15:48:54 To have the conversation in a dedicated ticket 15:49:01 sgallagh: Ah, yeah -- I like that idea better 15:49:08 sgallagh: I wasn't following, but now I see the light :-) 15:49:09 jsmith: Which one? 15:49:17 right, so when we have 10 of them in the ticket and 1 we want to discuss, we say 'those 9 are ok' and make a new ticket for the other one 15:49:25 I love it 15:49:36 sounds fine to me 15:49:56 I'm not convinced, but we can try that for a while and see. 15:50:34 * dgilmore thinks its fine but we should discuss in the change ticket :D 15:50:51 haha 15:50:54 dgilmore: Huh? Then what goes in the new ticket? 15:50:59 dgilmore: a single one or one for each of the proposed versions? 15:51:02 just wondering, in which cases is a single ticket better? 15:51:03 * jsmith is thoroughly confused again... 15:51:12 Is it to make it less work to close it/add the approved stamp? 15:51:14 jsmith: I think dgilmore was making a joke 15:51:16 (I hope) 15:51:41 * zbyszek assumed so too 15:51:41 sgallagh: I was trying to be funny 15:51:47 And would you add a single topic to the meeting for each individual item? 15:52:02 dgilmore: I thought it was funny. Then I started worrying it was serious and got nervouse. 15:52:04 *nervous 15:52:04 Because then it is more work to get through the ticket instead of just query the tickets once 15:52:06 Everyone's a comedian today... 15:52:17 I think we should form a subcomittee to discuss discussing in tickets tickets where we discuss. 15:52:41 Who's going to open a ticket to assign the tickets to the tickets subcommittee? 15:52:50 perdóname jsmith 15:52:54 we need a committee to decide what color of labels we should put on the tickets 15:52:59 and a committee to oversee that committee 15:53:11 * jsmith thinks we're nearing the end of the useful discussion... and lights the fuse 15:53:16 lol 15:53:30 Last chance for open floor discussions... 15:53:45 light the fuse :) 15:53:48 I had some serious questions about it 15:53:49 #info Congratulations on shipping F28! 15:54:06 yesss!!! 15:54:08 Yay! 15:54:12 oh man, first time on-time in how many releases? 15:54:16 ah, yes. tyll did have a couple other questions 15:54:16 We did not get a chance to discuss #1878, but I think it's better to continue the discussion in the ticket. 15:54:20 maxamillion: Ever, according to adamw 15:54:20 tyll: what is your serious questions? 15:54:25 maxamillion: According to adamw on the mailing list... first ever 15:54:26 maxamillion: adamw says the first, on phoronix 15:54:32 just wondering, in which cases is a single ticket better? 15:54:37 Is it to make it less work to close it/add the approved stamp? 15:54:42 tyll: Yes, mainly 15:54:43 And would you add a single topic to the meeting for each individual item? 15:54:47 tyll: likely when it is contentious 15:54:49 Because then it is more work to get through the ticket instead of just query the tickets once 15:55:11 No, we are supposed to mass approve those that make sense and only create individual items for those that have a disagreement raised 15:55:12 tyll: I would think you would work as we have until something had to be seperate 15:55:30 ok 15:55:39 zbyszek: Sorry, didn't see the meeting tag on that one... we already have the concept of "enchilada", maybe we just call it "taco" or "burrito" or something obtuse... 15:55:51 zbyszek: Let's discuss in ticket, and bring up again next week 15:55:55 ? 15:55:56 zbyszek: I don't think there's any rush on it 15:55:58 it would allow moving discussion out of the main 'self contained' ticket 15:56:18 jsmith: yes, agreed. 15:56:30 a good point to make the change woule be in rawhide right after branching 15:56:53 give as long as possible to weed out any issues 15:57:37 Going once.... 15:58:01 Thanks for chairing, jsmith 15:58:03 ... going twice .... 15:58:26 ... and sold to the highest bidder. Thanks everyone! 15:58:29 #endmeeting