15:00:01 #startmeeting FESCO (2018-07-30) 15:00:01 Meeting started Mon Jul 30 15:00:01 2018 UTC. 15:00:01 This meeting is logged and archived in a public location. 15:00:01 The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:01 The meeting name has been set to 'fesco_(2018-07-30)' 15:00:04 #meetingname fesco 15:00:04 The meeting name has been set to 'fesco' 15:00:06 .hello2 15:00:08 #chair nirik, maxamillion, jsmith, jwb, zbyszek, tyll, sgallagh, contyk, bowlofeggs 15:00:08 Current chairs: bowlofeggs contyk jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:00:10 bowlofeggs: bowlofeggs 'Randy Barlow' 15:00:12 #topic init process 15:00:15 .hello psabata 15:00:16 contyk: psabata 'Petr Ĺ abata' 15:00:24 .hello kevin 15:00:25 nirik: kevin 'Kevin Fenzi' 15:00:27 let's see how many people we get today 15:00:28 .hello2 15:00:29 bcotton: bcotton 'Ben Cotton' 15:00:33 are you ready to rumble 15:00:53 .hello2 15:00:54 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 15:01:19 it's unclear whether jakub is coming today 15:01:27 so I'd start with the "new" business and see if he makes it later 15:01:45 I think he doesn't 15:01:50 #topic #1946 Updates process is broken 15:01:54 .fesco 1946 15:01:56 contyk: Issue #1946: Updates process is broken - fesco - Pagure - https://pagure.io/fesco/issue/1946 15:01:58 https://pagure.io/fesco/issue/1946 15:02:11 I'm double-booked, but sort of here 15:02:21 so I put this one on the agenda because at least to me it's unclear what the next steps are 15:02:24 sgallagh: yeah, the same 15:02:39 yeah there's not really a specific proposal here 15:03:09 not sure why the abi check failed... that would be nice to know/fix. 15:03:30 .hello2 15:03:32 jsmith: jsmith 'Jared Smith' 15:04:03 who could investigate? 15:04:16 should this really be a fesco issue? 15:04:59 probably not; we could probably pass it to infra 15:05:24 or QA? 15:05:32 well, kparal asked in ticket... but I havent seen a reply there yet 15:05:53 dodji might be on vacation or something. 15:06:13 so if things had worked, there would have been a failed abi test. 15:06:32 .hello till 15:06:33 tyll: till 'Till Maas' 15:06:38 should we just refile it with the abicheck folks? 15:06:49 is that QA? 15:06:53 yes 15:07:17 proposal: this should be filed with QA instead of FESCo. 15:07:21 +1 15:07:22 +1 15:07:32 +1 15:08:13 +1 15:08:15 +1 15:08:37 jsmith: ? 15:08:49 I guess the problem is anyhow that there needs to be someone willing to work on it 15:08:50 +1 15:08:56 tyll: Agreed. 15:09:06 let the QA figure that out 15:09:29 #agree The issues should be filed with QA instead of FESCo (+6, 0, -0) 15:09:49 did that work? :) 15:09:55 Does #agree work or does it need to be #agreed? 15:09:56 i think so 15:10:00 oh i dunno 15:10:04 * sgallagh has always used the latter 15:10:19 let's try that 15:10:22 #agreed The issues should be filed with QA instead of FESCo (+6, 0, -0) 15:10:30 worst case we'll have it twice 15:10:34 * sgallagh nods 15:10:36 yeah, it's agreed... it doesn't send anything to channel, just the logs 15:10:42 #topic #1945 Nonresponsive maintainer policy: stalled pull requests 15:10:46 .fesco 1945 15:10:48 contyk: Issue #1945: Nonresponsive maintainer policy: stalled pull requests - fesco - Pagure - https://pagure.io/fesco/issue/1945 15:10:52 https://pagure.io/fesco/issue/1945 15:11:02 similar to the previous topic 15:11:13 I wondwe what the next steps for FESCo would be? 15:11:26 I agree with adding PRs to the policy 15:11:34 I also agree that PRs need to be made more visible 15:11:39 preferrably before we update the policy 15:11:55 for the notifications we need to file an infra ticket I believe 15:12:04 It looks like at least "adding to the policy" is approved in the ticket 15:12:10 sure. 15:12:13 Notifications would be a request to infra, yeah 15:12:31 but I think the policy can be updated anyhow since the non-responsive maintainer procedure will act as a notification as long as there is no other notification 15:12:44 that makes sense 15:13:18 There is not too much harm except that maintainers might be surprised to be considered non-responsive which is unfortunate but I do not know of a better word for this 15:13:57 who would be filing the infra request? 15:14:03 tyll: Well, the non-responsive process still requires a direct contact attempt 15:14:05 So I think it's okay 15:14:45 so do we just want a weekly email to maintainers on their outstanding prs? or also to the devel list? 15:14:49 * jsmith_2 had a network outage, and has re-joined 15:15:05 nirik: Is it too much to ask for both? 15:15:21 we can, but it means more devel mail... 15:15:49 * nirik can file the infra ticket, just want to clairify what we want 15:15:58 alright 15:16:04 * jsmith_2 wishes for a developer portal that would highlight all the things that a packager needs to focus on (BZ, PRs, FTBFS, etc.) 15:16:21 proposal: Let's update the policy and nirik will file an infra ticket to make PRs more visible 15:16:33 +1 to contyk's proposal 15:16:51 i don't think we need a devel mail 15:17:03 i think just somethnign like bz's outstanding requests notification would be enough 15:17:31 jsmith_2: yeah, i think that hubs was supposed to make that possible but it got funding pulled 15:18:46 I could go either way... on the one hand devel list mail would let people see who is overworked/has too many outstanding pr's... 15:18:49 I think the implementation can be discussed in the infra ticket 15:18:51 Could we do weekly ones to the maintainers and a monthly one to devel? 15:19:12 sgallagh: Seems like a reasonable compromise 15:19:36 I wonder if this could be a RFE for pagure... 15:20:32 nirik: Not sure I follow -- you mean Pagure send these itself, rather than having an external process query Pagure via its REST API to build the body of the email? 15:20:45 right. 15:20:55 so ie, pagure.io could also send them... 15:21:07 nirik: That's fine with me too 15:21:08 and users could disable that if they didn't want it in their prefs 15:21:37 I can discuss with pingou and figure out where it is best. that doesn't need to be in this meeting. 15:22:01 Sounds good -- let's move on :-) 15:22:17 any more votes on the proposal? 15:22:28 although I could change it a bit to reflect the last bit 15:22:54 proposal: Let's update the policy; nirik will discuss a method of highlighting PRs with pingou 15:23:02 +1 15:23:07 +1 15:23:24 +1 :) 15:23:28 +1 15:23:34 +1 15:23:45 bowlofeggs: ? 15:23:53 +1 15:24:08 #agreed Let's update the policy; nirik will discuss a method of highlighting PRs with pingou 15:24:15 alright 15:24:18 #topic #1935 [Security] Remove packages which has a consistent bad security record from the distribution 15:24:22 .fesco 1935 15:24:24 contyk: Issue #1935: [Security] Remove packages which has a consistent bad security record from the distribution. - fesco - Pagure - https://pagure.io/fesco/issue/1935 15:24:26 https://pagure.io/fesco/issue/1935 15:26:02 So we're dropping Firefox? 15:26:03 for this one, i would like us to consider that not all CVEs are important 15:26:04 * sgallagh ducks 15:26:07 in fact, most probably are not 15:26:44 sgallagh: the kernel is first. ;) 15:26:49 I'd prefer not to make a general proposal on this and instead consider any such cases individually in FESCo 15:27:04 actually, call the above my formal proposal for response 15:27:16 +1 15:27:58 well, who brings cases? whoever is interested I guess? so no systematic list? 15:27:58 sgallagh: yeah i was considering a similar proposal 15:27:59 +1 15:28:09 sgallagh: +1 15:28:29 nirik: In practice, I'd assume the Fedora Security Team 15:28:43 But I figure anyone interested enough should just be permitted to 15:29:01 bet the first one will be Firefox 15:29:03 I'll rephrase my proposal 15:29:38 .members gitfedora-security-team 15:29:39 ignatenkobrain: Members of gitfedora-security-team: dcafaro @ignatenkobrain jtaylor mhayden pjp siddharths @sparks 15:29:40 Proposal: FESCo does not want to set a general policy on this matter but will consider cases on an individual basis when any Fedora contributor raises the issue. 15:30:04 there really isn't an active fedora security team. ;) 15:30:05 +1 15:30:11 sgallagh: +1 15:30:12 +1 15:30:27 nirik: Yeah, I agree -- the security team is not functional at this point in time 15:30:42 sgallagh: +1 15:31:02 tyll: ? 15:31:19 there is currenlty the request for all issues in https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&keywords=SecurityTracking%2C%20&keywords_type=allwords&list_id=9188023&order=changeddate%2Cpriority%2Cbug_id&product=Fedora&query_format=advanced 15:31:33 not sure that we as FESCo want to discuss every one individually 15:32:01 tyll: the problem and question as to production of a non-exempt list remains, though 15:32:15 tyll: I'm going to formally suggest that if they want something reviewed, they need to select important cases and present them 15:32:30 If they ask for a blanket removal, I'll vote "no" 15:32:45 tyll: "This result was limited to 1000 bugs" thats going to take a while. ;) 15:32:49 Might be interesting to order that list based on highest CVSS score.... but otherwise, the list is too long to effectively deal with as-is. 15:33:19 I guess the problem is that it is too much to do manually, therefore they request some kind of cleanup to make it manageable 15:34:04 it is the same with FTBFS packages or like it was with orphaned pkgs in the past, there needs to be some kind of automatic removal threat to make sure that the important pkgs remain 15:36:14 tyll: I agree with the need to to put emphasis on the right packages... I think the key will be to come up with a shorter list of things that need to be addressed manually. 15:36:42 tyll: Maybe a list of the top ten or twenty offenders that we can start with -- and maybe go through several each FESCo meeting. 15:36:47 * jsmith is just throwing out ideas 15:37:03 yeah this isn't quite like FTBFS 15:37:10 because FTBFS is a binary 15:37:17 but CVEs aren't always important 15:37:23 they are a range of importance 15:37:42 so FTBFS seems to be always important to fix to me, but CVEs depend on the score 15:38:01 and BZ doesn't make it easy to search by score it seems 15:38:14 the score is not enough, context do matter 15:38:17 I wish we had a way to associate CVEs to upstream commits 15:38:32 AFAIU the problem is not that there is disagreement about whether they are important but that the issues are not triaged and there is no clear signal from maintainers that shows that certain CVEs are not important instead of just ignored 15:38:36 Then we could at least invoke the non-responsive maintainer policy on those that were fixed upstream but not in Fedora 15:38:45 (and for library, a CVE depend on who use it) 15:40:47 * nirik isn't sure we are going to solve this here... might be we need more discussion/ideas? 15:41:14 I think what was just said just confirms that we need to assess these individually 15:41:27 contyk: I agree 15:41:38 For now, the problem is intractible 15:41:54 I'm still +1 to sgallagh's original proposal 15:42:38 yeah me too 15:43:17 tyll: so what do you say? do you have an alternative proposal or do you think this needs more discussion? 15:43:55 * nirik notes it was never discussed on devel. 15:44:25 contyk: My would like a process more where the pkgs are announced to be removed with a deadline and then maintainers/people can object to them to be removed. Then they can stay and all the pkgs nobody cares about will be removed 15:45:30 tyll: At a quick glance, it looks like we'd be doing that for nearly every package in the distro... 15:48:09 yeah, so we would want some critera... but I am not sure what that should be 15:48:51 so how about we move this to the devel list and revisit next week? 15:49:03 +1 15:49:31 sgallagh: most of the bugs seem to be rather new, so they might still be handled (not sure if Bugzilla hides the old bugs) 15:49:35 contyk: +1 15:50:50 contyk: +1 15:51:03 contyk: +1 15:51:12 jsmith: ? 15:51:29 +1 15:52:24 #agreed Let's discuss this matter on the devel list before revisiting the topic next week (+6, 0, -0) 15:52:36 and then we have one followup 15:52:41 #topic #1942 F29 System Wide Change: Remove Excessive Linking 15:52:44 .fesco 1942 15:52:45 contyk: Issue #1942: F29 System Wide Change: Remove Excessive Linking - fesco - Pagure - https://pagure.io/fesco/issue/1942 15:52:47 https://pagure.io/fesco/issue/1942 15:52:56 but since jakub isn't here, I think we can just postpone it again 15:53:27 when is the f29 branching? 15:53:34 * nirik looks 15:53:56 2018-08-14 15:54:01 just after flock 15:55:02 are we going to have meeting next week? 15:55:04 or during flock? 15:55:24 I remain opposed to this for F29. I'm fine with flipping the switch right after F29 branches from Rawhide. 15:55:39 we are talking about f30 ehre 15:55:39 I suppose 15:56:01 ignatenkobrain: It was submitted for F29 15:56:09 If you want to retarget it for F30, that would make me happier 15:56:23 I think that was the plan 15:56:29 yeah i also think it should be switched to F30 15:56:34 but there is written proposal in ticket 15:56:35 but jakub was supposed to provide some input whether we should be doing it at all 15:56:36 just from a schedule standpoint, if it's not approved today it becomes F30 almost by default 15:57:15 we don't really have a deadline for change _approval_ in the schedule, but it seems too late for F29 at this point for reasons this group has raised 15:57:24 https://pagure.io/fesco/issue/1942#comment-523147 15:57:25 I mean here 15:57:57 i do think we should get more feedback from jakub - perhaps we need to contact him to ask if he intends to come to a fesco meeting 15:58:14 we might not have given him very good notice for the two so far 15:58:22 * nirik nods. 15:58:25 that's true 15:58:32 bowlofeggs: I'm willing to let it happen early in F30, reasoning that if it goes terribly poorly we can revert it before the mass rebuild 15:59:05 I would love to switch it as soon as f29 branches 15:59:28 because if we will be waiting for long, we might spot some issues too late and we would have to move it for f31 15:59:53 right, so we have until the 14th to decide that... 15:59:54 so that's why I was asking if there will be meeting next / after next week 15:59:59 I'm with ignatenkobrain here. Let's approve it for right after the branch, which gives us ample time to roll it back if we needed to 16:00:25 It also gives Jakub and his team two full weeks to chime in and tell us to stop if they feel like they need to. 16:00:32 We can revisit any decision. 16:00:33 I'll definitely be around both Mondays 16:01:01 WORKSFORME 16:01:10 I will not be around next Monday 16:01:14 * nirik should be around next monday 16:01:22 Approving for early F30 sounds good to me 16:01:24 i will not be around next monday 16:01:58 i am inclined to also approve pending feedback from jakub, since he hasn't been particularly responsive (he may be on vacation though?) 16:02:04 well, no reason to cancel the meeting early 16:02:08 I'll be around on Monday 16:04:23 ok, so what's the proposal here? 16:05:01 Proposal: Accept this change for F30, expecting it to be activated immediately after branching to provide maximum time to shake out issues or invoke the contingency plan. 16:05:04 +1 FTR 16:05:15 +1 16:05:19 sgallagh: +1 16:05:26 +1 16:05:30 do announce when it's enabled so people can look for the issues... 16:05:45 nirik: Yeah, good idea 16:06:09 +1 16:06:15 alright, +1 16:06:40 #agreed Accept this change for F30, expecting it to be activated immediately after branching to provide maximum time to shake out issues or invoke the contingency plan. 16:06:53 alright, so that's for the agenda 16:06:57 #topic Next week's chair 16:07:05 I will not be around 16:07:32 I can do that again if no one else volunteers 16:07:40 I can do it too 16:07:51 thanks! 16:07:58 i will not be here the next two meetings 16:08:02 #action jsmith will chair next meeting 16:08:07 :-) 16:08:11 #topic Open Floor 16:08:16 anything for the open floor? 16:09:19 looking forward to flock... 16:09:24 oh yes 16:09:25 is everyone going to make it? 16:09:30 I am 16:09:31 * tyll is 16:10:01 i'll be there 16:10:04 I'd better be, I'm scheduled as a speaker for six sessions :-/ 16:10:14 and travel is why i'm misisng both of the next two meetings :) 16:10:20 whoah six is crazy 16:10:23 * bowlofeggs is just doing 1 16:10:24 * jsmith is still only about 30% sure he'll make it to Flock 16:10:58 * nirik will be there. 1 talk and 1 workshop and 1 hackfest. :) 16:11:15 how many beers? 16:11:28 * ignatenkobrain is going to floc ;) 16:11:29 glock 16:11:29 argh! 16:11:30 flock 16:12:08 jsmith, i hope you will make it 16:12:38 bowlofeggs: I think I still hold the record. I had nine sessions at the first Flock 16:12:47 wow 16:13:09 so, endmeeting? 16:13:15 * contyk nods 16:13:19 jcline is trying to abandon me for lunch 16:13:29 yep, let's end it 16:13:32 #endmeeting