15:00:00 #startmeeting FESCO (2019-02-18) 15:00:01 Meeting started Mon Feb 18 15:00:00 2019 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_(2019-02-18)' 15:00:03 #meetingname fesco 15:00:03 The meeting name has been set to 'fesco' 15:00:05 #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor 15:00:05 Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek 15:00:07 #topic init process 15:00:09 .hello psabata 15:00:10 contyk: psabata 'Petr Šabata' 15:00:17 .hello2 15:00:18 jforbes: jforbes 'Justin M. Forbes' 15:00:29 .hello kevin 15:00:30 nirik: kevin 'Kevin Fenzi' 15:00:31 .hello2 15:00:33 bowlofeggs: bowlofeggs 'Randy Barlow' 15:00:48 .hello2 15:00:49 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:01:28 yay, quorum 15:01:47 i love the smell of quorum in the morning 15:01:51 .hello2 15:01:52 bcotton: bcotton 'Ben Cotton' 15:01:55 we have a lot to go through today 15:02:26 so let's get started 15:02:32 #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking 15:02:34 .fesco 1974 15:02:36 https://pagure.io/fesco/issue/1974 15:02:36 contyk: Issue #1974: Problematic blocker for F29: dnf 'offline' module tracking - fesco - Pagure.io - https://pagure.io/fesco/issue/1974 15:03:01 this one is pretty old; it wasn't fixed for f29 and likely won't be fixed for f30 either 15:03:23 I know the DNF team has it on their agenda but probably won't be done in time for f30 15:03:42 .hello2 15:03:49 otaylor: otaylor 'Owen Taylor' 15:03:52 Is anyone here speaking for the DNF team? 15:04:07 let me ping them 15:04:47 well, really the only things we can do are slip the release or just accept it's not going to be fixed for f30. ;( 15:05:35 or we could sit on someone's desk until they fix it :-) 15:05:49 fesco sit in! 15:05:50 (not speaking metaphorically this time) 15:05:54 The last update we actually saw from the DNF team said they thought end of January was still a realistic timeframe. Is the code written? 15:06:00 Well, it's not the kind of bug that could not be fixed by a few determined individuals in the next 3 months... 15:06:03 there he is 15:06:23 Hi 15:06:33 jmracek: we're discussing ${topic}; it's the modulemd storage / failsafe mechanism and planning for f30 15:06:48 welcome jmracek. Thanks for coming. 15:06:50 jmracek: as I understand it, this wouldn't be ready in time for f30 but we'd like your input here 15:08:15 or if we need to gather more info we can revisit it / ask for updates in bug? 15:08:30 I don't think we can make it for Fedora 30. Of course if any contribution arrives from community, I will be happy to merge it. 15:08:57 .hello2 15:08:58 ttomecek: ttomecek 'Tomas Tomecek' 15:09:13 so we prepared a technical proposal how to deal with this problem and discussed it with jmracek's team in December; they agreed to start looking at it in January but that date was moved because of other fires 15:09:40 then January was full of conferences and other events 15:10:10 yeah, and december holidays... 15:10:22 Is there another date? Personally, I don't mind treating this like we did with F29, but I also would rather not be having this same conversation again for F31 15:11:01 jmracek: when do you think we could meet and discuss the failsafe mechanism proposal? would sometime this month sound realistic to you? 15:12:36 contyk: We already have a planning meeting on Wednesday, and we can discussed it personally. 15:13:03 I think that's a yes then 15:13:13 Yes 15:13:40 if you all could discuss wed and update the bug / our ticket that would be great 15:13:41 so I'd be okay with deferring this to f31 as long as we sketch a specific plan before the end of the month 15:14:00 agree with jforbes 15:14:03 and contyk 15:15:04 proposed #agreed As we're fairly sure this wouldn't be fixed in time for F30, we're moving this to F31. Modularity & DNF folks with prepare a specific implementation plan and will update the ticket. 15:15:29 +1 15:15:46 * nirik would kind of like to see the plan first, but ok 15:16:24 contyk: +1 15:16:35 nirik: agreed 15:16:35 I think it's mostly about scheduling and prioritization rather than open technical questions 15:17:40 there's also another DNF bug related to system upgrades that, if I had to choose, I'd like to see fixed instead 15:18:48 otaylor: ? 15:19:22 contyk: you are asking about the discussion we had on fedora-modularity on friday? 15:19:31 contyk: or, are you prompting me for a vote on the proposal? 15:19:44 otaylor: I'm prompting you to vote on the proposal 15:19:48 oh, sorry 15:19:57 +1 15:20:06 I now realize how little time is left. So postponing is inevitable. So I'm full +1 for the proposal. 15:20:34 #agreed As we're fairly sure this wouldn't be fixed in time for F30, we're moving this to F31. Modularity & DNF folks with prepare a specific implementation plan and will update the ticket (+6, 0, -1) 15:20:35 (I don't think trying to rush some untested code in last minute is going to improve the user experience for f30) 15:20:44 agreed 15:20:50 okay, next one 15:20:56 #topic #2003 Ursa Major (modules in buildroot) enablement 15:20:58 .fesco 2003 15:21:00 https://pagure.io/fesco/issue/2003 15:21:00 contyk: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003 15:21:03 it's our favorite 15:21:31 so we kinda sorta have a plan how to put modules in the non-modular buildroot without Ursa Major 15:21:33 so i heard some rumours that this wasn't necessary with a new plan. any updates on that/ 15:22:06 we talked about this in person at DevConf and I promised to prepare a writeup people would ack before we move forward; I'm super late here 15:22:17 I'll have it ready today or tomorrow 15:22:47 either way, it requires changes to both MBS and Koji, which means it will not be ready for f30 15:23:03 so I guess the question here is -- what do we do about those java packages? 15:23:05 are we in ok shape for EPEL at least? 15:23:28 bowlofeggs: EPEL requires the very same changes 15:23:29 nothing stops volunteers from unretiring/unorphaning them, right? 15:23:43 right 15:23:47 other than lack of volunteers ☺ 15:23:52 for epel8beta we are going to first do a non modular thing, then modules when the above is ready. 15:24:19 yeah, but we need modules to build the non-modular thing, most likely 15:24:45 i don't have any ideas for what we can do about the java packages. sounds like they need someone motivated to do the work 15:25:06 I was thinking we could just... not retire them 15:25:19 some of them were picked up I thought... 15:25:24 well they'd need someone to at least adopt them, right? 15:25:36 yeah some were picked up 15:25:36 to make it easier on people; of course that means they would be unmaintained but it would be easier for volunteers and provenpackagers to fix them if needed 15:25:39 i assume not all though 15:25:52 contyk: agreed. I think we can add an exemption to the usual orphaining process. 15:26:03 we could assign them all to contyk ☺ 15:26:16 I was going to suggest nirik 15:26:19 ahahah 15:26:38 ha. No thanks. 15:26:52 i think 've had the misfortune of adopting too many packages in my past to accept any more myself 15:27:05 i got almost all of luke's packages when he left 15:27:09 I think the important ones to other folks will get picked up... 15:27:29 * contyk remembers the time when he had the most packages in Fedora 15:28:00 it would be nice if this hadn't happened until we had ursa major replacement in place... but such is life. 15:28:19 there is that group that wants to form around this 15:28:24 perhaps they would like to adopt these 15:28:33 (on devel list) 15:28:52 so how about we say they're an exception and won't be retired for f31/rawhide? 15:29:08 I don't know that I like excepting them... 15:29:08 these group can still take them but the rest will not disappear, it will just be orphaned 15:29:11 i think i would prefer to follow the policy 15:29:27 if we change the unretirement process, they could be unretired longer 15:29:28 if they are important, they should be looked after 15:29:39 if nobody wants to look after them, they must not be that important 15:29:43 that's my logic anyway 15:29:45 I'm worried hundreds of necessary packages will suddenly disappear and people will have to go through the review process to get them back 15:30:01 it's just people not noticing until it's too late 15:30:03 well, already you have 2 weeks... 15:30:04 i would +1 making that part easier 15:30:10 but there's a proposal to make it longer 15:30:47 Yup, just no agreed upon definition of "longer" 15:30:53 The reason is why we could except them is that we "know" that they are maintained in the modules, so maintainership could be mostly a matter of copying the changes. 15:31:11 So if there's some "grave" bug, chances are somebody will volunteer a fix. 15:31:33 +1 15:31:41 I'm really missing somethig obvious here - we don't have per-branch ownership, so how is 'maintained in the modules' different from maintained in dist-git? 15:31:44 but if no one is doing that... how does it matter? 15:31:52 if it were really that easy, wouldn't the original maintainer just keep doing it though? 15:32:07 i would think it must still not be that easy. sounds at least tedious to me 15:32:26 and yeah, nobody is doing it if it is orphaned 15:32:38 we have a process for this, i think we should stick to it 15:33:21 so your proposal is "do nothing and let people who need them handle it"? 15:33:46 haha, well i would phrase it as "let our usual processes handle this - this is what they are designed for" 15:33:48 but yes 15:34:18 i don't think we need to do anything out of the ordinary here 15:35:07 +1 15:35:30 OK, but can we revisit this question *before* all the java packages are orphaned in 5 weeks? 15:35:30 I'm now curious if these are going completely away then; as noted above, if they were in modules, they wouldn't be orphaned 15:35:33 but we should be ready to do a bunch of unretirements when/if people find they need something after all 15:35:53 just retired from master 15:36:01 or maybe I'm misunderstanding the situation 15:36:23 they are going away as buildrequires mostly 15:36:55 but I guess also from end users as the modules only use those to build things 15:37:09 or are they publishing those too? 15:37:19 okay, but that means the module maintainer should still own them 15:37:28 I think we discussed that a couple of meetings ago 15:37:39 nirik: we're also destroying the experience of Fedora as developer workstation 15:37:49 zbyszek: i wouldn't mind talking about it again before they are retired 15:38:45 should we discuss this next week then? 15:38:49 zbyszek: sure, but it's hard to force people to maintain things they don't want to maintain 15:38:50 zbyszek: I *think* most Java developers use maven, and not packaged depenendencies, but yes, it's an important general consideration 15:39:26 otaylor: in my experience, not everything is available in maven, for example in the scientific world. 15:39:48 is this an appropriate time to make java jokes? 15:40:01 It was very nice to be able to specify the environment using 'dnf install'. 15:40:05 .hello till 15:40:07 tyll_: till 'Till Maas' 15:40:25 zbyszek: except that on non-rawhide, java packages are outdated ;) 15:40:49 well, maven and ant are available to end users as modules, just other stuff is not I guess. 15:40:52 zbyszek: that should still be available with modular java, just takes more specialized knowledge then 'dnf install ' 15:41:21 not all of it would, if I understand it correctly 15:41:41 zbyszek: Fedora toolbox could potentially be a thing that knows how to set up a cojntianer with the right modules 15:42:10 otaylor: but that seems like a gigantic step backwards 15:42:36 I mean, I know that this is just software, so everything is always "possible", but meh. 15:42:53 zbyszek: Not necessarily - gives more power as well .... like being able to use the Java packages from rawhide without upgrading your system to rawhide 15:43:19 zbyszek: but it's only a step forward if we put real effort into making it nice, and not just wave our hands around :-) 15:43:30 :) 15:43:40 Yeah, 15:43:49 i keep feeling bad because i haven't really done much with modularity, so it's still very abstract to me 15:44:12 like i get the high level picture (well, i think i do?), but the details are very hazy to me 15:44:24 it's magical 15:44:49 Anyway, IIUC, contyk will prepare an alternate proposal within a few days. 15:44:56 Should we just wwait for that and revisit? 15:45:13 I think so 15:45:18 yeah, but the implementation will likely take time 15:45:24 bowlofeggs: to me it seems not very ready in many areas 15:45:43 I'd wanted to know what happens if it's not ready for f30 in this particular case 15:45:59 and zbyszek also has a point; that will be valid no matter what 15:46:30 but that's up to the maintainers, I'd say 15:46:54 tyll: sometimes i feel that way too, though i also don't know if i'm qualified to say that since i know so little about it 15:47:17 FESCo: where we get to make decisions on things we often aren't qualified to decide on 15:47:28 proposed #agreed contyk will prepare & share a proposal solving the buildroot problem without Ursa Major. We will revisit next week. 15:47:32 see probably also: any governing body 15:47:42 contyk: +1 15:47:43 contyk: +1 15:47:48 contyk: +1 15:47:48 contyk: +1 15:47:58 contyk: +1 15:48:09 +1 15:48:25 #agreed contyk will prepare & share a proposal solving the buildroot problem without Ursa Major. We will revisit next week. (+7, 0, -1) 15:48:34 okay 15:48:37 No -1? 15:48:40 bowlofeggs: This is why we can ask questions about technical details to get clarity 15:48:46 oh 15:48:48 #undo 15:48:48 Removing item from minutes: AGREED by contyk at 15:48:25 : contyk will prepare & share a proposal solving the buildroot problem without Ursa Major. We will revisit next week. (+7, 0, -1) 15:48:53 #agreed contyk will prepare & share a proposal solving the buildroot problem without Ursa Major. We will revisit next week. (+7, 0, -0) 15:48:55 tyll: indeed ☺ 15:49:07 #opitc #2078 F30 Change: MongoDB removal 15:49:10 .fesco 2078 15:49:12 https://pagure.io/fesco/issue/2078 15:49:12 contyk: Issue #2078: F30 Change: MongoDB removal - fesco - Pagure.io - https://pagure.io/fesco/issue/2078 15:49:38 +1 (sorry I didn;'t vote in ticket) 15:50:00 i'm +1 in ticket 15:50:04 and i'm +1 in irc 15:50:08 and i'm +1 irl 15:50:08 tyll -- you think this needs more discussion? 15:50:33 * zbyszek voted +1 15:50:35 i'll be surprised if there doesn't end up being a fork of mongodb that sticks to the old license 15:50:39 contyk: no, I just want to make sure that everyone who voted before the discussion still agrees after the discussion 15:51:44 not sure how to count it then 15:52:49 tyll: would you like to give it another week so that everyone has a chance to see the new comments? 15:53:10 contyk: we can decide this with the people here IMHO 15:53:10 Well, we have quorom. We can vote again if people have doubts. 15:53:33 not sure if there is anyone who did not agree after this discussion 15:53:42 the discussion 15:53:46 true; I'll discard the votes in the ticket and let's vote here 15:54:10 Nobody objected in the ticket... 15:55:08 also it is now 7 days after the list of pkgs was amende 15:55:10 amended 15:55:18 IMHO we are good to approve it now 15:55:24 * nirik nods 15:56:01 +1 for me too on that 15:56:09 +1 ftr 15:56:10 * contyk is still confused who to count as +1 and who could potentially change their mind, though, according to tyll's comment 15:56:23 so please 15:56:36 porposed #agreed F30 Change: MongoDB removal is approved. 15:56:40 I think count all the +1s in ticket and the +1s here? or we could just all vote in ticket and you can use that when you finish? 15:56:50 whatever works. +1 here. 15:56:53 contyk: +1 15:56:59 contyk: +1 15:58:13 jforbes, bowlofeggs, otaylor: ftr ^ ? 15:58:26 +1 15:58:33 contyk: as said above, i'm +1 in ticket, irc, and irl ☺ 15:59:17 #agreed F30 Change: MongoDB removal is approved. (+6, 0, -0) 15:59:27 #topic #2046 Change process: Releng impact tickets are tedious and possibly contribute to 15:59:30 overwhelm releng 15:59:32 .fesco 2046 15:59:34 https://pagure.io/fesco/issue/2046 15:59:34 contyk: Issue #2046: Change process: Releng impact tickets are tedious and possibly contribute to overwhelm releng - fesco - Pagure.io - https://pagure.io/fesco/issue/2046 16:00:31 So we're at +4 for nirik's proposal 16:00:52 +1 here 16:00:58 IMHO it is most important to know if mboddu wants a new ticket for every change or not. If not I am fine with the new proposal. 16:01:55 +1 for nirik's proposal 16:01:59 I'd take the fact that mboddu did not reply in the ticket at all as a strong sign that less tickets for him to process would be a good idea. 16:02:24 tyll: when i talked to mboddu at DevConf, he was in favor of reducing the number of tickets he has to ack 16:02:36 bcotton: ok, thx for the info 16:02:37 zbyszek: haha +1 16:02:38 +1 then 16:03:19 still with my +1 from ticket (for Mongo as well) 16:03:31 i +1'd in ticket 16:03:47 tyll: I prefer filing the tickets for system-wide changes but not for self contained changes, for self contained changes adding a line like "up to change requestor to create a ticket against releng if they think work is needed from releng" 16:03:59 so that's +8 16:04:36 #agreed System wide changes remain the same for now. For self contained changes if the proposal owner(s) think releng involvement is needed, they open a ticket, but it is not mandatory, Anyone who feels releng should be notified of and discuss the change can file a releng ticket anytime. (+8, 0, -0) 16:04:49 #topic #2067 tss2 package ownership 16:04:52 .fesco 2067 16:04:54 https://pagure.io/fesco/issue/2067 16:04:54 contyk: Issue #2067: tss2 package ownership - fesco - Pagure.io - https://pagure.io/fesco/issue/2067 16:04:56 contyk: +1 16:05:51 * nirik isn't sure what needs to be done here. 16:05:51 +1 to assigning to snits 16:06:08 shouldn't we do the usual process here? 16:06:11 sure, +1 to reassigning if we know they aren't there. 16:06:14 nonresponsive maintainer? 16:06:24 at least the part of mailing devel 16:06:29 since th address bounces 16:06:29 there's a quick path for if we know their email is invalid 16:06:32 * nirik looks it up 16:06:33 ah 16:06:51 https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers?rd=PackageMaintainers/Policy/NonResponsiveMaintainers#Notes_for_invalid_email_addresses 16:07:06 it's the same thing we do when people leave red hat and their address becomes invalid. 16:07:19 yeah devel list 16:07:23 so we still need to write devel list 16:07:26 I'd prefer to assign snits as a comaintainer now, and do the full switch after we have had the email to devel-list 16:07:55 zbyszek: +1 adding a co-maintainer should be fine. 16:08:02 who is going to do the devel list post? 16:08:15 I'll do it. 16:08:29 yeah +1 to comaintainer 16:09:06 +1 comaintainer as well 16:10:31 .fasinfo honclo 16:10:32 zbyszek: User: honclo, Name: None, email: lo1@us.ibm.com, Creation: 2016-03-21, IRC Nick: None, Timezone: None, Locale: None, GPG key ID: None, Status: active 16:10:36 zbyszek: Unapproved Groups: gitabout-fedora security-team rpm-software-management 16:10:39 zbyszek: Approved Groups: packager fedorabugs cla_ibm cla_done cla_fpca 16:11:00 +5 so far 16:11:01 want me to add them ? or someone else wants to? 16:11:01 For heaven's sake, can somebody give me the name of honclo? 16:11:26 they set 'private' on their fas account, so it won't share that info... 16:12:03 The ticket says it is Vicky, does it not? 16:12:11 Yeah, but Vicky who? 16:13:32 perhaps we should ask for clarification in the ticket... it's a bit confusing to me from a quick read 16:13:34 bowlofeggs, zbyszek, otaylor, tibbs: +1 to adding the comaintainer? 16:13:36 Hon Ching(Vicky) Lo 16:13:49 contyk: +1 16:13:53 contyk: I think I proposed that, so I'm +1 automatically 16:14:00 according to https://fedorapeople.org/~honclo/tss2.spec 16:14:11 Thanks tyll. 16:14:33 zbyszek: well, it's proposed in the ticket... okay 16:14:56 +1 16:15:49 #agreed Agreed to add snits as a comaintainer for tss2 (+7, 0, -0) 16:16:03 #topic #2071 F30 Change: Firefox Wayland By Default On Gnome 16:16:06 .fesco 2071 16:16:08 https://pagure.io/fesco/issue/2071 16:16:08 contyk: Issue #2071: F30 Change: Firefox Wayland By Default On Gnome - fesco - Pagure.io - https://pagure.io/fesco/issue/2071 16:16:41 * zbyszek was +1 in the ticket 16:16:43 +6 in the ticket, +1 more from me 16:16:45 * nirik was +1 in ticket. 16:16:47 i was +1 in ticket 16:17:19 So, I upgraded to the upstream nightly, and unfortunately many (most?) of the bugs that are present in the F29 version are still present there. 16:17:51 hmm 16:17:54 But at least upstream is aware of the bugs 16:17:58 I haven't been hitting too much... there's some odd focus issues, but otherwise it seems to work ok here. 16:18:04 zbyszek: would you characterize it as significant? 16:19:15 bowlofeggs: many menus appear trimmed to a quadrant, so you see 25% of area. Unless you know the keyboard shortcuts, many things are impossible. 16:19:27 So yeah, I'd characterize them as significant. 16:19:28 that's pretty bad 16:19:30 that does sound ungoog 16:19:32 *ungood 16:19:43 A new nightly came out today, but I haven't downloaded it yet. 16:19:47 that makes me hesitate 16:19:57 i think i might be -1 16:20:09 FF is the default browser in the workstation edition 16:20:10 Well, I think we should try it, rollback in this case is very easy. 16:20:24 that's true 16:20:34 weird. I do not seethat here 16:21:05 * tibbs reads scrollback.... 16:21:07 zbyszek: does it still happen for you with a new profile? 16:21:10 nirik: Do you have a hidpy main screen? 16:21:14 tibbs: apologies, I meant to tag tyll :| 16:21:15 yes 16:21:32 dimensions: 3840x2160 pixels (1016x572 millimeters) 16:21:48 contyk: where? 16:21:58 I'm always +1 for comaintainers, but I don't know why anyone would ask me. 16:22:10 tyll: the previous vote 16:22:14 tibbs: :) 16:22:45 i guess i'll stay +1 due to the ease of rollback and due to nirik not experiencing it 16:22:48 contyk: ah, ok, I'm +1, too ;-) 16:22:52 we can let QA see what they think ☺\ 16:23:30 otaylor: ? 16:23:46 nirik: just tested, at least the weird menu positioning and visual glicthes are there 16:23:55 huh, odd. 16:24:10 I don't get the menu effect right now, but it's racy... 16:24:36 contyk: I'm hestitant to vote, since I havne't been able to try it out myeslf, and form an informed opinion, but +1 since my default is to trust stransky's opinion 16:25:16 * contyk nods 16:25:17 I don't think visual glitches are going to be hard to fix, if we get on top of reproducing them, and get stransky and if necessary the mutter/gnome-shell people involved 16:25:19 I'm also assuming users can choose back to x11 if they like 16:25:36 FYI, I'm running FF-on-wayland and it seems to be working fine 16:25:38 and we can always revert it if it's not fixed before final 16:25:44 there are sometimes positioning issues, but most of the time it is good 16:25:44 that's less of a concern to me compared to some major missing feature 16:25:59 right now there's a firefox and a firefox wayland, if they switch this to firefox and firefox x11 it would be ideal. 16:26:53 #agreed F30 Change: Firefox Wayland By Default On Gnome is approved but might get reverted if the glitches are not fixed in time for F30 final (+8, 0, -0) 16:27:01 note that on silverblue, it's harder to switch at the moment, since firefox is baked in, but silverblue users are more tolerant of stuff being a little rough :-) 16:27:21 four more 16:27:30 #topic #2072 Unable to implement FESCO policy decision! ( https://pagure.io/fesco/issue/1935) 16:27:32 .fesco 2072 16:27:34 https://pagure.io/fesco/issue/2072 16:27:35 contyk: Issue #2072: Unable to implement FESCO policy decision! ( https://pagure.io/fesco/issue/1935) - fesco - Pagure.io - https://pagure.io/fesco/issue/2072 16:28:07 we talked about this at the last releng meeting. 16:29:06 https://meetbot-raw.fedoraproject.org/teams/releng/releng.2019-02-14-17.00.log.html 16:29:29 we had questions about the timing... 16:29:44 mboddu was going to file a ticket. 16:30:10 * mboddu did file a ticket and searching 16:30:17 * nirik can't find it now. ;) 16:30:25 https://pagure.io/fesco/issue/2090 16:30:30 https://pagure.io/fesco/issue/2090 16:30:34 Thanks tyll :) 16:31:30 so, 8 weeks seems an odd number... and doing it such that we have to retire things in both branched and rawhide seems like more work 16:32:12 IMHO the retirement should happen before branching and if we make it possible to unretire pkgs for longer than two weeks IMHO 4-6 weeks announcements should be enough IMHO 16:32:40 (also we didn't get to this process yet, so... what to do about f30?) 16:32:48 So, in that case, we have start processing them before mass rebuild and retire them before branchign 16:33:48 yeah. 16:34:23 nirik: wouldn't this be automated to address the more work bit? 16:34:25 should we close 2072 and discuss in 2090? 16:34:48 i do feel like retiring long after branching is not good for other reasons though 16:34:55 bowlofeggs: sure, but it means we have to handle 2 branches, more looking at bugs (we can't just look at rawhide, we have to look at the branched bugs, etc) 16:35:09 true 16:35:27 it also defeats part of the point of branching, imo, which is stabilizing 16:35:36 IMHO I would like to retire with enough time before branching that people could see that they need something and bring it back and fix it. 16:35:47 if our policy changes the branch then it destabilizes it during a period we are trying to stabilize it 16:35:50 nirik: +1 16:35:51 nirik: that seems wise 16:36:00 nirik: +1 16:36:25 nirik: +1 16:36:28 I have a feeling this is going to be a painfull process... 16:36:29 OK, so is everybody on board with 4 weeks of delay starting 5 weeks before branching? 16:36:50 it sounds reasonable 16:37:10 sounds good. 16:37:15 So, how about, after N-2 retirement, we will run the process and start sending notices for 4 and then retire them, that gives at least a month to 2 months of time before branching 16:37:23 and perhaps we should do some 'test' runs on rawhide after branching this cycle. 16:37:30 zbyszek: how about 6 weeks before branching to avoid putting too much stuff in just the one week before branching 16:37:39 tyll: works for me too 16:37:46 tyll: fine with that as well. 16:37:46 zbyszek: +1 16:37:49 I think we approved the overall idea, I would be happy to say let releng and huzaifas work out the specific timeline 16:37:51 I like mboddu's idea too. 16:37:51 tyll: also +1 16:38:01 jforbes: Also +1 16:38:08 +1 16:38:14 mboddu: except that sometimes N-2 can slip and N comes sooner 16:38:15 +1's all around! :) 16:38:26 better to schedule it relative to N than to N-2, IMO 16:38:27 +1 to +1s 16:38:49 Well, N-2 retirement is dependent of N release, its always retired 4 weeks after N release 16:38:57 bowlofeggs: agreed. from an schedule implementation perspective, it's always easier to tie tasks to milestones in N 16:38:57 jforbes: do you want them to figure it out in 2090? 16:39:15 [ Would think that *coordinated* automation of package retirement for security, orphaned dependences, FTBS, etc, woudl be great - separate nag mails, scripts for releng to run, etc. makes it hard on anybody ] 16:39:17 I'd just closed 2072 pointing to the 2090 discussion 16:39:39 otaylor: yeah, thats true too. 16:39:51 contyk: that works 16:39:57 and there's a lot of overlap in those scripts I would imagine 16:40:06 proposal: jforbes' idea about letting releng and huzaifas come up with a proposal in #2090 and revisit 16:40:11 bowlofeggs: So, indirectly its related to N, but I see your point with schedule, so, lets says 6 weeks after N release start the process and intimate people for 4 weeks and 5th is the retirement, which gives between a month to 2 before branching 16:40:37 mboddu: +1 16:40:40 bowlofeggs: +1 16:40:50 mboddu: right, but i'm saying it should be related to the schedule of the next release, not to the schedule of the last release 16:40:52 and also at that time people are done with N and can focus on fixing things. 16:41:03 i.e., it should be framed as x weeks *before* branching 16:41:11 not x weeks *after* the previous release 16:41:28 otherwise you end up with oddities if schedules change between releases (and they do) 16:41:30 Sure 16:41:42 19 minutes, three more topics to go 16:41:45 so 8 weeks before branching, 4 weeks of nags, ? 16:41:51 nirik: sure 16:41:55 +1 to bowlofeggs proposal 16:41:59 but yeah, we can come up with something and update the ticket 16:42:03 I will keep it to N release 16:42:16 bowlofeggs: +1 16:42:16 Let's vote in the ticket. 16:42:27 just to reiterate, my proposal was not to hash this out in the meeting here 16:42:28 sure, sounds good. 16:42:48 yeah let's let the specifics be hammered out in ticket and move on 16:43:13 I don't think this needs a formal vote 16:43:20 No. 16:43:22 I don't see anyone really objecting, so just an info 16:43:30 agreed 16:43:49 #info huzaifas and releng will discuss the solution in #2090; FESCo will revisit next week 16:43:51 I will update the ticket with my proposal and we can talk there 16:44:08 #topic #2077 F30 Change: SWID tag enablement 16:44:10 thanks mboddu 16:44:11 .fesco 2077 16:44:12 contyk: Issue #2077: F30 Change: SWID tag enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2077 16:44:13 https://pagure.io/fesco/issue/2077 16:44:37 +1, sounds fine 16:45:10 +1 from me as well 16:45:17 +1 16:45:33 +1 16:46:13 +1 16:46:17 +1 16:46:24 bowlofeggs: ^ ? 16:47:01 +1 16:47:21 #agreed F30 Change: SWID tag enablement approved (+9, 0, -0) 16:47:22 I support ignatenkobrain's idea of doing this upstream, but upstream doesn't seem inclined to ansewr 16:47:37 #topic #2088 Late F30 Change – “dnf --best” as default behavior 16:47:39 .fesco 2088 16:47:41 https://pagure.io/fesco/issue/2088 16:47:41 contyk: Issue #2088: Late F30 Change – “dnf --best” as default behavior - fesco - Pagure.io - https://pagure.io/fesco/issue/2088 16:47:57 zbyszek: I think everyone is busy 😞 16:48:42 I think it's going to be confusing to have --skip-broken and --nobest 16:49:07 nirik: agreed 16:49:31 Are people comfortable, that, to the best of current knowledge, this is only going to apply to dnf from the commadn line and not to GNOME Software? 16:49:39 but we can try and communicate that as best we can... definitely release notes, but also some blogs and other such things. 16:49:49 https://pagure.io/fesco/issue/2088#comment-553962 16:49:50 nirik: also weird that one has a - and the other does not ☺ 16:49:51 * nirik is +1 16:50:13 can we have it disabled for rawhide at least? 16:50:37 otaylor: i kind of assume they work differently today in various ways anyway, though tbh i don't really know 16:51:02 otaylor: is that true? I would expect GNOME Software to just use whatever libdnf tells it to use (via pkgkit) 16:51:02 will this result in hiding real errors from users? 16:51:18 ignatenkobrain: I'd also like to see this disabled in Rawhide 16:51:21 bowlofeggs: --nobest will allow installation of older package in order to satisfy dependencies, --skip-broken will just skip installation of anything like that 16:51:43 I'd also drop the --nobest shorthand and just rely on --setopts if you need it 16:51:54 for me, this is huge drawback even in stable release 16:51:55 contyk: PackageKit is an independent user of libdnf - it doesn't call dnf on the command line (as I understand, there's also some weirdness with libdnf with two API's - a C one and C++ one) 16:52:02 it is like getting back to old yum times 16:52:26 bowlofeggs: the current setup does that. ;) 16:52:30 so --best will highlight dependency problems more than dnf does today? 16:52:38 Kinda feels that it is soon will be time to drop libsolv usage from dnf because it is mostly not used for its features 16:52:41 nirik: ah ok, so backwards of whati though 16:52:43 t 16:53:10 bowlofeggs: right now what you see on rawhide is: - nothing provides python3.7dist(botocore) = 1.12.91 needed by awscli-1.16.101-1.fc30.noarch 16:53:27 after change, it will just show this error message and won't allow you to do an update, until you pass --skip-broken 16:53:34 --best makes it try only the newest and fail if it can't do that, by default it just hides those/drops them if it can't 16:53:57 ignatenkobrain: I possibly broke that yesterday, but I didn't think I did... 16:54:10 ignatenkobrain: yeah i see those all the time 16:54:12 haha 16:54:23 ok, so it just turns that into a non-zero exit code and a halt? 16:54:46 rawhide gating will save us all! :) 16:54:53 this is framed as being better for user security - is that just because it forces the user to see the error? 16:55:08 nirik: bowlofeggs now imagine that you have your custom package which depends on puppet < 5, and you have custom repo which has puppet-4-xyz.rpm... previously, libsolv would just select that rpm from non-fedora repo and user will be able to install his app 16:55:10 bowlofeggs: I'm don't think it's being framed as better for *desktop* user security 16:55:25 after change, he would have to use --setopt=best=0 in order to install his RPM 16:55:39 from my POV, this is one of few things people love DNF for 16:56:04 bowlofeggs: I don't think the self-maintained workstation was really considered here 16:56:04 otaylor: fair 16:56:14 yeah, it sounds like it's just the CLI 16:56:46 i'm not sure the security argument is hugely compelling to me 16:56:47 bowlofeggs: Even from the CLI, it's not clear the new experience is better if you want to "update your system" 16:56:55 yeah 16:57:04 so right now, I have readline broken here... if I just run dnf it shows that it's skipping that... 16:57:10 that's the point, I think 16:57:16 if I run --best it shows the error and exits 16:57:19 the current configuration silently hides updates from you 16:57:27 nirik: but it still updates other packages, right? 16:57:28 i think you would want to uypdate what you can, for security, right? 16:57:31 well, it's not silent tho. 16:57:39 does dnf report problem pkgs with "--nobest"? 16:57:42 (those which do not depend on libreadline.so.7) 16:57:43 Skipping packages with conflicts: 16:57:43 (add '--best --allowerasing' to command line to force their upgrade): 16:57:43 readline x86_64 7.0-13.fc30 rawhide 182 k 16:57:43 readline x86_64 8.0-2.fc30 koji 191 k 16:57:50 like it seems bad that it is refusing to update pacakges that it could just because of a few it can't, from a security angle 16:57:57 bowlofeggs: +1 16:57:59 what if one of the ones it could is an important security update? 16:58:25 nirik: it is silent to scripts 16:58:33 contyk: that's true 16:58:34 true 16:58:50 bowlofeggs: I don't think there is right answer, but I showed example with custom repo which has older version of package and dnf would be able to resolve dependencies properly (even by installing older package). 16:58:51 so for automated "users" this is an improveent, but for human (CLI) users, it's not, imo 16:58:54 which is really good UX 16:59:00 is dnf-automatic changing behavior too? 16:59:02 and now we disallow this 16:59:27 i would think someone doing automated updates could also automate configuring dnf to do the --best too though, if they wanted that 16:59:49 so i guess the question comes down to: which type of user do we want the defaults to benefit the most? 17:00:21 nirik: I guess so 17:00:24 And how much we value consistency with RHEL 17:00:30 someone doing updates should be using dnf-automatic I would think. 17:00:31 we don't default to doing automated updates, so doing this setting for the benefit of a thing we dont' do by default doesn't seem compelling to me 17:00:35 otaylor: +1 17:00:40 otaylor: yeah. 17:01:05 we're out of time, btw 17:01:25 I'd propose we discuss thsi in the ticket for another week 17:01:29 contyk: +1 17:01:32 does it make sense to defer this until Rawhide gating? Then at lesat for Fedora-only repos it would not be a problem, would it? 17:01:33 +1 17:01:43 contyk: +1 17:01:43 contyk: +1 17:01:45 tyll: yeah we should be able to stop broken repos from happening 17:01:48 contyk: +1 17:01:58 yep. if we can't do that, the gating is not working right. 17:02:05 tyll: but as igor said, there are 3rd party repos too ☺ 17:02:34 i don't think we need a formal vote on whether to talk in ticket for a week 17:02:34 #info There are too many things to consider. We will discuss this in the ticket for another week. 17:02:41 we don't 17:02:45 bowlofeggs: yes, I am not sure if "--best" is the best behavior in the 3rd party repo case 17:02:53 there's one more topic; should we go over? 17:03:04 tyll: yeah i'm leaning -1 but want to talk more first :) 17:03:06 technically we already are 17:03:11 I can continue 17:03:12 contyk: i would say no 17:03:17 but i can continue 17:03:21 i just think it's good to time box 17:03:22 ;) 17:03:24 we're already at 2 hours 17:03:30 it might be short 17:03:35 #topic #2084 "Fedora packaging service" kickoff 17:03:38 .fesco 2084 17:03:40 https://pagure.io/fesco/issue/2084 17:03:40 contyk: Issue #2084: "Fedora packaging service" & packit ask - fesco - Pagure.io - https://pagure.io/fesco/issue/2084 17:03:50 o/ 17:04:25 okay, this wouldn't be quick 17:04:38 yes, let's reschedule? 17:04:44 yeah 17:04:46 so, should this move to the list for wider input? 17:04:47 zbyszek: i'm not hugely invested in having this be a service, just thought it was worth mentioning the-new-hotness plans 17:04:59 haha yeah this one is a complex topic 17:05:29 ttomecek: would you post to devel if you haven't already? 17:05:35 I will 17:05:46 * contyk nods 17:05:54 thanks 17:06:07 I need to figure out some things too... I tried rebase-helper today, to do a trivial systemd update, and after 2h of 100% I had to kill it 17:06:09 #info ttomecek will share this on devel@, FESCo will continue discussing in the ticket and will revisit in a week 17:06:15 alright! 17:06:16 I think it sounds pretty cool... automation is good. 17:06:19 cool 17:06:22 #topic Next week's chair 17:06:34 I can 17:06:48 that was quick, thank you 17:06:57 #action zbyszek will chair next meeting 17:07:01 #topic Open Floor 17:07:13 zbyszek, yes, that's why I tried to point out there are multiple workflows we intend to cover, I also really like last Igor's comment 17:07:24 * contyk will give it a minute 17:07:42 * ttomecek is not trying to open any discussion :D 17:08:09 haha 17:08:11 ;) 17:08:15 ok, let's close this 17:08:16 man this was a long one 17:08:18 #endmeeting