15:00:03 #startmeeting FESCO (2019-04-08) 15:00:03 Meeting started Mon Apr 8 15:00:03 2019 UTC. 15:00:03 This meeting is logged and archived in a public location. 15:00:03 The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:03 The meeting name has been set to 'fesco_(2019-04-08)' 15:00:03 #meetingname fesco 15:00:03 #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:03 #topic init process 15:00:03 The meeting name has been set to 'fesco' 15:00:03 Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:08 .hello2 15:00:09 sgallagh: sgallagh 'Stephen Gallagher' 15:00:12 .hello psabata 15:00:13 contyk: psabata 'Petr Šabata' 15:00:13 .hello kevin 15:00:16 .hello2 15:00:16 nirik: kevin 'Kevin Fenzi' 15:00:18 .hello2 15:00:20 bookwar: bookwar 'Aleksandra Fedorova' 15:00:22 jforbes: jforbes 'Justin M. Forbes' 15:00:52 hey 15:00:54 So, to make up for last week's lack of any agenda items, we have a very full agenda today. 15:01:07 .hello2 15:01:08 bowlofeggs: bowlofeggs 'Randy Barlow' 15:01:10 .hello2 15:01:11 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:22 I'll have to drop after 30 minutes, sorry. 15:01:36 * contyk will have to drop after 60 15:01:46 zbyszek, contyk: Which items do you want to discuss most? I'll hit them first 15:02:39 .hello2 15:02:40 bcotton: bcotton 'Ben Cotton' 15:02:54 I suggest starting with new meeting time, so we don't repeat this next week 15:02:55 Dunno, they all seem important. 15:02:58 no preference; you'll cover it if we don't get there in time 15:03:21 mhroncok: +1 15:03:24 mhroncok: I didn't put that on the agenda; we need to do a WhenIsGood 15:03:37 #action zbyszek to do whenisgood 15:03:39 .hello2 15:03:41 otaylor: otaylor 'Owen Taylor' 15:03:42 zbyszek++ 15:03:46 zbyszek++ 15:03:53 ok, let's move on 15:04:01 I was going to put one together, then got busy before the meeting. Thanks zbyszek 15:04:10 #topic #2102 F31 System-Wide Change: Gating Rawhide Packages 15:04:10 .fesco 2102 15:04:11 sgallagh: Issue #2102: F31 System-Wide Change: Gating Rawhide Packages - fesco - Pagure.io - https://pagure.io/fesco/issue/2102 15:04:51 I have to say that I like the new proposed gating scheme quite a bit 15:05:05 * pingou around for questions/precisions 15:05:23 It looks something that is comprehensible and functional and relatively easy to opt-out if necessary 15:05:26 There was some discussion in the ticket, but I think we (FESCo) have not been really fair to the CI/Gating team this last year. 15:05:38 * nirik is in favor 15:05:55 But the problem is that the CI feels flakey, and this is going to put very big pressure on the CI. 15:06:03 I'm firmly in favor of the proposal, but I understand that there are concerns about the CI reliability. 15:06:30 I tend to agree with dperpeet that those issues are probably not getting the priority they need because there's no immediate blocking reason to focus on it. 15:06:35 I agree with technical aspects of the proposal. pingou did a very good job collecting the feedback for round two 15:06:46 pingou++ 15:06:47 sgallagh: Karma for pingou changed to 17 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:07:03 but I don't agree that opt-in gating will amke the situation better 15:07:08 I think that as long as the gating starts as opt-in, it gives us time to work out the issues and ramp up 15:07:16 pingou++ yes! great work on putting this together 15:07:16 nirik: Karma for pingou changed to 18 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:07:17 the CI is... broken 15:07:22 pingou++ 15:07:27 sgallagh: to become more stable, ci needs attention, to get an attention, ci needs to get users, and to get users, ci needs to become more stable 15:07:35 thank you for the cookies :) 15:07:44 bookwar: yep. 15:07:59 Proposal: If we agree to opt-in gating, every FESCo member that is a package maintainer agrees to opt at least one of their packages in to help work out the kinks. 15:08:13 I would like to get more of a promise from the CI team that there are resources and will to fix any such issues. 15:08:16 bookwar: please help me understand how more attention => more stable 15:08:26 ha 15:08:33 sgallagh: I am not sure we can do that in kernel 15:08:34 I'm not saying "fix the CI before we gate" 15:08:35 i will abstain since i am involved in this proposal (but i have opted-in bodhi, so i have been using gating) 15:08:36 sgallagh: by what date? :) 15:08:37 I say "get a plan" 15:08:46 contyk: By the end of April 2019 15:09:09 sgallagh: I already opt-in for Pull Requests with CI -> it simply doesn't work 15:09:15 mhroncok: people learn how to use it, they share experience how to use it in a right way, infra team learns how to support it and gets more experience with that 15:09:16 not sure I can commit to that 15:09:17 jforbes: I'm willing to except kernel on general principle :) 15:09:47 That said, I am looking forward to the day that we can 15:09:59 contyk: Even just a basic "it can be installed" test? 15:10:05 I don't think we should force anyone to opt in. ;) I'm happy to opt in some... 15:10:33 nirik: I'm trying to make the point that if FESCo is going to continue to be timid about this, we at LEAST need to be trying the damned thing 15:10:35 mhroncok: is that koji-simple-ci? or ? 15:10:40 sgallagh: perhaps; but considering the PTO, I'd need to get it working before Friday :) 15:10:45 And yes, mhroncok: thank you for your efforts on this front 15:10:46 nirik: Fedora CI pipeline 15:10:51 ok 15:11:08 simple-koji-ci is broken for f29 and f30 as well 15:11:16 but that's a different story 15:11:24 * pingou puts it back on its todo (somehow it got lost) 15:11:33 sgallagh: well, sure, but how about we just say 'fesco members will opt in packages as they can/urge others to do so' or something. 15:11:52 I don't think fesco members opting in makes a difference 15:12:01 anyhow, +1 to the change 15:12:14 sgallagh++ 15:12:20 * mhroncok remains -1 until a plan for sustainable Ci is proposed 15:12:34 Maybe the problem with CI is it is stuck 49 years in the past according to fedmsg :) 15:12:47 I'm very much *for* the change, but I don't want to have another case where we build something which is nonfunctional because of missing prerequisites. 15:12:47 I'm sorry but I don't see how broken CI with gating get's CI fixed 15:13:27 ... and there is no clear plan to add those prerequisites. 15:13:36 mhroncok: It puts more pressure on CI to get fixed 15:13:49 this being hold on becasue CI does as well 15:14:00 mhroncok: Let's turn this around. What is the MVP for CI to turn on gating? 15:14:07 A basic install test? 15:14:10 I mean, making CI a prerequisite for gating puts presure as well 15:14:26 sgallagh: I can agree to that, yes 15:14:58 mhroncok: Ok, and with what reliability? 15:15:13 Is it okay if flakes ever happen? How often can they happen before it's a blocker? 15:15:28 I'd be more inclined to say basic install test of the package + dependent packages, but that makes it hard for packages with thousands of dependent that are usually broken by unrelated bugs 15:15:28 (Not trying to come across belligerently, just trying to figure out what our target is) 15:15:48 it's not just about being flaky 15:16:03 it about basic UX: when the pipeline is broken, we cannot tell why 15:16:21 we again missing the point 15:16:26 mhroncok: Can you cite a specific example, please? 15:16:30 sure 15:16:39 mhroncok: you are talking about dist-git _CI pipeline_ 15:16:51 it is just one of the pipelines which we can run in gating 15:17:05 https://pagure.io/fedora-ci/general/issue/44 15:17:09 https://pagure.io/fedora-ci/general/issue/43 15:17:19 bookwar: Is there a doc listing what the various pipelines are? 15:17:36 taskotron, openqa and the CI pipeline 15:17:52 https://pagure.io/fedora-ci/general/issues?status=Open&tags=new+pipeline 15:17:55 all of which are posting results to resultsdb and can thus be considered when gating 15:17:57 taskotron wants to move their own stuff to the CI pipeline 15:18:36 true 15:18:44 but I do not know the eta for this 15:18:56 mhroncok: it will be a separate pipeline, and its logs will be different from that of distgit pipeline logs 15:18:59 And I don't really know if openqa is the right hammer for the "basic install test" nail 15:19:08 bookwar: it will? 15:19:32 bookwar: aka it's a "future" thing? 15:20:11 I personally don't want gating based on any tests done on a non koji build. Only because one of the most important tests I would like to gate on would fail anywhere else 15:20:44 mhroncok: it is still on discussion how end result is going to look like 15:20:49 Let me be clear about one thing. I do not want to leave this meeting without either A) a firm list from FESCo of things that must be done and a commitment that gating is approved once they are or B) a firm decision to abandon this. 15:20:49 Continuing to string the CI team along is unfair and unproductive. 15:22:27 for A) I'd like to get a Fedora Objective (or similar) that addresses the CI problems mentioned https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QUDIXHS4EWJFILODUL6JZJOAWCQ5M5L7/ 15:22:49 mhroncok: i think we need to work on a different thing here: we need a list of requirements towards CI pipeline. Any CI pipeline. And then whenever we would like to enable a certain pipeline in Fedora gating we will use this list of criteria to decide. But we anyway need gating to be able to enable and disable pipelines 15:23:02 well, I agree the issues mhroncok points out need to be fixed. I don't think blocking the gating work makes sense to get that fixed... 15:23:04 and if the problems are to be fixed by a "new pipeline", I'd like to see that planned and defined as well (or instead) 15:23:09 mhroncok: I believe this is what dperpeet is working on :) 15:23:14 My personal feelings on things as they are 1) I am fine with turning on gating as opt-in now. That allows people who are willing to help get this stable. 2) Changing it to opt-out would be the next step, and require another change proposal. 3) Eventually changing the opt-out to requiring a FESCo approval would be the goal, but requiring yet another change proposal 15:23:22 pingou: but I got no answer for a month 15:23:45 pingou: a simple, yes, we know about this, we plan to fix this by XYZ (or we don't), would do 15:23:47 jforbes: +1 15:23:55 jforbes: +1 15:24:00 does the opt-in vs. opt-out nature of gating make a difference for you mhroncok? 15:24:05 mhroncok: he replied on the FESCo ticket last week, and I've been tasked by him to pressure him into writting this objective :) 15:24:12 jforbes: If that's a proposal. I'm +1 on it 15:24:25 bowlofeggs, pingou: how many engineering time you expect to spend on gating? 15:24:31 jforbes: +1, current gating change has almost no impact at all, any next changes - onboarding pipelines in to gating, switching to opt-out and so on, should pass through change management process 15:24:32 jforbes: +1 15:24:35 mhroncok: it's my top priority currently 15:24:50 mhroncok: though to be honest, i'm not working on the CI pipeline itself, but the bodhi side of it 15:25:01 I'd rather not waste that engineering time on something that has missing prerequisites 15:25:10 mhroncok: it's a priority for a number of person at this point 15:25:18 FTR, that's +6 for jforbes proposal 15:25:28 What about the following reqs: 1. a simple "can-install" test that can be easily opted into, 2. a way to run the CI tests locally, 3. if the tests fail, the output needs to be comprehensible to a normal packager 15:25:40 zbyszek: +1 15:25:45 mhroncok: existing ci pipeline is not a prerequisite for implementation of a gating framework 15:25:55 bookwar: not for implementing it 15:25:58 bookwar: for using it 15:26:01 thats reqs for what? enabling a pipeline? 15:26:05 we can implement this 15:26:13 but without a wokring CI, it's wasted work 15:26:31 zbyszek: I feel those don't need to block opt-in gating, though they all sound like good things to have 15:26:39 jforbes: +0, not because I disagree, but because I think points and 2. and 3. are so far out in the future, it doesn't make sense to vote on them now. 15:26:44 i think it should be ok for the pipeline to not be perfect as long we are make it opt-in 15:26:57 that is OK 15:27:06 investing engineering time to this? I don't think so 15:27:07 zbyszek: The proposal specifically says they have to be voted on in the future 15:27:20 zbyszek: I think we can expect the CI team to prioritize without using a big stick "you can't turn on opt-in gating without having these things" 15:27:41 mhroncok: well, isn't the engineering time investment not something for fesco to decide on? (i.e., i do it because my mgmt wants it) 15:28:21 bowlofeggs: as the main body of fedora engineering, it is precisely FESCo job to decide on 15:28:34 bowlofeggs: you cans till do it if you mgmt wants it 15:28:41 well, serializing things doesn't make sense to me here... if we wait until we have a good pipeline to start working on gating it's going to take a lot longer than if we work on both. 15:28:45 *still 15:28:57 nirik: I'd like a plan 15:29:06 nirik: not getting it done before we do gating 15:29:13 a plan 15:29:41 Such a plan makes sense if we were talking about opt-out (or mandatory) gating 15:29:47 mhroncok: i'm not sure fesco's purpose is making that sort of decision. i think our job is more about setting criteria, not priorities 15:29:55 I think we can trust people to make their own staffing decisions otherwise 15:30:00 1) get a gating framework setup and at the same time 1) work on the existing pipelines or fix them, 2) decide what pipeline to use when the gating framework is ready (if any) 15:30:13 bowlofeggs: Yes. And my criteria is: have a plan ready for the CI 15:30:13 i guess the council makes priority calls (or each person/person's manager) 15:30:39 yeah i think having a plan is good ☺ 15:31:07 I can see that this is maybe only my opinion here and you can outvote me, but I cannot +1 this with clean conscience 15:31:34 We are now at thirty minutes. I'm going to call a formal vote on the simplest part of this, which is: 15:31:34 Proposal: Opt-in gating may be enabled. 15:31:39 I have to run now. mhroncok has my vote, so please count his vote as +2 (or -2, whatever). 15:31:54 sgallagh: +1 15:31:56 sgallagh: +1 15:31:59 sgallagh: -1 15:32:00 +1 to my proposal 15:32:05 i still abstain since i am involved (but i informally am +1 ☺) 15:32:08 sgallagh: +1 15:32:18 +1 15:32:45 * nirik wonders if this is actually a "change" since it's only affecting rawhide. 15:32:52 mhroncok: jfyi, from my side there are several plans: 1) improve STR to make dist-git pipeline more usable 2) choose one of the tests Fedora QA already running and get them into gating (kochei, rpmdeplint,..) and let Fedora QA drive it 3) add rpm-inspect job to. None of these is final yet. All is going in parallel in the background, and i believe it shouldn't be blocking for the current task 15:33:00 nirik: yeah i had that thought too 15:33:06 bookwar: Do you want to vote? 15:33:19 sgallagh: i am +1 for gating change 15:33:27 #agreed Opt-in gating may be enabled. (+6, 1, -2) 15:33:28 bookwar: my understanding is that Fedora QA is not going to be responsible for those systems going forward 15:33:29 bookwar: I am more interested in "get 5 more people to work on this" plan 15:33:39 systems/tests 15:33:39 I wasn't sure either, but I felt it was potentially important enough for Fedora that it could use the publicity and processes in the change-proposal procedure 15:33:46 mhroncok: sorry, but you can not get such thing 15:33:55 bookwar: I know :( 15:34:20 #topic #2109 Policy revamp: Package Removal for Long-standing FTBFS and FTI bugs 15:34:20 .fesco 2109 15:34:22 sgallagh: Issue #2109: Policy revamp: Package Removal for Long-standing FTBFS and FTI bugs - fesco - Pagure.io - https://pagure.io/fesco/issue/2109 15:34:22 mhroncok: this is always the problem 15:34:32 mhroncok: You added this to the agenda. Want to lead it? 15:34:46 sgallagh: I added it because t is getting stalled 15:34:59 * bowlofeggs is +1 in ticket 15:35:00 tflink: it depends on what you call "responsible for a system", for global generic tests i see fedora qa driving the content of the test. But we need to discuss it in a separate thread 15:35:37 FWIW, I'm +1 to the latest proposal in the ticket. 15:35:42 bookwar: my understanding of the situation is different but I agree that right here and right now is probably not the place to be discussing it 15:35:45 I asked about the needinfo thing, it was indeed dropped in bugzilla5 15:35:55 bookwar, tflink We're moving on. Please move it to another channel. 15:36:10 +1 to latest proposal 15:36:14 mhroncok: I would like to see an email added to the needinfo time frame as well... Reasoning is this, people filter bugzilla mail, a direct mail would increase visibility in the event of extended vacation 15:36:21 Wait, needinfo is gone? 15:36:24 jforbes: an e-mail is there 15:36:36 https://pagure.io/fesco/issue/2109#comment-563753 15:36:38 no, it's there, but it does not mail you a list of needinfos every week 15:36:40 here is TLDR 15:36:45 oh 15:36:52 Which sucks, but oh well 15:36:58 an imprtant question is: shoudl we block this on NEEDINFO or not? 15:37:27 mhroncok: an email is there, I meant an additional email at the time of the needinfo 15:37:43 it seems it's a WONTFIX so if we want more comments or e-mails, I can add that 15:38:02 jforbes: after 1 week, you set NEEDINFO + e-mail? 15:38:19 mhroncok: yes, just to make sure they have every opportunity 15:38:34 email to pkg-owner@, I assume? 15:38:39 yes 15:38:48 +1 to that amendment 15:39:22 I think it's an overkill but I don't want to bikeshed the policy on that, so consider me OK 15:39:32 it would be nice to automate things... but this can work for a first cut 15:39:38 sgallagh: +1 15:39:56 just to make this obvious 15:39:57 yeah i would like it automated, but would not require that 15:40:00 proposal: ... 15:40:07 it would obviously work better if automated though 15:40:09 mhroncok: Only because, if you set a bug needinfo for me, I won't see that until I look into that bugzilla folder. a direct email goes to the inbox. 15:40:22 Formal proposal: https://pagure.io/fesco/issue/2109#comment-563753 is approved, with one amendmend that we add an email to pkg-owner@fp.o at the NEEDINFO step 15:40:40 sgallagh: +1 15:40:42 sgallagh: +1 15:40:49 sgallagh: +1 15:40:50 sgallagh: +1 15:40:51 +1... 15:40:54 sgallagh: +1 15:41:13 sgallagh: +1 15:41:56 #agreed https://pagure.io/fesco/issue/2109#comment-563753 is approved, with one amendmend that we add an email to pkg-owner@fp.o at the NEEDINFO step (+8, 0, -0) 15:42:06 #topic #2113 F31 System-Wide Change: F31 Mass Python 2 Package Removal 15:42:06 .fesco 2113 15:42:07 sgallagh: Issue #2113: F31 System-Wide Change: F31 Mass Python 2 Package Removal - fesco - Pagure.io - https://pagure.io/fesco/issue/2113 15:42:24 anyone got a chance to read this? 15:42:38 it has been 6 days without a vote 15:43:05 Not too thoroughly, but as I'm in the "just stop shipping python2 in the distro and let it all burn" camp, I'm good with whatever you propose on this score :) 15:43:12 I don't have any better ideas on how to do this... :) 15:43:24 so, +1 from me. 15:43:24 sgallagh: I like that camp 15:43:36 * sgallagh grabs the marshmallows 15:43:38 Really, we are being as nice as possible here. 15:43:41 * nirik wonders if he should ask to keep calibre around or not. 15:43:42 yeah i am also in the python 2 is game over camp 15:44:16 * mhroncok quickly preps a "just stop shipping python2 in the distro and let it all burn" Fedora 32 change :D 15:44:25 i confess that i haven't made the time to read this yet myself 15:44:38 We have to realize that we are going to lose some things that people use ... but having the most software isn't Fedora's #1 goal 15:44:42 mhroncok++ 15:44:46 I think this is as gracefull as we can be... 15:44:50 It's not exactly time critical, so if you need one more week, I'm good 15:44:51 we do need to get agressive about python 2 removal at some point 15:45:26 I think I'm +1 15:45:33 Yeah, I'm +1 here as well 15:45:38 and there is no discussion on a mailing list.. 15:45:41 i'm +1 15:45:57 bookwar: I think there's a certain amount of exhaustion-apathy around py2 removal at this point 15:45:58 +1 15:46:17 bookwar: I suspect that people who will be angry about this will only be angry once their package is gone or force removed 15:46:25 sgallagh: i have a feeling that it is because people haven't seen the actual list of packages affected by it 15:46:38 it seems that people who actually follow the proposals are in the remove-python2 camp 15:47:03 mhroncok: indeed, is it possible to prepare a list of affected packages and alert people the same way you do fororphans? 15:47:13 bookwar: https://fedora.portingdb.xyz/ 15:47:15 mhroncok: Can I count you as +1? :) 15:47:26 sgallagh: yes 15:47:45 I'm at +5 then, which makes this approved. Anyone else want to add their formal vote? 15:47:48 mhroncok: yes, but when you send a mail with all maintainers affected listed in it, it works better i think 15:47:52 sgallagh: +1 from me 15:48:08 bookwar: does that work with 2k packages? 15:48:35 mhroncok: ok, point taken ) 15:48:41 Oh, I missed nirik's +1 above. 15:49:04 #agreed "F31 Mass Python 2 Package Removal" Change is approved. (+7, 0, -0) 15:49:11 #topic #2114 What is the scope of Modularity? 15:49:11 .fesco 2114 15:49:13 sgallagh: Issue #2114: What is the scope of Modularity? - fesco - Pagure.io - https://pagure.io/fesco/issue/2114 15:49:22 this one should be easy :D 15:49:57 Oh, look at the time. 15:49:58 so far only igor attempted to answer. with "I think we should be aiming to go fully-modular" 15:50:03 * sgallagh runs 15:50:07 :D 15:50:47 I think we should have boundries... but I am not sure 100% what I think they should be. 15:50:48 asamalik's comment is very good, but not sure if it helps getting an answer 15:51:05 * sgallagh is reading fast, as he missed the emails for this and saw this ticket for the first time when writing the agenda 15:51:25 sgallagh: we can skip it now and continue in the ticket 15:51:26 (Filter failure in my emails) 15:51:38 I don't expect us answering this question here 15:51:39 Yeah, I think that might be best. 15:51:51 i forgot to comment on this too 15:51:56 #info Discussion is active in the ticket, let it bake there a bit longer. 15:51:59 +1 for continuing in ticket 15:52:28 I'll try to internalize and comment on it thoroughly later today. 15:52:30 yeah this is a complex topic 15:52:58 #topic #2115 Missing PkgDB features should be implemented 15:52:58 .fesco 2115 15:52:59 sgallagh: Issue #2115: Missing PkgDB features should be implemented - fesco - Pagure.io - https://pagure.io/fesco/issue/2115 15:54:07 * nirik still thinks this is a waste of time, but sure, +1 to get it done so we can move on 15:54:28 So, I read through this earlier, and while I completely agree with the intent, I don't see the point. We don't have a budget to put resources on this 15:54:38 we don't 15:54:54 I realize this might end up ignored 15:54:59 might? 15:55:04 but I still think this needs to be said 15:55:11 I think what mhroncok is asking for is a Non-Binding Resolution from FESCo 15:55:21 you could say that 15:55:24 it's a stement 15:55:38 Proposal 2, let the java packages retire, things burn, then things have to be addressed. 15:55:51 I like to print it out on a card to play against other things or when talking to bowlofeggs's management 15:55:53 depending on the scope of work to be done, i'll note that you can always ask the Council to fund a hackfest 15:56:11 Though realistically it wouldn't be handled in the way that we want for long term 15:56:24 bcotton: We're talking about a long-term project, including maintenance. 15:56:26 It's a big ask 15:56:34 (and also a firm statement from FESCo gives mattdm some leverage to ask people's managers to do stuff) 15:56:58 disclaimer: I do plan to carry this to Council as well 15:57:07 bcotton: i would think a hackfest might not be enough time to do it all, but i bet we could hit a subset at such a thing and make a worthwhile step in the right direction 15:57:16 i think it shouldn't be managed by FESCo and voting process, it s more like product management and product ownership activity, so i'd suggest to find an area (wiki, docs, taiga?) to work on some details/documents and then see if we can build smth like Google Summer of Code project out f it 15:57:23 I think the main question is this: does FESCo consider this need-to-have or nice-to-have? 15:57:38 sgallagh: good point 15:57:47 Are we willing to burn political capital to try to get these changes made, or are there better ways to spend it? 15:58:02 sgallagh: i personally think it's a need 15:58:11 I consider 2 major pain points are currently hurting Fedora - this and the undefined scope of modularity 15:58:33 as I noted in the ticket, I want all these things. But currently there are more important things going on. As soon as we can get cycles to work on these things we will... fesco making a resolution doesn't really change that I don't think. 15:58:37 I'm not convinced it's a "need" right now. 15:58:40 so I consider this a must 15:59:00 Though the Java debacle is concerning. 15:59:25 sgallagh: very concerning 15:59:28 But while things are inconvenient in many places, I don't see any that are really impossible to work around 15:59:30 we do have that problem where we are not gaining contributors. i can't say that doing this will gain us contributors, but i believe that it is a reasonable suggestion to attempt to help with it 16:00:08 sgallagh: yeah not impossible, but i do think contributing to fedora is significantly more painful today than it was 2 years ago 16:00:19 this problem has a potential of loosing contributors 16:00:33 bowlofeggs: I don't see this particular proposal as helping to gain contributers, though it may stop us from losing some 16:00:35 and that seems bad for new contributors and for occasional contributors 16:00:59 jforbes: yeah i don't have data to back up my position, it's just my opinion 16:01:14 Sure, but if the goal is to gain/not-lose contributors, is this the best avenue? 16:01:38 I don't think it's 'significally' more painfull..all the things in this ticket are things most people do rarely 16:01:41 More automation to navigate these choppy waters might be a better ROI than reimplementing PKGDB 16:01:45 (hypothetically) 16:02:09 I think we'd want to really comprehensively think about hte contributor UX 16:02:15 nirik: i hit these things more often than rarely 16:02:24 otaylor: +1 16:02:34 I agree. 16:02:37 bowlofeggs, mhroncok I am concerned that sgallagh is not concerned enough :) Do you think you can rework the text a bit and add actual use cases from a point of view of new contributor or old one, and how the lack of a certain feature makes the work harder? 16:02:56 sgallagh: well i think what we are saying is that we want more automation 16:02:57 I'm -1 to a FESCo resolution on this and I'd rather see someone pitch a general Packager UX Objective to the Council 16:02:59 bowlofeggs: odd. I wouldn't think most packagers would 16:03:28 sgallagh: or maybe you mean a specific type of automation? we're basically saying that computers used to do a lot for us, and now humans do it 16:04:07 nirik: it's hard for me to guess how often contirbutors would hit this, but consider that a new contributor would hit many of these immediately 16:04:25 so for *new contributors* specifically, we don't have a good story 16:04:30 bowlofeggs: yeah, once initially for their new package... but then... not for a long time? 16:04:31 and i think that matters 16:04:47 nirik: yeah perhaps, but are they going to get through it all? 16:04:53 again, no data, opinions, etc. 16:05:07 well, it's not so much as 'get through it' as 'there are delays because of humans' 16:05:25 for a new contributor, as long as things happen reliably, it's in some ways less of an issue if it's slow than for mhroncok who needs to do *many* of these things .OTOH, if they don't happen reliably, then a new contributor is much more inconenienced 16:05:44 Is there a proposal we expect to see in this meeting, or should we take this to the ticket and proceed? 16:05:49 anyhow, I agree we want this fixed, I think if fesco wants to press for this, talk to the council and/or cpe managers... 16:05:50 bookwar: do you think the text doesn't cover what was easier and is now harder? 16:06:26 sgallagh: we can go to ticket. also, it's just a statement, not a decision ☺ 16:06:54 we just thougth that the voice of fesco would be more powerful than a thread on a mailing list 16:06:56 bowlofeggs: I think the problem statement is perfect for a pitch to the Council for an Objective 16:07:17 sgallagh: and I think a fesco agreed statement would help with that 16:07:18 Or even a pitch to the Community Platform Engineering team at Red Hat. 16:07:27 or that as well 16:07:31 sgallagh: yeah, and there actually already is one, but we wanted to have that "non-binding resolution" statement from fesco that says we also think… something… ☺ 16:07:43 sgallagh: +1 16:07:45 as mentioned, it will also help this kind of thing once we have a taiga setup... 16:08:07 we don't need to make such a statement if people on fesco don't want to, of course ☺ 16:08:09 bowlofeggs: I don't disagree that all of these proposed changes are desirable. 16:08:38 But I'm wary of using our very limited political capital on this without any clear idea of what it will gain us. 16:08:42 bowlofeggs: i think it might be more convincing if there is a personal perspective added to it. Like user story. You can write them from a newcomer point of view, or from Fedora infra admin point of view, or Fedora module maintainer point of view 16:08:48 Because all we have are opinions and guesswork at the moment. 16:09:09 sgallagh: fair 16:09:19 bookwar: that makes sense 16:09:42 Now, show me that a particular process is impacting our ability to deliver X in a reasonable manner, you'll have me right beside you 16:10:49 good points 16:11:03 i think we can move on 16:11:06 agreed 16:11:12 ok 16:11:27 #info Discussion will continue in the ticket 16:11:35 #topic #2116 Moving forward with zchunk metadata for F30? 16:11:35 .fesco 2116 16:11:36 sgallagh: Issue #2116: Moving forward with zchunk metadata for F30? - fesco - Pagure.io - https://pagure.io/fesco/issue/2116 16:12:02 proposal: option 1 16:12:06 +1 16:12:06 do we need a vote here? if so, consider me +1 to 1. 16:12:48 We do, and I'm also +1 to option 1 16:13:58 +1 for 1, it is beta :) 16:14:20 +1 for 1 16:14:48 I'm +1 for 1 16:14:55 I see +7, so that's approved 16:15:57 #agreed Turn zchunk metadata back on (+8, 0, -0) 16:16:03 (Counted zbyszek in the ticket as well) 16:16:37 #topic #2117 Set skip_if_unavailable=false as default behavior for software management tools 16:16:37 .fesco 2117 16:16:38 sgallagh: Issue #2117: Set skip_if_unavailable=false as default behavior for software management tools - fesco - Pagure.io - https://pagure.io/fesco/issue/2117 16:17:01 proposal: fesco want's a change proposal 16:17:04 *wants 16:17:16 mhroncok: +1 (as in the ticket) 16:17:23 yeah, that would be good. +q 16:17:28 +1 even 16:17:37 +1 16:18:07 I'm pretty hesitant about changing this for F30 though. I'd probably +1 an F31 Change. 16:18:19 i would prefer F31 as well 16:18:22 but +1 to the idea 16:18:27 * mhroncok would be +1 F31, -1 F30 16:18:28 I'm -1 to this, I think it's very similar to --best - I don't think errors in system setup or on the network should keep packaging tools from doing what it can 16:19:00 otaylor: that doesn't really go against an idea of having this as a change proposal 16:19:26 otaylor: that's a good point, and i was against the --best flag... hmm 16:19:33 otaylor: it won't change main repos, only additional ones 16:19:37 or is it that they would like our opinion before they burn hours on drafting a formal change proposal? not sure 16:19:56 In my understanding, the result would be if hyou have an unreachable repo, dnf will refuse to do anything? 16:20:10 i think it is quite reasonable to expect that if someone adds a repo it should be available 16:20:14 I think this change makes good sense. Third-party repos can just ship with that setting swapped if that's how they want to proceed. 16:20:16 (what if you have rpeos that are only available on VPN ... as I suspect many of us do) 16:20:18 otaylor: unles you explcitly mark that repo as skip_if_whatnot 16:20:24 But if I install a repo, I'd default to assuming that it gets used. 16:20:28 otaylor: you set such flag in them 16:20:50 There's limited notification that you aren't reaching the server unless you're watching the output carefullt 16:20:59 this discussion should ahppen on devel amiling list when they propose the change 16:21:01 It comes back and tells you clearly that there is a problem, otherwise people may not notice that their web browser is no longer getting security updates 16:21:15 (provided they are using a browser from a 3rd party repo) 16:21:17 *happen *mailing 16:21:25 what about gnome-software? 16:21:45 sholdn't we expect that most fedora Workstation users are updating through gnome software? 16:21:57 it goes against process now, so i wonder is there a way to make sure this change appears in release notes? 16:22:22 jforbes: Yeah, that's a problem we have a LOT with the Chrome browser 16:22:45 otaylor: Honestly, not if they ever use any repos besides the official ones. 16:22:54 (Or if they use Chrome, because that's problematic too) 16:23:03 sgallagh: why is Chrome problematical? 16:23:05 sgallagh: Actually, chrome is somewhat better about this, I believe it updates itself while running, but the issues remains with other packages 16:23:29 otaylor: GNOME's fedora-workstation-repos package has in the past overridden the one from Google, disabling it. 16:23:55 I *thought* I fixed that in F29, but I hit it again when I upgraded to F30 16:24:03 (Which reminds me that I need to figure out why) 16:24:06 But you'd still get updates, right? 16:24:08 no 16:24:27 otaylor: perhaps not the target market, but I don't know of any workstation users firsthand who are using gnome software for updates 16:24:42 let's not get into specifcis hre? can we just say we want a formal change proposal for F31? 16:24:55 otaylor: It also doesn't work if you're maintaining your own addon repo, because unsigned stuff doesn't work with it 16:25:03 mhroncok: +1 16:25:10 and it will get discussed on the list as part of that 16:25:21 Anyway, I don't see any opposition to getting a proper Change Proposal, so let's just go with that, yes? 16:25:29 +1 16:25:33 mhroncok: i think we need to decide if we consider this for f30. If not - let's request a formal change 16:25:34 yup 16:26:15 they need a change proposal either way 16:26:29 -1 F30 16:26:34 if they liek tog et a change proposal for f30 now, I guess thay have that option, and I'd -1 it 16:27:02 mhroncok: so let's save some time and don't ask :) 16:27:36 so: "needs a formal Change Proposal for F31" ? 16:27:44 proposal: please submit a regular change proposal. fesco recommends targeting fedora 31 16:27:50 mhroncok: +1 16:27:55 +1 16:28:00 +1 16:28:24 mhroncok: +1 16:29:23 +1 16:29:56 mhroncok: +1 (but think any such change proposal needs to address gnome-software as well) 16:30:23 #agreed please submit a regular change proposal. fesco recommends targeting fedora 31 (+7, 0, -0) 16:30:36 #topic Next week's chair 16:30:38 otaylor: I guess you can put that as a comment...? 16:30:44 mhroncok: yes, I can 16:30:46 I will be on PTO next week, as will contyk 16:31:14 i can do it 16:31:23 bowlofeggs++ 16:31:59 I guess next week remains the same time? whenisgood will probably not be solved before that 16:32:05 bowlofeggs: Thanks 16:32:24 #action bowlofeggs will chair 2019-04-15 meeting 16:32:34 #undo 16:32:34 Removing item from minutes: ACTION by sgallagh at 16:32:24 : bowlofeggs will chair 2019-04-15 meeting 16:32:39 #action bowlofeggs will chair next meeting 16:32:44 mhroncok: it could be? 16:32:53 Good point, let's set a deadline for Wed of this week for the WhenIsGood 16:33:22 (Maybe Thursday) 16:33:37 Enough time for the results to be seen before the weekend, at any rate 16:33:41 is there an existing whenisgood, or do we need to make one? 16:33:51 bowlofeggs: zbyszek volunteered to send it out 16:33:53 zbyszek set an action to do it 16:33:54 cool 16:34:13 or that opensource one... that I always forget the name of 16:34:41 So let's say WhenIsGood results must be in by 2359 UTC on Thursday? 16:34:49 sure 16:34:51 Anyone who doesn't reply... doesn't get a say. 16:35:32 nirik: Framadate? 16:36:12 yeah, that could it it... 16:36:27 sgallagh: I guess I'm Ok with this assuming zbyszek sends this out no later than wednesday 16:36:49 mhroncok: WFM 16:37:34 #info Available time-slots must be provided to the WhenIsGood (or equiv.) by 2359 on Thursday. New meeting time will be announced Friday. 16:37:51 I'll talk to zbyszek so he doesn't miss this 16:37:56 ack 16:38:00 Thanks 16:38:07 #topic Open Floor 16:38:14 Any items for Open Floor this week? 16:40:02 I'll interpret that as "no" 16:40:08 Thanks for coming, folks 16:40:11 #endmeeting