13:03:35 #startmeeting workstation wg 13:03:35 Meeting started Mon Oct 14 13:03:35 2019 UTC. 13:03:35 This meeting is logged and archived in a public location. 13:03:35 The chair is mclasen. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:35 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:03:35 The meeting name has been set to 'workstation_wg' 13:03:57 #chair mcatanzaro 13:03:57 Current chairs: mcatanzaro mclasen 13:04:03 #chair cmurf 13:04:04 Current chairs: cmurf mcatanzaro mclasen 13:04:19 #meetingname workstation 13:04:19 The meeting name has been set to 'workstation' 13:04:25 #chair otaylor 13:04:26 Current chairs: cmurf mcatanzaro mclasen otaylor 13:04:36 .hello2 13:04:38 otaylor: otaylor 'Owen Taylor' 13:04:46 .hello chrismurphy 13:04:47 cmurf: chrismurphy 'Chris Murphy' 13:04:55 morning 13:05:00 #chair kalev 13:05:00 Current chairs: cmurf kalev mcatanzaro mclasen otaylor 13:05:40 we need one more 13:05:51 I haven't seen cschaller yet 13:06:03 langdon: around ? 13:07:27 its columbus day, so there's a chance that they are not around today... 13:08:08 No aday or ngompa either 13:08:57 aday is at the shell hackfest 13:08:59 well we have the time we might as well use it 13:09:05 yes, sure 13:09:06 the votes will be straw votes 13:09:18 * mclasen looks at tickets 13:09:39 I wonder if we should have a weekly meeting instead of every other week 13:09:55 every other week keeps it out of pattern, off schedule 13:10:08 * mclasen can't deal with non-weekly meetings at all 13:10:18 which is why I am never prepared for this 13:10:22 * kalev doesn't have a strong opinion either way. 13:10:36 it's better if they're 30 minutes instead of an hour than to have fortnightly meetings 13:11:11 I'm inclined to agree with that 13:12:41 I'm not sure how well I 13:12:59 'll do at making short 9am meetings every week, but I can try! 13:13:38 I'll never be enthusiastic about 8 AM meetings, but I'm OK with 30 minutes weekly 13:14:02 one option would be to enforce the 30 minutes and move half an hour later 13:14:21 but then we trade a biweekly schedule with an off-the-full-hour schedule 13:14:27 not sure thats better 13:14:40 At least this simplifies my alarm situation, it is annoying to either wake up needlessly once a week when I have an alarm set for Mondays, or risk forgetting the meeting 13:15:27 8:30 seems fine to me, it's not odd to start meetings on a :30 IMO 13:15:36 Er, 9:30 Eastern 13:16:17 * kalev is happy with either. 13:16:38 cmurf: want to file a ticket and bring it to a vote next time we have quorum ? 13:16:46 sure 13:16:59 thanks 13:17:34 here is a ticket that could use some discussion : https://pagure.io/fedora-workstation/issue/107 13:17:42 "reconsider updates policy" 13:18:01 yeah this is interesting 13:18:05 mclasen, use #topic :) 13:18:07 mcatanzaro: your ticket, want to pitch it ? 13:18:21 #topic reconsider updates policy, https://pagure.io/fedora-workstation/issue/107 13:19:03 Pitch: let's make updates happen at most once per week. Or even every two weeks. Something like that. 13:19:22 For released distros, of course. E.g. F30, not F31. 13:19:52 my preference would be to have updates batching on server side, so that they can be tested to be known good 13:19:53 Feels like almost every day when turning on my F30 laptop, I'm prompted to reboot to install updates... it's too much. And it's right after booting too 13:19:55 what's the trigger? does it exist yet? would it be in PK or gnome-software? 13:20:09 mcatanzaro: and you are thinking of this as a g-s thing, not a bodhi thing? 13:20:18 kalev: can you describe the current behavior ? 13:20:30 * mclasen implemented it originally, but ... too long ago 13:20:32 Sadly batching was implemented for us and then later removed from bodhi because we weren't using it, so yes I'm thinking of this as a g-s thing now, feels like we missed our chance there. 13:20:39 I thought there was supposed to be a week delay already for non-security related things 13:20:56 currently, gnome-software checks updates every day. if the pending update set includes security updates, then the user is notified immediately. otherwise, they get notified once a week has passed since last update. 13:21:12 is it that so many updates in bodhi have a security tag now? 13:21:18 cmurf: I guess either there are security-related things every day, or it "feels that way" 13:21:27 oh dear 13:21:35 improvement to the current status, in my opinion, would be to start doing updates batching on server side so that the whole batch can be tested 13:22:06 thats basically the premise of silverblue, no ? 13:22:10 yes 13:22:11 the silverblue folks have to do something like that already don't they? in order to come up with their next deployment tree every two weeks? 13:22:41 any way on the server side to coordinate this so they end up being based on the same thing, same effort? 13:22:46 cmurf: there's no two-week cadence for silverblue that was a fedora atomic host thing (probably a fedora coreos thing now) 13:22:54 ok 13:23:04 what is the silverblue cadence? 13:23:14 https://bodhi.fedoraproject.org/releases/F30 says there are 379 security updates for F30, which is roughly six months old, that's roughly two security updates per day 13:23:17 cmurf: "nightly compose, if it works - goes out" 13:23:26 i see 13:24:07 I suspect almost all of these can wait a week at least; it's not like it's common to exploit 0-days on desktop Linux, unless you're victim of a targeted attack (in which case you will lose anyway) 13:24:34 Obviously there's no point in having separate rules for security vs. non-security updates when there are security updates every day 13:24:35 kalev: we only do automatic updates for flatpaks, right ? there's no automatic security updates ? 13:24:45 right that suggests better granularity is needed for the security update 13:24:48 Can't do automatic security updates because that would require reboot.... 13:24:48 mclasen: correct, only for flatpaks 13:25:13 mcatanzaro: good point 13:25:27 We could try changing the policy to do daily updates for stuff marked *urgent* instead of *security*, and see whether packagers abuse urgent status 13:25:32 mcatanzaro: could we go off of update severities for security updates? 13:25:48 otaylor: Great minds think alike! 13:25:57 would have rebooted today for https://bodhi.fedoraproject.org/updates/FEDORA-2019-be4b40654f 13:26:09 sure, checking urgency sounds like it's worth a try 13:26:12 (but not on silverblue, eventually) 13:26:41 * cmurf likes the urgency concept 13:26:41 if we're going to try that, we should collect the data - what is the frequency of urgent security updates going stable 13:26:57 it's all available through the bodhi api 13:26:59 Related Silverblue epic: https://teams.fedoraproject.org/project/silverblue/epic/95 ("Slow down the update cadence") 13:27:01 default to urgent updates only, users can opt into daily 13:27:09 kalev: do we have severity information for updates ? 13:27:12 Looks like Silverblue wants one update every 2-3 weeks 13:28:34 * mclasen has to run for a minute 13:28:40 mclasen: the repo metadata includes severity information, but not sure if packagekit supports severity, let me take a look 13:29:15 Unfortunately bodhi doesn't show stats for severity... if there are 10 urgent updates per release cycle it should work, 300 it won't work. Dunno how many there are. 13:29:34 I can figure that out 13:29:52 Thanks 13:30:08 no, packagekit doesn't support severity if I am reading this right, would have to be fixed there first before we can change it in gnome-software 13:30:17 #action otaylor to figure out how frequently bodhi updates are marked urgent 13:32:24 By point of reference, Windows security updates are famously monthly (second Tuesday), macOS seems to be every 1-2 months... 13:32:28 * mclasen back 13:32:57 ok, more on this ticket, or should we wait for stats and move on to the next topic ? 13:33:02 https://bodhi.fedoraproject.org/updates/?releases=F30&type=security&severity=urgent gives you an idea - basically it seems like only stransky tags his security updates urgent 13:34:24 useful data 13:34:25 https://bodhi.fedoraproject.org/updates/?releases=F30&type=security&severity=high gives quite a few more 13:34:33 Nice, stats. :P So we can talk to stransky about that, I think one week is OK for Firefox 13:34:56 Looks like this will work 13:35:26 The other thing is timing of updates: getting a notification to reboot is annoying, we should only notify if some time has passed without the updates being installed from the gnome-shell power off dialog IMO 13:35:37 Presumably any exploit that people *know* is actively remotely exploitable will be marked urgent (e.g., the recent exim updates) 13:36:17 mcatanzaro: but if the update is truly urgent, such a notification is warranted, imo 13:36:24 Yes, if it is urgent 13:36:27 But not otherwise 13:37:03 Also, the shutdown dialog is currently broken: https://gitlab.gnome.org/GNOME/gnome-software/issues/791 13:37:59 it was a packagekit change that broke the shutdown dialog offering 13:38:24 * kalev commented in the ticket. 13:39:16 mcatanzaro: is that on the f31 blocker list ? 13:39:50 mclasen: nope 13:40:30 would be nice to get a freeze exception for it 13:40:36 No, it's maybe a F29 or F28 regression, old bug 13:41:29 would still be nice to get a freeze exception for it :/ 13:41:39 if there's a tested fix it might get an FE, but anything that touches otherwise working updates I think QA would be reluctant to accept 13:42:01 We can fix it post-release so it's not a big deal if it gets a FE 13:42:04 I don't think a fix would be touching otherwise working updates 13:42:13 Also I suspect if it was easy to fix, it would be fixed by now :P 13:42:36 I suspect it wasn't getting anybodys attention 13:42:39 Anyway I guess kalev to look into that? 13:42:45 mclasen: the fix would be in PackageKit? So it would touch that? 13:42:52 (kalev, volunteer yourself, you know you want to ;) ;) ;) 13:42:57 I think the fix would be in gnome-shell 13:43:02 gotcha 13:43:03 cmurf: no, it would be in gnome-shell 13:43:27 packagekit exiting on idle is good, we don't want to change that 13:43:53 so the problem, as I understand it, is that packagekit shuts down on inactivity now, and shell only checks for cached dbus properties that disappear when packagekit disappears from the bus 13:43:57 or something along those lines 13:44:09 so shell would have to spin up packagekit properly 13:44:11 sounds spot-on 13:44:30 * cmurf would like it if PK weren't spinning up every time he logs in or changes network settings 13:45:08 I'm not sure what it's refreshing, but it's 100% CPU with fans on for about a minute each time 13:45:20 it's gnome-software checking for updates, I guess 13:46:07 but that should still be time-based ? I mean, it shouldn't check for updates _just_ because I go online 13:46:28 yeah, something wonky must be going on there 13:46:29 but it should check if it is overdue and I go online 13:46:33 * kalev agrees. 13:46:38 it does seem like I get that refresh every time I turn on VPN and again when I turn it off 13:46:47 for sure when logging out and back in 13:48:10 may needs some further investigation in a g-s issue? 13:48:49 * mcatanzaro wonders if half an hour might not be enough time to discuss an issue fully 13:49:09 mcatanzaro: :P forward progress is being made 13:49:32 everything is complicated 13:50:25 mcatanzaro: 30 minutes would certainly require us to prepare better in tickets, and be more focused on voting in the meeting 13:51:01 Or vote in tickets and only use the meeting for controversies, like FESCo (not sure we need to do this though) 13:51:11 mcatanzaro: +1 13:51:15 Er hi cschalle, around? 13:51:26 i prefer that, i think the meetings should be for the discussion 13:51:27 he's out sick 13:51:48 ok. we have 9 minutes left. not sure thats enough for a controversy 13:52:16 topic -> open floor? 13:52:25 sure, good idea 13:52:29 #topic open floor 13:52:29 tis' enough for an unresolved controversy :D 13:52:48 who's the chair next weeek? 13:52:55 here is one: https://teams.fedoraproject.org/project/silverblue/us/82?kanban-status=319 13:53:25 "make a subset of flathub available in Fedora" (Silverblue, specifically) 13:54:13 I've made a pr to add a filtered flathub remote to fedora-workstation-repositories 13:54:34 fedora-council report is due, somehow catanzaro got removed as the point of contact, but when I accepted being volunteered as the new PoC I didn't know that 13:54:35 with a whitelist that currently allows exactly one application: steam 13:54:38 https://pagure.io/Fedora-Council/status_reports/c/a3e69348cc86436de156bb8935f38fafdd8d822b?branch=master 13:55:01 I quite like what mclasen did to add the same apps through flathub that we already had approved previously as ok 13:55:05 so i'll do it sometime this week, if anyone has status notes, email them to desktop@ 13:55:07 I was never actually the point of contact, they just picked me and then asked if I was willing to do it... I declined :) 13:55:17 mcatanzaro: haha 13:55:28 so my problem is I said yes 13:55:33 I merged mclasen's MR by the way, it is now the subject of some controversy on devel@ from the usual suspects 13:55:55 * mclasen had missed out on that controversy. should I look ? 13:55:56 mcatanzaro: would have been better to wait for workstation wg to approve this first 13:56:04 mclasen: Probably should look 13:56:14 now it's mclasen's head in the fire here since you merged it without workstation wg approval 13:56:22 * mcatanzaro assumed it was uncontroversial 13:56:26 I don't feel the fire if I don't look 13:56:33 :) 13:56:34 But maybe I violated the policy, does the policy require that we approve new repos? 13:56:42 yes 13:56:52 Maybe I should actually read the policy.... 13:56:55 or at least I believe so 13:57:02 Proposal: WG to thanks cmurf for volunteering to send these reports 13:57:05 you didn't violate the policy until we build and publish a package update? 13:57:22 Proposal: WG to scold mcatanzaro for potentially violating third-party repos policy :) 13:58:26 sadly, we don't have quorum, so our scolding will be non-binding 13:58:47 haha :) 13:58:48 non-binding thanks and non-binding scoldings, we're broken 13:59:27 any last topic for open floor ? one minute left 14:00:02 We need to get attendance up :/ 14:00:07 Bye 14:00:21 good point 14:00:26 #endmeeting