15:01:46 #startmeeting FESCO (2018-08-20) 15:01:46 #meetingname fesco 15:01:46 Meeting started Mon Aug 20 15:01:46 2018 UTC. 15:01:46 This meeting is logged and archived in a public location. 15:01:46 The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:46 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:46 The meeting name has been set to 'fesco_(2018-08-20)' 15:01:46 The meeting name has been set to 'fesco' 15:01:46 #chair nirik, maxamillion, jsmith, jwb, zbyszek, tyll, sgallagh, contyk, bowlofeggs 15:01:46 #topic init process 15:01:46 Current chairs: bowlofeggs contyk jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:01:52 .hello2 15:01:53 maxamillion: maxamillion 'Adam Miller' 15:01:54 .hello2 15:01:54 .hello2 15:01:56 .hello psabata 15:01:56 bowlofeggs: bowlofeggs 'Randy Barlow' 15:01:59 jsmith: jsmith 'Jared Smith' 15:02:02 contyk: psabata 'Petr Šabata' 15:02:06 .hello2 15:02:07 bcotton: bcotton 'Ben Cotton' 15:02:13 .hello2 15:02:14 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:02:19 * jsmith is traveling, and will have limited connectivity, but will try to respond as quickly as possible in the meeting. 15:02:37 morning 15:02:58 I'm in the middle of recovering a bad F29 update, so I'm on my phone. Will try to vote, but probably won't be talkative 15:03:22 sgallagh: you can probably send some emoticons easy 15:03:37 🖕 15:03:49 confirmed 15:04:05 🥕 15:04:07 sgallagh: "finger" is not one of the four Fs 15:04:08 alright, we have the votes ... let's get rolling 15:04:15 #topic #1935 Remove packages which has a consistent bad security record from the distribution. 15:04:15 .fesco 1935 15:04:15 https://pagure.io/fesco/issue/1935 15:04:16 maxamillion: Issue #1935: [Security] Remove packages which has a consistent bad security record from the distribution. - fesco - Pagure - https://pagure.io/fesco/issue/1935 15:04:23 this is a follow-up from last week 15:04:37 Two weeks ago? 15:04:37 or two weeks ago 15:04:52 also jsmith and I attended the flock talk 15:05:03 bcotton: Apologies. Frustrating morning. 15:05:15 do we have a concrete proposal here? 15:05:41 zbyszek: yes ... many weeks ago I think 15:05:45 I'd be in favor of triggering the ftbfs process for leaf packages that have had open and unaddressed security issues for two releases 15:06:31 And I would as well -- especially if the security issues are High or Critial and/or have a CVSS score of 8.0 or higher. 15:06:41 contyk: Of at least medium severity? 15:06:41 I don't think we should stick to leaf packages. 15:06:44 I can be in favor of that, but note someone has to manage that process. 15:07:08 no preference on the severity 15:07:13 how would users be notified ? 15:07:28 (cause we do have a example with cobbler currently) 15:07:33 Quite the opposite, especially if it is not a leaf package, we should go through the process of annoying the maintainers, and possibly orphaning and then retiring the package. 15:08:02 contyk: I really couldn't care less if the maintainers ignored bugs like "If you already have root on the system, you can do other stuff in this specific app" 15:08:26 i agree - non-leaf packages could be more important to pay attention to since they affect more of the distribution 15:08:49 during the talk, huzaifas said he would like to see at least some response to the report 15:08:50 sgallagh: maintainers should jsut close such bugs with WONTFIX and a short message. 15:09:01 if it's of the type sgallagh is mentioning, even just closing it with wontfix is fine 15:09:11 It's better for everybody involved than an unmanagable pile of CVEs. 15:09:20 WORKSFORME 15:09:31 I can see my way to agreeing to that 15:09:37 yeah i also think ack'ing it could be enough if it's not severe 15:09:38 or even a assigned with 'working on a fix, but it could be a while' is much better than silence. 15:10:20 may I ask that a minimum CVSS3 threshold be part of this .. ther eis gamesmanship on getting CVE's that are not exploitable in the broader community 15:10:20 yeah 15:10:54 there is a technical problem to solve with CVSS scores - i don't know that bugzilla has an easy way to query by them 15:10:56 (or does it?) 15:11:02 orc_fedo: That was kind of what I was suggesting, but the counter-argument holds merit: the maintainer should at least make a statement that they are ignoring or deferring it 15:11:19 bowlofeggs they are in tag: Whiteboard 15:11:33 sgallagh: see eg: https://bugzilla.redhat.com/show_bug.cgi?id=1618891 15:11:34 if we are using the ftbfs process all they have to do is change the bug state... wontfix, assigned, etc right? 15:11:42 right 15:13:03 I guess this should be enough. If there are specific cases where this is not enough, FESCo can override the process. 15:14:09 any proposals? 15:14:17 so, ftbfs process for all packages, not just leaves, with security bugs in the NEW state for at least two releases? 15:14:37 I think it should be different, let me type a counter-proposal up 15:14:39 the bug list in the ticket was pretty long; do we know how many packages this means? 15:15:40 * nirik notes we don't actually have anyone doing the ftbfs process, so we should note who will manage this. perhaps rotating fesco members? but that will need a good SOP 15:17:04 nirik: I think we should discuss this during open floor 15:18:28 zbyszek: are you still typing up a counter? 15:19:10 proposal: If a CRITICAL or IMPORTANT security issue is open against a package at the branch point, trigger a procedure similar to long-standing FTBFS immediately, with 8 weeks of weekly notifications to maintainers and subsequent orphaning and then subsequent removal from distribution. This applies to all packages, not just leaf. 15:19:40 I know this is pretty harsh. 15:19:53 zbyszek: would that remove it from the branched release? 15:19:57 or just rawhide? 15:20:03 Both. 15:20:16 that could impact the schedule of the branched release 15:20:23 i wonder if we should start earlier than branched? 15:20:36 I was wondering about that too. 15:20:36 depending on which packages, of course 15:20:39 zbyszek: I'm not against the proposal as written, but I worry about the implications / fall-out of it applying to all packages 15:20:44 it's also rather different from the original proposal where we grant them 2 releases time 15:20:55 2 releases is a long time for a critical 15:20:57 does someone have a search handy for that? ie, how many does that affect? 15:20:59 Yes, but 2 releases time is very long. 15:21:02 I would also like to do it for all severities, as noted before 15:21:08 also that leaves stuff less critial just lingering 15:21:25 i'm not sure what other anchor point in the schedule would fit. though we could just add it as an explicit milestone with some offset from the branch point 15:22:34 i do think it's sensible to have different requirements based on severity 15:22:42 because low sev CVEs are often silly 15:23:09 nirik: so what about doing "If a CRITICAL or IMPORTANT security issue is open, or an issue of lower severity has been open for at least 6 months, at the branch point ..."? 15:23:33 there are presently 2438 moderate or critical CVE's in bugzilla 15:23:33 bowlofeggs: any status of CVE can be silly. ;) 15:23:49 nirik: hahah true, for different reasons of "silly" 15:24:01 what i meant was more that a lot of them start with "if the attacker has root..." 15:24:16 so, perhaps we should punt this to next week and ask people to write up concrete proposals rather than trying to draft something in meeting? 15:24:24 nirik: +1 15:24:27 nirik: +1 15:24:35 though i think zbyszek's proposal is close to what i'd want 15:24:43 nirik: +1 15:24:47 i just worry about the schedule and the severity 15:25:05 nirik: +1 15:25:15 I'll put my proposal in the ticket and then maybe we can hammer out the details there. 15:25:16 +1 15:27:32 #agreed - Postpone decision until next week, awaiting zbyszek's proposal in ticket 15:27:36 #undo 15:27:36 Removing item from minutes: AGREED by maxamillion at 15:27:32 : - Postpone decision until next week, awaiting zbyszek's proposal in ticket 15:27:47 #agreed - Postpone decision until next week, awaiting zbyszek's proposal in ticket (+5, -0, +0) 15:27:59 sure, +1, lets move on 15:28:00 #topic #1955 Let's get rid of filedeps (FESCo edition) 15:28:01 .fesco 1955 15:28:01 https://pagure.io/fesco/issue/1955 15:28:03 maxamillion: Issue #1955: Let's get rid of filedeps (FESCo edition) - fesco - Pagure - https://pagure.io/fesco/issue/1955 15:29:52 This issue is a bit circular, with various actions only making sense if other stuff is done, which in turn somewhat depends on those initial issues. 15:30:06 really the big win would be lazy loading in dnf... 15:30:16 this issue also seems like an FPC issue to me 15:30:29 well, we sent them to fpc before 15:30:30 though i guess it's here because they are undecided on it? 15:30:31 now it's back 15:30:44 fun :) 15:30:58 they still also have a ticket I think. 15:31:00 * jsmith is still waiting to see if zchunk makes this much less of an issue. 15:31:01 fpc thinks there's nothing to change in the guidelines; they already discourage the usage of file deps 15:31:07 My proposal would be to say: "we are doing this", and ask FPC to update the guidelines to forbid deps outside of /usr/[s]bin, and initiate cleanup of packages, and in parallel start working on dnf, createrepo_c, libsolv 15:31:10 I also think zchunk will help a lot here 15:31:18 contyk: current guidelines are inadequate 15:31:34 contyk: zchunk is orthogonal to this 15:31:53 zbyszek: i think they wanted to allow /etc/ too, but it sounds fine to me 15:31:57 it won't help with the dnf startup time 15:32:26 i feel like there was a comment somewhere about allowing /etc anyway... 15:33:07 I'm not really sure about /etc, I'm not sure if I see the point, but this is a minor detail. 15:33:15 agreed 15:33:45 tibbs suggested just closing the issue 15:33:50 in https://pagure.io/fesco/issue/1955#comment-524412 15:33:51 https://pagure.io/packaging-committee/issue/714 15:34:15 FPC did agree on some changes, see the end of that ticket 15:34:46 it's just not been announced yet 15:34:57 It is written into the guidelines, though. 15:35:08 cool 15:35:18 they went with SHOULD NOT and not MUST NO 15:35:19 t 15:35:31 so, if they came to an agreement, do we need to decide anything? 15:35:38 Yes 15:36:02 Well, we don't really have to, but it'd be good if fesco gave a +1 to doing the changes in packages and dnf 15:36:29 well, we can ask dnf developers to consider it and put it on their road map... but we cannot force them to do soemthing. 15:36:29 I need to drop, folks. Is that going to kill quorum? 15:37:05 True. 15:37:26 sgallagh: i think we still have 5? 15:37:40 proposal: ask dnf folks to put this on their roadmap, close ticket 15:37:48 nirik: +1 15:37:51 me, zbyszek, nirik, contyk, jsmith, and maxamillion (so, 6) 15:38:06 nirik: +1 15:39:17 +1 15:39:48 nirik: could you be more specific with "this"? 15:40:23 implement lazy loading or other ways of reducing initial repodata downloads 15:40:57 #agreed ask dnf folks to put lazy loading (or reduced repodata loads) on their roadmap, close ticket (+1: 6, -1: 0, +0: 0) 15:41:00 good? 15:41:14 contyk didn't vote I think 15:41:20 (yet) 15:41:31 I only see three votes after nirik's proposal 15:41:53 but I'm +1 to lazy loading in dnf 15:42:40 oh, sorry ... I was counting what bowlofeggs said about votes 15:42:44 #undo 15:42:44 Removing item from minutes: AGREED by maxamillion at 15:40:57 : ask dnf folks to put lazy loading (or reduced repodata loads) on their roadmap, close ticket (+1: 6, -1: 0, +0: 0) 15:43:00 jsmith: sgallagh: what say you? 15:43:10 sgallagh said he was leaving 15:43:21 maxamillion: haha i was just telling sgallagh that we had quorum (he had to leave) 15:43:47 maxamillion: +1 15:45:26 jsmith: your +1 is for nirik's proposal, I presume 15:45:33 Yes 15:45:35 oh, I missed that 15:45:38 sgallagh: nvm :) 15:45:39 (Sorry, juggling multiple cats) 15:45:41 bowlofeggs: we do 15:46:00 #agreed ask dnf folks to put lazy loading (or reduced repodata loads) on their roadmap, close ticket (+1: 5, -1: 0, +0: 0) 15:46:09 #topic #1962 F29 Change: Cloud Provider Image Updates 15:46:10 .fesco 1962 15:46:10 https://pagure.io/fesco/issue/1962 15:46:11 Actually it's +6 now 15:46:12 maxamillion: Issue #1962: F29 Change: Cloud Provider Image Updates - fesco - Pagure - https://pagure.io/fesco/issue/1962 15:46:18 No matter 15:46:22 +1 here if I wasn't already in ticket. 15:46:34 zbyszek: I apparently can't count ... sorry about that one 15:47:25 +1 too, I guess the details will have be figured out during implementation 15:47:52 +1 15:47:53 +1 too, although I'd still like feedback from releng 15:48:05 +1 - agreed about feedback from releng 15:48:09 mboddu: ping - you around? 15:48:17 +1 15:48:21 maxamillion: Yes 15:48:47 mboddu: do you mind commenting on https://pagure.io/fesco/issue/1962 ? 15:50:22 Sure, will take a look now 15:51:03 mboddu: thank you 15:53:28 15:53:51 the sound of eyeballs moving 15:55:19 so, uh... 15:55:30 maxamillion: i think i count +6? 15:55:45 bowlofeggs: oh crap 15:55:56 I'm still not used to the new process, that's on me 15:56:04 .hello2 15:56:07 jdoss: jdoss 'Joe Doss' 15:56:31 #agreed F29 Change: Cloud Provider Image Updates - Approved by in-ticket votes (+1: 6, -1: 0, +0: 0) 15:56:35 mboddu: sorry 15:56:45 #topic #1964 Nonresponsive maintainer: wolnei (kio-gdrive) 15:56:45 .fesco 1964 15:56:45 https://pagure.io/fesco/issue/1964 15:56:46 maxamillion: Issue #1964: Nonresponsive maintainer: wolnei (kio-gdrive) - fesco - Pagure - https://pagure.io/fesco/issue/1964 15:57:27 Sorry I'm late. I can answer any questions about #1916 but I looks like it's approved :) 15:58:07 maxamillion: I commented on it and I am +1 to the change but we need some help/changes which I commented on the ticket 15:58:11 Sorry #1962 15:58:52 +1 to this ticket, I can just do it now. 15:59:15 is there a non-responsive BZ ticket here? 15:59:22 +1 15:59:28 ah yes there is 15:59:40 i'm +1 to reassign 16:00:01 same, +1 16:00:07 +1 to reassign 16:01:24 #agreed reassign wolnei (kio-gdrive) packages (+1: 5, +0: 0, -1: 0) 16:01:30 note that it just needs one fesco member to ack it... :) so done. move on. 16:01:35 #topic #1967 Fedora 29 incomplete changes 16:01:36 .fesco 1967 16:01:36 https://pagure.io/fesco/issue/1967 16:01:39 maxamillion: Issue #1967: Fedora 29 incomplete changes - fesco - Pagure - https://pagure.io/fesco/issue/1967 16:02:21 should we go 1x1? 16:02:41 the last update was 5 days ago, some of them may be marked done now? 16:02:54 yeah, 1x1 16:03:00 mpfr seems unresponsive maybe 16:03:05 well more than maybe 16:03:13 one by one seems good, we can check them as we go. 16:03:15 proposal: kick mpfr down to f30 16:03:20 +1 16:03:39 +1 16:04:37 contyk, maxamillion, jsmith: ? 16:04:52 +1 16:04:53 +1 16:06:16 16:06:31 we do have a +5. shall we move on? 16:06:38 please do 16:06:58 maxamillion: ? 16:07:22 dbus looks good as noted by zbyszek 16:07:34 bowlofeggs: we have +5? 16:07:43 bowlofeggs: I see +4 16:07:54 bowlofeggs, let's do each one separately, we risk chaos otherwise 16:07:57 maxamillion: well i think it's reasonable to interpret a proposal as an implicit +1 16:08:22 zbyszek: sure, so let's discuss dbus 16:08:26 #agreed Defer mpfr to Fedora 30 (+1: 5, -1: 0, +0: 0) 16:09:01 So, re dbus, nirik merged the remaining PRs yesterday, so it's ready to be tested by unsuspecting users ;) 16:09:08 zbyszek: heh 16:09:19 we need a build tho right? or did you do one? 16:09:20 so is there anything to do re: dbus, or come back to it in a week? 16:10:01 nirik: I didn't do a build. I asked a few times, and I was always told that only releng people should work on this package 16:10:25 no problem, mboddu or I can do a build. just wanted to make sure 16:10:52 Well, if I can do builds, I wouldn't do the dance of "send a pr, then 8 reminders" so many times 16:11:45 you can't now that I think about it, it's in a special channel. but PR's are good anyhow. 16:11:56 I would prefer to have an explicit ack from the maintainers before doing that though. 16:12:13 ah, OK, so if you or mboddu could do the build that'd be great 16:14:03 * nirik nods. 16:14:07 so where are we? 16:14:17 Would it be possible for the maintainers to *always* do a build of fedora-release after merging a batch of stuff, just to avoid the state where it's merged, but not available? 16:14:43 Well, a discussion for another time and place, let's move on. 16:15:06 +1 let's move on 16:15:23 Let's discuss "Update festival to 2.5" 16:15:53 +1 to moving on 16:15:54 I'll look into sponsoring Lukáš Tyrychtr. It seems he did a lot of good work, it'd be a shame to waste it. 16:16:07 sounds good, thanks 16:16:19 This is a leaf package, so I think it's OK to let the change slip a bit 16:16:20 proposal: see where this stands in a week after zbyszek helps out? 16:16:37 +1 16:16:39 +1 16:17:22 + 16:17:23 +1 16:17:30 +1 16:18:47 maxamillion: ? 16:19:02 +1 16:19:17 #action zbyszek to talk to change owner about sponsorship 16:20:00 #agreed defer "update festival to 2.5" until next week, zbyszek to take point on following up (+1: 6, +0: 0, -1: 0) 16:20:26 Let's move on to "Let's Label Our Variants!" 16:20:54 It was supposed to be done during the past week, seems it wasn't. 16:21:32 do we still have mboddu? 16:21:41 contyk: kinda 16:22:14 i don't see anything here https://src.fedoraproject.org/rpms/fedora-release/pull-requests?status=0 16:22:19 or with status=1 either 16:22:27 Label our variants thing is not done, I might need some help with that with lua scripts 16:22:48 should we postpone this one to f30? 16:23:10 bowlofeggs: We can still get it, my plan is to get it done before freeze 16:23:29 I guess pbrobinson was going to work on it some? 16:23:44 the contingency plan is that it's fine if some get done and not others 16:23:49 * nirik guesses which peter is meant) 16:24:01 https://fedoraproject.org/wiki/Changes/Label_Our_Variants#Contingency_Plan 16:25:42 bowlofeggs: Lets go with contingency plan 1 if I cannot get it done before beta freeze, is that okay? 16:26:05 fine with me, +1 16:26:11 proposal: what mboddu said 16:26:15 +1 16:26:39 +1 16:27:22 -0, it's late for a change that could potentially break unrelated stuff 16:27:38 +1 16:28:05 zbyszek: what do you think it is at risk of breaking? 16:28:26 (By "late" I mean that if this goes in right before beta freeze, and users report issues with the beta image, it'll be pretty late in the cycle to fix.) 16:28:38 bowlofeggs: I don't know, but many things read that 16:29:00 E.g. various non-distro scripts conditionalize on VARIANT_ID 16:29:06 it is an additive change though afaiu 16:29:20 my laptop actually doesn't have those vars defined 16:29:22 jsmith: ? 16:29:34 ermmm... we might not have the votes anymore 16:29:41 i would expect an additive change to be pretty low risk 16:30:00 yeah we only have +4 16:30:12 Sorry, give me a second to catch up... 16:30:13 i could also vote to defer to f30 though 16:30:18 imo it's not a critical change 16:31:20 it should be easy enough to revert too, no? if it's breaking lots of things... 16:31:46 OK, I'll change to +1, but let's watch out for regressions and not merge this right before the beta freeze 16:31:53 zbyszek: Its an additive change and easy to revert and will be done before beta freeze and not before the beta release 16:31:55 I guess I'm OK, as long as it's easy to revert 16:32:38 zbyszek: oh no, I meant I was worried we didn't have quorum 16:33:02 #agreed Label Out Variants will be go with Contingency Plan 1 if not completed by beta freeze (+1: 5, -1: 0, +0: 1) 16:33:29 maxamillion: I'm slow, but I'm still here :-) 16:34:16 alright 16:34:21 let's talk about -> Merge Dstat And Performance Co-Pilot 16:35:23 looks like someone just got needinfo'd today about this 16:35:23 It looks like there was a confusion with issue assignment, so the needifno flag was only set today 16:35:29 proposal: wait a week on this one? 16:35:33 bowlofeggs: +1 16:35:40 +1 16:35:44 +1 16:36:17 contyk: jsmith: ? 16:36:41 +1 16:37:32 #agreed allow a week to get an update on the state of Merge Dstat And Performance Co-Pilot (+1: 5, -1: 0, +0: 0) 16:37:33 nirik: mboddu: I was working on it, I was awaiting lua help 16:37:53 Let's talk about -> Stop building 389-ds-base on i686 16:38:08 That's done, right? 16:38:23 zbyszek: yeah zbyszek's comment is that it's done 16:38:26 I thought it was 16:38:41 I mean we requested the change page after the fact 16:38:47 #info Stop building 389-ds-base on i686 is actually complete and no longer requires discussion as an incomplete Change 16:39:14 Let's talk about -> Rename Atomic Workstation to Silverblue 16:39:29 mclasen: is https://bugzilla.redhat.com/show_bug.cgi?id=1598405 done? 16:39:33 dustymabe: ^ 16:40:00 * dustymabe wakes from the dead 16:40:53 any question for me? 16:42:03 dustymabe: is https://bugzilla.redhat.com/show_bug.cgi?id=1598405 done? 16:42:13 dustymabe: you happen to know what's up with Silverblue vs Atomic Workstation? 16:42:31 .fas lobocode 16:42:31 lobocode: lobocode 'Vitor Lobo Ramos' 16:42:48 maxamillion: I know some part of it was done recently 16:42:53 mboddu: helped us out there 16:43:14 https://pagure.io/pungi-fedora/pull-request/631 16:43:27 it seemed like there was progress on it from the discussion of Silverblue at Flock but I don't know how much of that was "this is what we want to do" vs "this is what we've done" 16:43:32 i imagine there are some few things left to rename 16:44:35 so "some progress has been made" 16:44:45 will have to get official update from mclasen in the future?? 16:45:26 bowlofeggs: it was on my list for this week to find out the status 16:45:48 alright 16:45:50 proposal: wait one more week for a status update 16:45:52 +1 16:45:57 +1 16:46:55 +1 16:47:00 +1 16:47:14 +1 16:48:04 #agreed wait one more week for a status update on Silverblue rename (+1: 6, -1: 0, +0: 0) 16:49:08 #topic #1968 Proposed F30 Schedule 16:49:08 .fesco 1968 16:49:08 https://pagure.io/fesco/issue/1968 16:49:09 maxamillion: Issue #1968: Proposed F30 Schedule - fesco - Pagure - https://pagure.io/fesco/issue/1968 16:49:29 did we finish all the items from the not ready ticket? 16:49:40 nirik: we did 16:49:46 ok, cool 16:49:49 at least I'm pretty sure we did 16:49:53 we did 16:49:59 +1 16:50:02 +1 from me. 16:50:05 Looks pretty solid 16:50:16 +1 16:50:17 +1 16:50:18 well, +1 16:50:20 i put a +1 in ticket 16:50:48 (again, with the caveat that we may need to adjust for any new Objectives that might come up) 16:51:41 afaict, there's no real timing for when objectives may come up, so that's always going to be a concern. i plan on working with the council to better define that (or at least make it more readily obvious) 16:52:15 for F31, i'd like to have objectives be an explicit part of the schedule if possible 16:52:29 #agreed F30 Schedule (+1: 6, -1: 0, +0: 0) 16:52:37 #topic #1969 Nonresponsive maintainer: dbmacartney 16:52:37 .fesco 1969 16:52:37 https://pagure.io/fesco/issue/1969 16:52:38 maxamillion: Issue #1969: Nonresponsive maintainer: dbmacartney - fesco - Pagure - https://pagure.io/fesco/issue/1969 16:53:05 It's +5 in the ticket 16:53:08 bah! 16:53:26 #agreed Nonresponsive maintainer: dbmacartney was handled in ticket, no discussion necessary 16:53:35 We need a volunteer to do the deed 16:53:38 #topic Next week's chair 16:54:59 crickets .... 16:55:02 sure 16:55:04 I'll do it 16:55:13 #action contyk to chair next week's meeting 16:55:16 #topic Open Floor 16:55:22 anything to discuss here? 16:55:28 nirik had something 16:56:20 Note: I filed https://bugzilla.redhat.com/show_bug.cgi?id=1619368 for the dnf RFE for lazy loading 16:56:31 Thanks nirik 16:56:57 for non responsive maintainer tickets, anyone mind if I add a template? that would help people fill in the right info... 16:57:19 +1 16:57:21 sounds good 16:57:27 nirik: +1, great idea 16:57:31 nirik++ 16:57:32 maxamillion: Karma for kevin changed to 26 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:57:54 I dont think I had anything else... 16:58:08 alright, I'll wait 60 seconds and then hit the button 16:58:10 We need to discuss ftbfs policy 16:58:36 Well, not the policy, but the implementation of the policy 16:58:53 alright 17:00:07 The specified time is up for many packages. My proposal would be to ping the maintainers of the packages which are still failing and in NEW state by main now, and wait another week, and then do the orphaning. 17:00:26 zbyszek: +1 17:00:43 I'm not particularly eager to do this myself, but I'll do it if nobody else can 17:00:46 is there a list? 17:01:08 nirik: no, I think we need some scripting to generate a proper list 17:01:29 ok 17:02:29 OK, I'll open a fesco ticket with the list and detailed procedure, and let's vote on that. 17:02:42 might I suggest when we orphan and announce that, we point everyone to a single releng ticket and people can ask for packages they want there... instead of all over the place. 17:02:59 Yes. 17:03:32 It's unfortunate that the de-orphaning procedure is now manual. If people could just pick up packages, that'd be much easier on releng. 17:04:09 yeah so many things are manual now 17:04:15 that were automated a year ago :/ 17:05:27 well, the orphaning/retiring wasn't automated I don't think... 17:05:43 a human had to run scripts... but yes, the scripts now need rework 17:07:49 OK, let's move on. 17:08:22 maxamillion: there are 4 issues tagged pending announcement 17:09:41 The normal procedure would be list them in the announcement email, but they can go in the summary email too 17:10:47 "normal procedure" ... I've never seen that tag before 17:12:34 Anyway, I have two more things... 17:12:59 One, did anything happen with the "man page tracker" bug? Do we just ignore it? 17:13:21 Two, do we have a volunteer to reassign ownership in #1969? 17:13:34 this meeting has been going on for a long time 17:13:36 maxamillion: you may have been out at the time... but see https://fedoraproject.org/wiki/FESCo_meeting_process (tickets voted on in ticket just get announced) 17:13:44 should we call it and schedule those items for next week? 17:14:10 I can reassign things in 1969. 17:14:25 Thanks. 17:14:36 Sorry for being such a bore, but I don't want things to slip through. 17:14:45 nirik: fair, the last three months have been really spotty for me 17:14:56 I have to go, we've reached the meeting time threshold 17:15:08 if someone else wants to take over, go for it but I need to bounce 17:15:13 o/ 17:15:21 Yep, let's close. 17:16:13 * nirik isn't sure what to do about the man pages thing. perhaps it could be discussed on list? 17:16:58 Or just ignored? Maybe just ignoring it is the way to go. 17:18:37 maxamillion: endmeeting ? 17:19:43 OK, let's close. 17:19:53 #endmeeting