13:03:35 <mclasen> #startmeeting workstation wg 13:03:35 <zodbot> Meeting started Mon Oct 14 13:03:35 2019 UTC. 13:03:35 <zodbot> This meeting is logged and archived in a public location. 13:03:35 <zodbot> The chair is mclasen. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:03:35 <zodbot> The meeting name has been set to 'workstation_wg' 13:03:57 <mclasen> #chair mcatanzaro 13:03:57 <zodbot> Current chairs: mcatanzaro mclasen 13:04:03 <mclasen> #chair cmurf 13:04:04 <zodbot> Current chairs: cmurf mcatanzaro mclasen 13:04:19 <cmurf> #meetingname workstation 13:04:19 <zodbot> The meeting name has been set to 'workstation' 13:04:25 <mclasen> #chair otaylor 13:04:26 <zodbot> Current chairs: cmurf mcatanzaro mclasen otaylor 13:04:36 <otaylor> .hello2 13:04:38 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com> 13:04:46 <cmurf> .hello chrismurphy 13:04:47 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com> 13:04:55 <kalev> morning 13:05:00 <mclasen> #chair kalev 13:05:00 <zodbot> Current chairs: cmurf kalev mcatanzaro mclasen otaylor 13:05:40 <cmurf> we need one more 13:05:51 <mclasen> I haven't seen cschaller yet 13:06:03 <mclasen> langdon: around ? 13:07:27 <mclasen> its columbus day, so there's a chance that they are not around today... 13:08:08 <mcatanzaro> No aday or ngompa either 13:08:57 <mclasen> aday is at the shell hackfest 13:08:59 <cmurf> well we have the time we might as well use it 13:09:05 <mclasen> yes, sure 13:09:06 <cmurf> the votes will be straw votes 13:09:18 * mclasen looks at tickets 13:09:39 <cmurf> I wonder if we should have a weekly meeting instead of every other week 13:09:55 <cmurf> 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 <mclasen> which is why I am never prepared for this 13:10:22 * kalev doesn't have a strong opinion either way. 13:10:36 <cmurf> it's better if they're 30 minutes instead of an hour than to have fortnightly meetings 13:11:11 <mclasen> I'm inclined to agree with that 13:12:41 <otaylor> I'm not sure how well I 13:12:59 <otaylor> 'll do at making short 9am meetings every week, but I can try! 13:13:38 <mcatanzaro> I'll never be enthusiastic about 8 AM meetings, but I'm OK with 30 minutes weekly 13:14:02 <mclasen> one option would be to enforce the 30 minutes and move half an hour later 13:14:21 <mclasen> but then we trade a biweekly schedule with an off-the-full-hour schedule 13:14:27 <mclasen> not sure thats better 13:14:40 <mcatanzaro> 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 <mcatanzaro> 8:30 seems fine to me, it's not odd to start meetings on a :30 IMO 13:15:36 <mcatanzaro> Er, 9:30 Eastern 13:16:17 * kalev is happy with either. 13:16:38 <mclasen> cmurf: want to file a ticket and bring it to a vote next time we have quorum ? 13:16:46 <cmurf> sure 13:16:59 <mclasen> thanks 13:17:34 <mclasen> here is a ticket that could use some discussion : https://pagure.io/fedora-workstation/issue/107 13:17:42 <mclasen> "reconsider updates policy" 13:18:01 <cmurf> yeah this is interesting 13:18:05 <mcatanzaro> mclasen, use #topic :) 13:18:07 <mclasen> mcatanzaro: your ticket, want to pitch it ? 13:18:21 <mclasen> #topic reconsider updates policy, https://pagure.io/fedora-workstation/issue/107 13:19:03 <mcatanzaro> Pitch: let's make updates happen at most once per week. Or even every two weeks. Something like that. 13:19:22 <mcatanzaro> For released distros, of course. E.g. F30, not F31. 13:19:52 <kalev> my preference would be to have updates batching on server side, so that they can be tested to be known good 13:19:53 <mcatanzaro> 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 <cmurf> what's the trigger? does it exist yet? would it be in PK or gnome-software? 13:20:09 <otaylor> mcatanzaro: and you are thinking of this as a g-s thing, not a bodhi thing? 13:20:18 <mclasen> kalev: can you describe the current behavior ? 13:20:30 * mclasen implemented it originally, but ... too long ago 13:20:32 <mcatanzaro> 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 <cmurf> I thought there was supposed to be a week delay already for non-security related things 13:20:56 <kalev> 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 <cmurf> is it that so many updates in bodhi have a security tag now? 13:21:18 <mcatanzaro> cmurf: I guess either there are security-related things every day, or it "feels that way" 13:21:27 <cmurf> oh dear 13:21:35 <kalev> 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 <mclasen> thats basically the premise of silverblue, no ? 13:22:10 <kalev> yes 13:22:11 <cmurf> 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 <cmurf> any way on the server side to coordinate this so they end up being based on the same thing, same effort? 13:22:46 <otaylor> 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 <cmurf> ok 13:23:04 <cmurf> what is the silverblue cadence? 13:23:14 <mcatanzaro> 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 <otaylor> cmurf: "nightly compose, if it works - goes out" 13:23:26 <cmurf> i see 13:24:07 <mcatanzaro> 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 <mcatanzaro> 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 <mclasen> kalev: we only do automatic updates for flatpaks, right ? there's no automatic security updates ? 13:24:45 <cmurf> right that suggests better granularity is needed for the security update 13:24:48 <mcatanzaro> Can't do automatic security updates because that would require reboot.... 13:24:48 <kalev> mclasen: correct, only for flatpaks 13:25:13 <mclasen> mcatanzaro: good point 13:25:27 <mcatanzaro> 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 <otaylor> mcatanzaro: could we go off of update severities for security updates? 13:25:48 <mcatanzaro> otaylor: Great minds think alike! 13:25:57 <otaylor> would have rebooted today for https://bodhi.fedoraproject.org/updates/FEDORA-2019-be4b40654f 13:26:09 <kalev> sure, checking urgency sounds like it's worth a try 13:26:12 <otaylor> (but not on silverblue, eventually) 13:26:41 * cmurf likes the urgency concept 13:26:41 <otaylor> 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 <otaylor> it's all available through the bodhi api 13:26:59 <mcatanzaro> Related Silverblue epic: https://teams.fedoraproject.org/project/silverblue/epic/95 ("Slow down the update cadence") 13:27:01 <cmurf> default to urgent updates only, users can opt into daily 13:27:09 <mclasen> kalev: do we have severity information for updates ? 13:27:12 <mcatanzaro> Looks like Silverblue wants one update every 2-3 weeks 13:28:34 * mclasen has to run for a minute 13:28:40 <kalev> mclasen: the repo metadata includes severity information, but not sure if packagekit supports severity, let me take a look 13:29:15 <mcatanzaro> 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 <otaylor> I can figure that out 13:29:52 <mcatanzaro> Thanks 13:30:08 <kalev> 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 <mcatanzaro> #action otaylor to figure out how frequently bodhi updates are marked urgent 13:32:24 <mcatanzaro> 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 <mclasen> ok, more on this ticket, or should we wait for stats and move on to the next topic ? 13:33:02 <otaylor> 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 <mclasen> useful data 13:34:25 <otaylor> https://bodhi.fedoraproject.org/updates/?releases=F30&type=security&severity=high gives quite a few more 13:34:33 <mcatanzaro> Nice, stats. :P So we can talk to stransky about that, I think one week is OK for Firefox 13:34:56 <mcatanzaro> Looks like this will work 13:35:26 <mcatanzaro> 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 <otaylor> Presumably any exploit that people *know* is actively remotely exploitable will be marked urgent (e.g., the recent exim updates) 13:36:17 <mclasen> mcatanzaro: but if the update is truly urgent, such a notification is warranted, imo 13:36:24 <mcatanzaro> Yes, if it is urgent 13:36:27 <mcatanzaro> But not otherwise 13:37:03 <mcatanzaro> Also, the shutdown dialog is currently broken: https://gitlab.gnome.org/GNOME/gnome-software/issues/791 13:37:59 <kalev> it was a packagekit change that broke the shutdown dialog offering 13:38:24 * kalev commented in the ticket. 13:39:16 <mclasen> mcatanzaro: is that on the f31 blocker list ? 13:39:50 <cmurf> mclasen: nope 13:40:30 <mclasen> would be nice to get a freeze exception for it 13:40:36 <mcatanzaro> No, it's maybe a F29 or F28 regression, old bug 13:41:29 <mclasen> would still be nice to get a freeze exception for it :/ 13:41:39 <cmurf> 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 <mcatanzaro> We can fix it post-release so it's not a big deal if it gets a FE 13:42:04 <mclasen> I don't think a fix would be touching otherwise working updates 13:42:13 <mcatanzaro> Also I suspect if it was easy to fix, it would be fixed by now :P 13:42:36 <mclasen> I suspect it wasn't getting anybodys attention 13:42:39 <mcatanzaro> Anyway I guess kalev to look into that? 13:42:45 <cmurf> mclasen: the fix would be in PackageKit? So it would touch that? 13:42:52 <mcatanzaro> (kalev, volunteer yourself, you know you want to ;) ;) ;) 13:42:57 <mclasen> I think the fix would be in gnome-shell 13:43:02 <cmurf> gotcha 13:43:03 <kalev> cmurf: no, it would be in gnome-shell 13:43:27 <mclasen> packagekit exiting on idle is good, we don't want to change that 13:43:53 <kalev> 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 <kalev> or something along those lines 13:44:09 <kalev> so shell would have to spin up packagekit properly 13:44:11 <mclasen> 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 <cmurf> 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 <kalev> it's gnome-software checking for updates, I guess 13:46:07 <mclasen> but that should still be time-based ? I mean, it shouldn't check for updates _just_ because I go online 13:46:28 <kalev> yeah, something wonky must be going on there 13:46:29 <mclasen> but it should check if it is overdue and I go online 13:46:33 * kalev agrees. 13:46:38 <cmurf> it does seem like I get that refresh every time I turn on VPN and again when I turn it off 13:46:47 <cmurf> for sure when logging out and back in 13:48:10 <mclasen> 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 <cmurf> mcatanzaro: :P forward progress is being made 13:49:32 <cmurf> everything is complicated 13:50:25 <mclasen> mcatanzaro: 30 minutes would certainly require us to prepare better in tickets, and be more focused on voting in the meeting 13:51:01 <mcatanzaro> Or vote in tickets and only use the meeting for controversies, like FESCo (not sure we need to do this though) 13:51:11 <cmurf> mcatanzaro: +1 13:51:15 <mcatanzaro> Er hi cschalle, around? 13:51:26 <cmurf> i prefer that, i think the meetings should be for the discussion 13:51:27 <mclasen> he's out sick 13:51:48 <mclasen> ok. we have 9 minutes left. not sure thats enough for a controversy 13:52:16 <mcatanzaro> topic -> open floor? 13:52:25 <mclasen> sure, good idea 13:52:29 <mclasen> #topic open floor 13:52:29 <cmurf> tis' enough for an unresolved controversy :D 13:52:48 <kalev> who's the chair next weeek? 13:52:55 <mclasen> here is one: https://teams.fedoraproject.org/project/silverblue/us/82?kanban-status=319 13:53:25 <mclasen> "make a subset of flathub available in Fedora" (Silverblue, specifically) 13:54:13 <mclasen> I've made a pr to add a filtered flathub remote to fedora-workstation-repositories 13:54:34 <cmurf> 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 <mclasen> with a whitelist that currently allows exactly one application: steam 13:54:38 <cmurf> https://pagure.io/Fedora-Council/status_reports/c/a3e69348cc86436de156bb8935f38fafdd8d822b?branch=master 13:55:01 <kalev> I quite like what mclasen did to add the same apps through flathub that we already had approved previously as ok 13:55:05 <cmurf> so i'll do it sometime this week, if anyone has status notes, email them to desktop@ 13:55:07 <mcatanzaro> 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 <cmurf> mcatanzaro: haha 13:55:28 <cmurf> so my problem is I said yes 13:55:33 <mcatanzaro> 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 <kalev> mcatanzaro: would have been better to wait for workstation wg to approve this first 13:56:04 <mcatanzaro> mclasen: Probably should look 13:56:14 <kalev> 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 <mclasen> I don't feel the fire if I don't look 13:56:33 <kalev> :) 13:56:34 <mcatanzaro> But maybe I violated the policy, does the policy require that we approve new repos? 13:56:42 <kalev> yes 13:56:52 <mcatanzaro> Maybe I should actually read the policy.... 13:56:55 <kalev> or at least I believe so 13:57:02 <mcatanzaro> Proposal: WG to thanks cmurf for volunteering to send these reports 13:57:05 <mclasen> you didn't violate the policy until we build and publish a package update? 13:57:22 <mcatanzaro> Proposal: WG to scold mcatanzaro for potentially violating third-party repos policy :) 13:58:26 <mclasen> sadly, we don't have quorum, so our scolding will be non-binding 13:58:47 <kalev> haha :) 13:58:48 <cmurf> non-binding thanks and non-binding scoldings, we're broken 13:59:27 <mclasen> any last topic for open floor ? one minute left 14:00:02 <mcatanzaro> We need to get attendance up :/ 14:00:07 <mcatanzaro> Bye 14:00:21 <mclasen> good point 14:00:26 <mclasen> #endmeeting