13:00:05 <stickster> #startmeeting Workstation WG 13:00:07 <zodbot> Meeting started Mon Oct 9 13:00:05 2017 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:07 <zodbot> The meeting name has been set to 'workstation_wg' 13:00:07 <stickster> #meetingname workstation 13:00:07 <zodbot> The meeting name has been set to 'workstation' 13:00:10 <stickster> #topic Roll call 13:00:15 <stickster> .hello pfrields 13:00:17 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com> 13:00:35 <ryanlerch> .helo ryanlerch 13:00:43 <ryanlerch> .hello ryanlerch 13:00:44 <zodbot> ryanlerch: ryanlerch 'Ryan Lerch' <rlerch@redhat.com> 13:01:20 <mclasen> .hello mclasen 13:01:21 <stickster> o/ ryanlerch, thanks for staying up late for us :-) 13:01:21 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com> 13:01:25 <ryanlerch> good morning stickster! 13:01:28 <kalev> .hello kalev 13:01:29 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com> 13:01:31 <ryanlerch> :D 13:01:40 * mclasen watches cschalle walk in 13:02:02 <stickster> I think the correct term is "saunter" :-) 13:02:57 <stickster> #chair ryanlerch kalev mclasen 13:02:57 <zodbot> Current chairs: kalev mclasen ryanlerch stickster 13:03:10 <kalev> I have GNOME 3.26.1 queued for updates-testing, would be great if everyone running F27 could give it a try and leave karma 13:03:13 <kalev> https://bodhi.fedoraproject.org/updates/FEDORA-2017-69737f8a58 13:03:14 * stickster hopes cschaller turns up here, or rdieter or otaylor, so we can have quorum 13:03:19 <stickster> #topic Housekeeping 13:03:21 <otaylor> .hello otaylor 13:03:22 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com> 13:03:28 <stickster> excellent ;-) 13:03:29 <stickster> #chair otaylor 13:03:29 <zodbot> Current chairs: kalev mclasen otaylor ryanlerch stickster 13:03:46 <mclasen> kalev: excellent, I was going to ask about it 13:03:47 <stickster> #info stickster has to leave at :30 today to run another IRL meeting 13:03:58 * cschalle hi 13:04:10 <stickster> #chair cschalle 13:04:10 <zodbot> Current chairs: cschalle kalev mclasen otaylor ryanlerch stickster 13:04:25 <stickster> #info Please try and karm up the GNOME 3.26.1 megaupdate 13:04:43 <stickster> #info --- Agenda for today --- 13:04:44 <stickster> #link https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting 13:05:13 <stickster> I'm going to hit one that I hope is a quickie first 13:05:20 <stickster> #topic Langpack installation 13:05:28 <stickster> #link https://pagure.io/fedora-workstation/issue/27 13:06:12 <stickster> I left a comment this morning: can we go ahead and approve adding libreoffice-langpack-* into Workstation compose? (It's only ~32 MB added.) 13:07:23 <stickster> cschalle: kalev: mclasen: ryanlerch: otaylor: ^ (+/-1) 13:07:25 <mclasen> +1 13:07:31 <kalev> +1 13:07:34 <ryanlerch> +1 13:08:29 <otaylor> +1 since it's that "small" 13:09:22 <stickster> I +1 my own proposal, cschalle? 13:09:58 <stickster> OK, in the interest of time... 13:10:00 <stickster> #agreed APPROVED: Add libreoffice-langpack-* to Workstation compose (+1: 5, 0: 0, -1: 0) 13:10:19 <stickster> #info There is more to decide here, but it's a bigger discussion and we'll come back to this ticket 13:10:39 * rdieter waves, hi 13:10:44 <stickster> o/ rdieter! 13:10:46 <stickster> #chair rdieter 13:10:46 <zodbot> Current chairs: cschalle kalev mclasen otaylor rdieter ryanlerch stickster 13:10:59 <stickster> #topic Update frequency 13:11:07 <stickster> #link https://pagure.io/fedora-workstation/issue/28 13:11:21 <mclasen> I'm looking for the diagram that describes the current gnome-software algorithm 13:11:26 <mclasen> haven't tracked it down yet 13:11:53 <stickster> Oh kalev -- would you mind doing the necessary for the compose above? 13:12:02 <stickster> sorry, I should have declared the #action 13:12:27 <kalev> stickster: sure, happy to 13:12:32 <stickster> kalev: thank you sir! 13:12:37 <ryanlerch> so is the proposal here to just limit the notification? 13:13:04 <ryanlerch> or actaully limit how often gnome-sw looks for new updates? 13:13:18 <stickster> ryanlerch: I don't think there's a specific proposal, but that's how I understand the problem: seeing minor updates offered daily 13:13:21 <rdieter> the former I think 13:13:40 <rdieter> I don't think it's possible to check for *only* urgent updates without all the others 13:13:52 <stickster> rdieter++ 13:13:54 <zodbot> stickster: Karma for rdieter changed to 5 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 13:13:59 <kalev> I was actually going to suggest the opposite here than what the ticket asks for, because we just got batched weekly updates in bodhi 13:14:06 <otaylor> I feel there isn't enough data to act on this proposal 13:14:12 <stickster> And I don't think this proposal is about urgent/security updates. 13:14:19 <stickster> er, s/proposal/topic/ 13:14:39 <rdieter> the proposal specifically mentioned urgent updates (?) 13:14:40 <otaylor> is there reason that mcantazaro is getting daily requests *precisely* the flatpak nightlies and not something else? 13:14:42 <kalev> bodhi now by default puts all updates in a batched state, and sends them out every tuesday 13:14:49 <kalev> before that, they'd go out immediately 13:15:03 <rdieter> sounds like bodhi may give mostly what is wanted here then 13:15:21 <kalev> so by default, all bodhi updates go out weekly and there's a way for package maintainers to submit them to stable directly, if needed 13:15:43 <stickster> so is this something that needs to be addressed by flathub similarly? 13:16:00 <mclasen> rdieter: but it should be possible to only notify for urgent updates, even if the check found minor ones 13:16:05 <otaylor> stickster: for flatpaks. I think it 110% needs to be handled on the client side 13:16:13 <mclasen> in fact, I believe thats how it is meant to work 13:16:22 * mclasen goes back to looking for the diagram 13:16:38 <rdieter> mclasen: I agree 13:16:50 <otaylor> stickster: that is, the repository should just say what is available, and let clients figure out when it's worth annoying users with updates (auto-updates are also an option) 13:17:03 <kalev> so what I'm saying is that now that bodhi has weelky batched updates, I think we need to make sure we check updates daily in gnome-software so that we play nice with the bodhi scheduling 13:17:21 <kalev> and completely drop the gnome-software weekly scheduling and just follow what bodhi does 13:18:17 <kalev> https://rungehoc.wordpress.com/2017/08/07/bodhi-101-an-updates-life-cycle/ 13:18:57 <rdieter> to me, there's 2 things here: how often to check repo metadata, how often to notify user of what's available. these are not neccessarily the same (are they?) 13:19:00 <stickster> kalev++ 13:19:19 <rdieter> and I thought we're just talking about the second thing (notification) 13:19:42 <stickster> rdieter: They shouldn't be, correct -- this is what otaylor is saying as well I believe. 13:19:48 <mclasen> https://bug709121.bugzilla-attachments.gnome.org/attachment.cgi?id=256126 13:20:04 * mclasen adds that to the ticket 13:20:59 <ryanlerch> this is where we need to be careful though, if bodhi is moving to (weelky) batched updates, and software only notifies once a week, a user could end up being a whole week behind if the timing is right(wrong) 13:21:38 <stickster> ryanlerch: but if these are non-urgent updates, that's not a huge problem 13:21:43 <rdieter> ryanlerch: that is the point, if we don't want to notify of updates more than once a week. 13:21:54 <rdieter> otherwise that rule will be broken 13:22:01 <stickster> I think trying to be too clever about timing would be a headache 13:22:02 <otaylor> ryanlerch: yeah. Also, I think if you get a security update, on monday, then you won't see weekly updates until next monday - do we want that? 13:22:42 <rdieter> depends on the implementation, I'd say you want no more than 1 *non-security* update notification per week 13:22:58 <rdieter> ie, security updates should not reset the weekly counter (or whatever you want to call it) 13:22:59 <mclasen> I think the next step would be to find out what broken the logic in that diagram that is supposed to ensure just that 13:23:17 <otaylor> I actually, think you probably want no more than one update per week, period, unless security forces it, because reboots are just too disruprive 13:23:21 <rdieter> mclasen: +1 13:23:28 <stickster> mclasen: that sounds rational to me 13:23:46 <mclasen> I'll put it on richards list, but it'll be behind a few other things 13:23:56 <otaylor> Do people think there is a general problem here, or is it just something that mcantazaro is seeing? 13:24:09 <stickster> mclasen: It would also be good to know whether the security update case means you apply all pending updates; I was under the impression that is what happens 13:24:12 * ryanlerch is not a fan of adding options for everything, but just putting it out there -- should we add an option for a user to manage the fequency of the notifications? 13:25:43 <otaylor> ryanlerch: probably not in the user interface - it's just too complex of a landscape to have an option make obvious sense 13:25:53 <mclasen> ryanlerch: lets make the hardcoded value work before we think about that 13:25:54 <stickster> I agree with otaylor 13:26:18 <stickster> I mean, if I really want to force the issue with a manual update I can do that 13:26:38 <ryanlerch> otaylor: i pretty much agree too - just throwing it out there :) 13:28:01 <stickster> mclasen: OK, so are you taking the action to discuss with hughsie, describe the timing cases more specifically, and figure out whether there's a real improvement to be had here? 13:28:41 <mclasen> yes 13:28:52 <ryanlerch> i think we all agree with the general idea of this proposal - don't annoy the user :D 13:29:02 <stickster> ryanlerch++ 13:29:47 <stickster> #info We agree we don't want to annoy the user with non-urgent updates, but need more clarity on how this logic or timing is working/non-working 13:30:43 <stickster> #info bodhi batches non-urgent updates weekly, which helps 13:30:49 <stickster> #info We agree we don't want to annoy the user with non-urgent updates, but need more clarity on how this logic or timing is working/non-working and bring back to WG 13:30:55 <stickster> #undo 13:30:55 <zodbot> Removing item from minutes: INFO by stickster at 13:30:49 : We agree we don't want to annoy the user with non-urgent updates, but need more clarity on how this logic or timing is working/non-working and bring back to WG 13:31:21 <stickster> #action mclasen bring this to hughsie to figure out whether there is a gnome-software improvement to be had here 13:31:37 <stickster> OK, I need to run to my IRL meeting. Does someone want to take over gavel, or do we call it? 13:32:45 <rdieter> (if there's nothing more to discuss, call it) 13:33:06 * stickster waits 30 sec for objections 13:34:02 <stickster> OK, th-th-th-that's all folks! Thanks for coming. 13:34:03 <stickster> #endmeeting