15:01:40 #startmeeting FESCO (2019-02-04) 15:01:40 Meeting started Mon Feb 4 15:01:40 2019 UTC. 15:01:40 This meeting is logged and archived in a public location. 15:01:40 The chair is mhroncok. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:40 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:40 The meeting name has been set to 'fesco_(2019-02-04)' 15:01:40 #meetingname fesco 15:01:40 The meeting name has been set to 'fesco' 15:01:40 #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor 15:01:40 Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek 15:01:40 #topic init process 15:01:47 contyk: I got connected 15:01:50 .hello2 15:01:51 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:55 .hello2 15:01:56 otaylor: otaylor 'Owen Taylor' 15:01:59 morning 15:02:00 .hello2 15:02:01 sgallagh: sgallagh 'Stephen Gallagher' 15:02:34 mhroncok: cool 15:02:38 .hello psabata 15:02:39 contyk: psabata 'Petr Šabata' 15:02:41 .hello2 15:02:42 bowlofeggs: bowlofeggs 'Randy Barlow' 15:03:12 are you guys ready to steer some things, together, as a committee? 15:03:24 do we have 9 steering wheels on this bus? 15:03:28 how does that even work? 15:03:52 Do we have to by unamimous or things go wonky? 15:03:59 bowlofeggs: so much philosophy 15:04:00 you have 9 wheels 15:04:16 haha 15:04:49 I guess we have quorum 15:05:02 all of them unicycles 15:05:03 bowlofeggs: I think it's more like having nine oars. 15:05:13 Four on either side of the boat, one acting as a rudder 15:05:35 (Or anchor, if you prefer) 15:05:41 the oar comittee 15:05:52 sgallagh: ha yeah that is a better but less funny analogy ☺ 15:06:09 bowlofeggs: Until you imagine the scene, sure! 15:06:12 #topic #1970 Action needed: Orphan packages will be retired if they remain orphaned for six weeks 15:06:12 .fesco 1970 15:06:12 https://pagure.io/fesco/issue/1970 15:06:14 haha 15:06:35 so about orphans 15:06:59 the retirement happens due to a volunteer that does it every week 15:07:06 * bowlofeggs spends 5 minutes scrolling his mouse wheel to the bottom of this ticket 15:07:14 it's not *that* tedious actually 15:07:23 bowlofeggs: ? 15:07:25 the problem here is that there is no actual policy about depndent packages 15:07:29 haha 15:07:40 yeah the dependent package thing is tricky 15:07:51 one extreme is: retire them as well, show no mercy 15:07:57 on one hand, it's tempting to just say "they get orphaned too" 15:08:05 but what if they happent o be really important packages 15:08:12 the other extreme is: let them be, everything-is-fine.jpeg 15:08:16 I think we just ignore them until they fail their next mass-rebuild 15:08:18 we do have a list of "really improtant packages" in the critpath package list 15:08:24 middle might be wait and get them next cycle 15:08:37 sgallagh: FTBFS ones are easy 15:08:37 bowlofeggs: That list is very much out of date 15:08:42 (or what sgallagh said more coherently) 15:08:43 (critpath package list is not well maintained) 15:08:43 it's the runtime problems that i worry about 15:08:46 yeah 15:08:55 critpath also doens't really mean "really important" as much as "necessary to boot to a desktop" 15:09:21 I think such deps are often forgotten and/or semi-optional, so orphaning dependent packages seems like too big of a step for me 15:09:27 mhroncok: Well, runtime problems tend to get noticed by automatic QA processes 15:09:29 and the FTBFS orphan / retire policy doesn't happen either, so not so much luck there 15:09:31 otaylor: true (or is it "included in one of the official ISOs, or a dependency of a package included in an official ISO?") 15:09:35 So I think we'd have a quick turnaround there 15:09:55 i don't mind letting the next FTBFS round pick them up 15:10:03 the "middle option" as nirik stated 15:10:18 as long as we have a policy and actual process running for FTBS **and** broken deps, we are good 15:10:21 nether is true 15:10:24 yeah 15:10:42 * zbyszek intends to spend some time on the FTBFS-retirement after this mass reubild 15:10:44 I don't mind letting the next FTBFS round pick them up if that actually means something 15:10:47 i'm a little scared of just retiring deps too, though i am not sure i'm opposed to that 15:11:04 We should also think about EPEL here - that's the only place where retirement affects a current release, if I'm not mistaken? 15:11:09 .hello till 15:11:10 tyll_: till 'Till Maas' 15:11:13 the downside to the next round is that could be a long time (6ish months) 15:11:26 otaylor: yet the policy for orphanned packages doesn't spek of retiring them on epel 15:11:32 otaylor: i'm not sure we touch EPEL with this, do we? 15:11:35 we have to at least warn deps 15:11:42 jforbes: i think we do that now 15:11:45 * mhroncok only retires packages in rawhide 15:11:56 in the past I retired dependent packages as well... and they could still be unretired in case they are important 15:11:56 bowlofeggs: if a package is orphaned, it's orphaned for EPEL too, right? 15:12:00 jforbes: I bomp them with e-mail for 6 weeks 15:12:04 otaylor: i don't think so 15:12:05 jforbes: they don't care 15:12:08 oh yes 15:12:11 otaylor: yes you are right 15:12:16 but we don't *retire* it there 15:12:28 until they are "oh no, thi isn't here anymore, where did it go, it was right here 8 years ago and now it isn't" 15:12:44 mhroncok: haha "bomp" 15:12:52 otaylor, bowlofeggs so in the past a package would have branch owners and so would be 'owned' in EPEL but orphaned in main 15:12:54 supposed to be bomb 15:12:57 * nirik leans toward just retiring the dependent ones (with enough notice) 15:12:58 mhroncok: you should put "bomp" in the subject line 15:13:20 we sort of have people who don't want to maintain things in Fedora as much as Fedora packagers have things they don't want to look at in EPEL 15:13:30 the one good thing about retiring is that it's easy to unretire if it's done quickly enough 15:13:46 yet it put unnecessary work on releng 15:13:46 within some number of weeks you can unretire without re-review iirc 15:13:50 also true 15:13:50 2 weeks 15:14:04 and if tahey ahven't noticed in 6 weeks, those 2 weeks are not gonna change that 15:14:20 mhroncok: yeah that's probably true 15:14:20 the epel interactions here are much less clear than they used to be... and somewhat confusing. 15:14:21 mhroncok: if they do not notice, then the package can be rightfully retired 15:14:35 tyll: I tend to agree 15:14:40 i think i could support any of the proposed options 15:14:54 yet I get the "sigh" emails "I've juts noticed this" after couple months 15:15:10 I think that retirement is too much 15:15:10 thats always going to happen I fear 15:15:15 yeah 15:15:22 at least half of the cases the dependency can go away 15:15:30 That actually argues for retiring dependent packages so that people notice asap, on the other hand, there has to be some "human touch" there - since we don't want to retire a huge bunch of packages, then have to fix it all up afterwards 15:15:49 we get similar emails still for people who find their accounts were locked out from a password change 7 years ago 15:15:56 ideally, we'd have a mechanism that opens a bug (or similar) as soon as package starts to FTBS and/or has problematic runtime deps 15:16:01 mhroncok: i wonder if it would be good to send an e-mail per package about retiring that package, rather than a single e-mail with all the packages to the packagers, and then *also* send the single e-mail with all packages to devel list? 15:16:10 That's why I like taking the slightly slower route of filing FTBFS for depdent packages 15:16:12 there would be a deadline to fix them, or retirement happens after 15:16:20 that might catch people's attenotion, because the e-mail that goes to their inbox would be more targeted? 15:16:23 just an idea… 15:16:40 bowlofeggs: they got the same e-mail both to inbox and the mailing list 15:16:50 depends on their filters really 15:17:19 zbyszek: the FTBFS only solves the buildtime deps problem 15:17:20 tyll: yeah but the e-mail in the inbox makes you ctrl-f for your nick to see which packages affect you 15:17:39 it's not bad as it is now, i'm just considering whether it would help 15:17:44 might not 15:17:47 bowlofeggs: might help a little 15:17:48 well, if you got it it does 15:17:58 bowlofeggs: probably not worth dealing with dozens of emails every week 15:18:02 until a bo runs this 15:18:04 mhroncok: yeah maybe not 15:18:08 *bot 15:18:22 so who feels strongly about the options we've proposed? i would +1 any of them honestly 15:18:34 IMHO it would be nice to send out a notification direclty when a package is orphaned to all the co-maintainers and the maintainers of directly dependent pkgs to make them aware 15:18:38 * otaylor tries to avoid speculating about how we could do packager notifications better in absence of resources to actually improve things 15:18:46 AFAIK there is no notification if a package is orphaned atm 15:18:59 there is fedmsg 15:19:05 (or at least I hope there is) 15:19:08 fedmsg is not a notification system 15:19:16 and there is a fedmsg -> e-mail notification thing 15:19:25 and fedmsg --> iRC too 15:19:29 so this could (maybe) be easy 15:19:34 or not :D 15:19:35 yes, but they do not notify atm 15:19:41 Yeah, question of how people have their fedmsg filters set up 15:19:53 they do not notify by default 15:20:00 we could emit messages about this, but not sure how much better than emails that would really end up being 15:20:12 also, the filter to notify me when a dependncy is orphaned is probably nontrivial 15:20:20 i think we currently do a good job of notifying that we are going to orphan packages 15:20:26 i certainly see and look at those e-mails anyway 15:20:34 I tend to agree 15:20:42 people are ignoring those becasue they know nothign happens 15:20:51 so we should make something happen and they'll get used to this 15:21:10 yeah maybe we should just do *something* and see how it goes>? 15:21:17 we can readjust our policy later if needed 15:21:29 +1 to do something 15:21:33 as said, i don't feel strongly about which something we do 15:21:40 So the crucial difference for *dependent* packages is that until the orphaning actually happens, there's nothing to do for the maintainers. They can rightfully hope that somebody will pick up the package. 15:21:40 i'll +1 any of the three we've talked about 15:21:45 -1 to retire deps when we retire the orphaned package 15:22:17 I remember getting a daily e-mail "your package has broken deps", it stopped couple years ago 15:22:28 yeah that was useful, i remember that oo 15:22:31 That's why I think immediately retiring (or acting in any immediate way) on dependent packages at the same time as the dependended-upon package is too soon. 15:22:32 yep. it broke due to rich deps 15:22:34 i use koschei too 15:22:39 oh yeah, rich deps 15:22:42 there's a new one that has been having issues getting to work... 15:22:47 It'd be great to bring this back. 15:23:18 https://pagure.io/releng/issue/6365 15:23:33 even a once per release, generate bugzillas for broken deps and apply FTBFS rules would work for me 15:23:49 https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190204.n.0/logs/depcheck 15:24:03 (without arm and aarch64) 15:24:28 mhroncok: actually there was a rule to retire pkgs with broken deps before branching 15:24:41 (to be added to the list of things that are not happening anymore) 15:24:48 so it sounds like there's less support for the "extreme option" (retiring deps immediately) 15:25:01 bowlofeggs: yes, that's correct 15:25:14 Yeah, I'd be against 15:25:14 Yeah, I have a hard time with that option 15:25:17 so how about the 'let dependent packages get caught in FTBFS process' 15:25:33 nirik: that doesn't solve runtime only deps 15:25:38 the remaining options are to let the FTBFS naturally pick it up next cycle (slooow), or to immediately file a FTBFS upon retiring (medium speed) 15:25:49 I'm Ok with slow 15:25:53 mhroncok: I still feel that runtime-only deps will get noticed by automation 15:25:55 as long as it also covers runtime 15:25:57 * tyll prefers medium speed 15:26:04 sgallagh: they are not 15:26:07 * nirik likes medium speed too 15:26:18 sometimes missing deps don't mean FTBFS 15:26:28 there are some deps that are runtime only 15:26:32 and the FTBFS could be quite medium speed, if the policty there actually happens 15:26:32 mhroncok: I don't mean the missing-deps tests 15:26:35 Automation in the form of gating will hopfully appear in the non-too-distant future 15:26:38 I mean the actual functional tests. 15:26:53 If things that aren't part of the installed media are broken, that's less worrisome to me 15:26:56 I like the medium sped best. 15:26:58 that's a fairy tale ATM 15:26:58 i dont' think we have a "Fail to Install" test, do we? 15:27:04 other than koschei 15:27:22 we easily could with rawhide gating. 15:27:37 gating happens on new build, correct? 15:27:42 if we immediately file a FTBFS when we retire a dependency, we could detect what to file based on Requires AND BuidRequires 15:27:44 so let's say A needs B 15:27:46 we retire B 15:27:49 yeah, so it wouldn't catch old things. 15:27:53 which i think might be more thorough than FTBFS 15:27:55 A has broken deps, what does gatin do and when? 15:28:15 yeah i guess automation could catch Fail to Install 15:28:23 and we are working towards gating rawhide 15:28:26 it definitively should 15:28:32 automate all the things \o/ 15:28:48 yet I don't like to plan policies on top of "this should be automated" 15:28:49 mhroncok: I think *any* test is bound to fail if the package cannot be installed. 15:28:52 bodhi has a number of open pull requests for gating rawhide! 15:29:25 this has been a long dicsussion 15:29:28 yeah 15:29:28 do we sish to continue 15:29:30 ? 15:29:33 wish 15:29:35 it's high on the infra priority list... 15:29:37 I think it's fine to set a policy that depends on stuff that we expect to happen soon 15:29:44 is anyone opposed to the slow option? 15:29:50 just let FTBFS pick it up next round? 15:29:58 keep in mind we are free to change our minds later 15:30:02 not a permanent decision 15:30:07 Not opposed. 15:30:15 IMHO letting FTBFS pick up is like doing nothing 15:30:16 bowlofeggs: that is the status quo 15:30:21 * nirik is fine with that for now, but not handling the runtime deps is not great 15:30:23 tyll: exactly 15:30:33 I'm not opposed, it wold be great if we had immediate notification to maintainers of dependent packagers ... but that's a bonus, not a requirement 15:30:36 but we agreed we want to do something :-) 15:30:54 well, the medium option requires more work right? is anyone available to do that? i'd +1 it too 15:31:32 I think we can vote conditionally that the medium option is wanted, and we ask volunteers to work on the implmenetation. 15:31:40 sure 15:31:41 if nobody is going to implement it, then I would be more in favor of retiring dependent pkgs directly 15:32:35 I mean if nobody is implementing the medium option 15:32:37 so "the medium speed" thing is: when a long orphaned package is retired, bugz are filled for dependent packages and FTBFS-like policy applies there 15:32:46 filed 15:32:51 yeah 15:32:55 ack 15:32:57 and then they get their 6 weeks to respond 15:33:05 if someone can implement that, that does sound ideal to me 15:33:24 Shouldn't be *that* hard. 15:33:34 for the record: until that is automated, I'm not going to file those bugzillas when i retire packages 15:33:34 +1 15:33:35 maybe since we are so powerful as FESCo, we can just *demand* that someone implement it ☺ 15:33:53 .fire bowlofeggs for getting overconfident 15:33:53 adamw fires bowlofeggs for getting overconfident 15:33:55 bowlofeggs: we could, but it wouldn't do much good. ;) 15:33:57 hahaha 15:33:58 bowlofeggs: sure, we demand you do it 15:34:01 hahaha 15:34:10 Yeah, that seems to work. We just will things into existence. 15:34:13 +1 too 15:34:43 could we approve the slow option *and* the medium option 15:34:45 ? 15:34:50 actually to implement the mediums speed thing, someone also needs to actually retire the long-time FTBFS pkgs 15:34:56 bowlofeggs: the slow option doesn't need to be approved 15:34:59 allowing someone to implement the medium option, and just do the slow option until then? 15:35:02 well, the slow option doesn't need any approval, it's what we are doing now? 15:35:19 sure 15:35:28 ok, so let's just vote on the medium thing and hope that someone does it? 15:35:30 hahaha 15:35:56 * tyll is not +1 for medium if it is not going to happen - then I would prefer the immediate retirement 15:36:01 we could advertise that we need some help on devel list 15:36:04 that might get someone 15:36:28 Asking nicely always helps more than demanding 15:36:43 proposal: I'll summarize this on the ticket, send an email do devel asking for help 15:36:44 lets try and get some help, if it fails revisit next week? 15:36:49 jforbes: but it's more fun to say "the power of fesco compels you!" 15:37:09 mhroncok, nirik: +1 15:37:32 +1 mhroncok 15:37:44 mhroncok: +1 15:37:56 mhroncok: +! 15:37:58 +1 15:38:00 mhroncok: +1 15:38:18 +1 15:38:33 # action mhroncok will summarize this on the ticket, send an email to devel asking for help 15:38:36 mhroncok: +1 15:38:41 I don't think we need a formal vot for this 15:38:47 next topic 15:39:02 #topic #2060 F30 System-Wide Change: DNF Better Counting 15:39:02 .fesco 2060 15:39:02 https://pagure.io/fesco/issue/2060 15:39:21 zbyszek sent aproposal 7 days agao 15:39:33 oh, missed it. +1 to that 15:39:35 technically this should get autoapproved today 15:39:49 yet +2 is not too confident 15:40:12 that is +3 now with nirik 15:40:32 is there anyone who would want more time for this? 15:40:46 I am not sure why the implementation will hape to make it clearer how to do the countme syntax 15:40:51 will help 15:41:01 +1 15:41:16 tyll: Because when implmenting things, details of design are much easier to see 15:41:25 I thought I had +1'ed that already 15:41:40 +1 15:42:32 do i see +5? 15:43:00 zbyszek: the implementation of the reporting is rather simple AFAICS, if at all then implementing the analytics with some real data would help to figure out whatis needed 15:43:01 I suppose zbyszek is +1 as well, or definitively not -1 15:43:10 +1 from me too (also in ticket just now) 15:43:23 mhroncok: we voted (previous fesco) that the proposer is automatically +1 15:43:38 zbyszek: good to know, not sur if documented 15:43:53 that is +7 15:44:01 * tyll is 0 15:44:05 tyll: thanks 15:44:09 (they can always change to -1 explicitly, but that's rather rare) 15:44:25 mhroncok: I'll try to find the reference. 15:44:40 tyll: do you think we should give this more discussion? 15:44:47 it saved us from a bunch of "hey , are you for your own proposal?" questions 15:44:49 haha 15:45:29 mhroncok: IMHO we should agree on/approve an actual specification 15:45:57 currently it is very vague 15:46:24 would we want to say "proceed with the change, yet submit it for re-approval once implemented"? 15:46:40 also not sure if this shouldn't be approved by council as well 15:47:00 mhroncok: that's a good suggestion 15:47:12 we can say that we like the direction but want to see more detail for final approval 15:47:45 * mhroncok would +1 that 15:48:07 I'd trust the people involved to make a reasonable choice. Any of the proposed implementation details seems good enough to me. 15:48:09 (we technically approved zbyszek's proposal, but I see tyll's point) 15:48:30 if there isn't enough support for this, we can move on 15:48:42 If we feel that the implmentation leaks too much information, we can always opne a new ticket. 15:49:25 but is now going to be implemented first, countme with a boolean or a counter? 15:49:46 What is now... 15:50:39 boolean is whats on the change page 15:50:55 oh, it has counter as optional 15:51:15 so not sure. 15:51:31 this is my point, IMHO it should be clear what is going to happen when we approve this 15:51:51 yeah i think what tyll is saying is reasonable 15:51:57 let's make a second vote so we are sure what we want 15:52:14 proposal: proceed with the change, yet submit it for re-approval once implemented 15:52:18 +1 15:52:19 mhroncok: +1 15:52:21 I kinda agree. I'm ok with either thing, but it would be good if they said what they were doing... 15:52:47 mhroncok: +1 15:52:54 That's just it, I am okay with either thing as well, so why force more overhead? 15:53:25 jforbes: exactly 15:53:28 I take it by this, tyll is okay with one, but not the other 15:53:36 zbyszek's proposal has +7,1,-0 15:53:56 this proposal is +5 if I count "I'm OK with both" 15:54:27 I'm +1 for either if it moves things forward, but do trust people to implement it with privacy in mind and come back and ask us if it's not clear 15:54:30 flipping tyll to a +1 is a good thing too though imo 15:55:08 +8, 0, -0 is a little better than +7, 1, -0 15:55:19 I think anyone can see the implementation and raise concerns then... bringing it back for another approval round seems like a lot of overhead... but sure. 15:55:28 mhroncok: Okay with either thing in this regard, meant the bool or counter. I am not particularly in favor of forcing more red tape if no one is against their implementation 15:55:32 i'm also fine either way 15:55:32 since it is a sensitve topic, I would in favor to have the actual implemention under crucial review even though if I trust the implementers to handle in good faith they might miss something 15:56:32 I guess we can always volunteer to review the code 15:56:35 sure, I guess we can... 15:56:38 I'll vote +1 to the updated proposal, even though I don't think this additional step is necessary 15:57:50 tyll: would you be willing to act as a fesco shepherd on this thing or whatever is that thing called? 15:58:34 mhroncok: not sure I understand what you are asking 15:59:08 my idea is that we approve the change, but you personally would work with the change owners to make sure the implementation is good(tm) 15:59:43 you would act as a fesco delegate in the matter, making sure it doesn't go crazy 16:00:00 (it's just an idea) 16:00:58 mhroncok: sure, I can review it again 16:01:16 tyll: does that keep you at 0? 16:02:03 mhroncok: eh, I guess so, because this means that I would be giving my approval later after I reviewed it... 16:02:10 sure 16:02:40 #action tyll will work with change owners to make sure the actual implementation is sane 16:02:57 #agree APPROVED (+7, 1, 0) 16:03:04 (goes for the change) 16:03:58 * mhroncok waits couple seconds if somebody has a bureaucratic remark about what i just did 16:04:53 nirik: does #agree also work, or does zodbot recognize only #agreed? 16:04:55 "you are technically correct, the best kind of correct." -a bureaucrat from futurama 16:05:17 https://fedoraproject.org/wiki/FESCo_meeting_process says afree 16:05:18 I think it may only be agreed... 16:05:19 agree 16:05:25 #agreed APPROVED (+7, 1, 0) 16:05:30 anyway npow we have both 16:05:33 * nirik looks 16:05:46 Yeah, I noticed that in the Wiki recently and meant to ask 16:06:00 * mhroncok waits 16:06:01 either works 16:06:03 good 16:06:03 ok 16:06:13 #topic #2065 F30 System-Wide Change: GCC9 16:06:13 .fesco 2065 16:06:13 https://pagure.io/fesco/issue/2065 16:06:24 This is already approved, is it not? 16:06:33 It's de facto approved at any rate 16:06:41 Since we held the mass-rebuild for it 16:06:43 sgallagh: by whoom? 16:06:49 it didn't get to 7 days yet 16:06:53 Formality, in that we approved holding the mass rebuild for it 16:07:06 this actually makes me wanna go -1 just to enjoy some fun :D 16:07:11 anyhow, +1 here. 16:07:11 ha 16:07:25 +1 16:07:30 +1 16:07:32 it didn't go 7 days and until now there was no vote 16:07:38 +1 16:07:54 mass rebuild has usual number of failures 16:07:56 so +1 16:08:05 +1 16:08:27 I really think this was covered under 16:08:28 .fesco 2066 16:08:29 sgallagh: Issue #2066: Delay mass rebuild by a day, that is on Jan 31st 2019 - fesco - Pagure.io - https://pagure.io/fesco/issue/2066 16:08:42 sgallagh: no, that was clearly about delaying the mass rebuild 16:08:54 it said nothign about our approval of gcc9 16:09:08 It was specifically to delay the mass rebuild so that gcc9 wouldn't break it 16:09:17