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