14:07:16 #startmeeting weekly meeting 14:07:17 Meeting started Mon Feb 20 14:07:16 2017 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:07:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:07:17 The meeting name has been set to 'weekly_meeting' 14:07:22 .hello mvo 14:07:23 mvollmer: mvo 'Marius Vollmer' 14:07:39 .hello larsu 14:07:40 larsu: larsu 'Lars Karlitski' 14:07:48 .hello garrett 14:07:49 garrett: garrett 'Garrett LeSage' 14:08:20 #topic Agenda 14:08:46 .hello andreasn 14:08:47 andreasn: andreasn 'Andreas Nilsson' 14:09:38 garrett: is garbage collector a good topic, perhaps? 14:09:57 andreasn: sure, I suppose, if people would like to talk about it? 14:10:15 I think I'm up for talking about it :) 14:11:03 * garbage collection/task killer 14:13:13 okay 14:13:22 #topic garbage collection/task killer 14:14:30 #link https://github.com/cockpit-project/cockpit/wiki/Feature:-Task-Killer#resources 14:14:44 garrett: what is the current status of this? 14:15:16 I've been looking into ways to determine if iframes can be inspected to figure out their impact on system resources 14:15:22 such as RAM, CPU, etc. 14:15:49 andreasn and I were talking about making it possible to manually kill parts of cockpit, and we decided the best place might be the about box to do this 14:16:10 but it would be a little odd to have a listing of the various components without some sort of way to determine which might be using the most resources 14:16:45 yeah, only having it be triggered by a shortcut can make it hard to discover for those who wants to get to it, and easy to accidentally trigger for those that are not interested in it 14:16:48 for web pages, there are only limited ways to look into this, but I found an API that's cross-browser that we can use to weigh parts of cockpit that use iframes against other parts 14:17:08 ideally, no one should really have to manually kill parts of cockpit 14:17:08 that's really cool 14:17:21 in normal usage 14:17:31 this is mainly meant as a developer/debugging tool 14:17:48 I would suspect most people having issues with pages in their browser would just reload 14:18:32 but it would be nice to see how heavyweight some parts of cockpit are 14:19:12 with this information, we could possibly have an automatic task killer that can figure out if it needs to shut down parts of cockpit (which can be re-loaded on the fly) 14:20:15 really good research 14:20:19 today, I made 2 little snippets that demonstrate figuring out resource usage with Cockpit is possible _today_, if you copy and paste them into your browser's devtools console 14:20:24 👍 14:20:38 is the next step wireframes? 14:20:52 we could use something like this to create a task list, and show it in an enhanced about box 14:20:57 yes, the next step is wireframes 14:21:07 I didn't want to jump into mockups without knowing if this would even be possible 14:21:17 but, thankfully, it looks like we can do this 14:21:28 do you think it would help with stories and workflows, just to spell it out properly? 14:21:40 just one quick and small one 14:21:44 andreasn: spell what out properly? 14:21:53 the scope of the feature 14:21:58 oh, certainly 14:22:10 just something small and quick 14:22:31 "Jeff is a Cockpit plugin developer. He needs to debug the garbage collection" 14:22:38 or something along the lines of that 14:22:54 the one issue I see with that, is this only shows you resources on load 14:22:56 not the current page 14:23:13 that is, if canvas is involved, then that could spike the CPU and resource usage 14:23:25 even if you manipulate the DOM a bunch, it could impact both as well 14:23:37 this is just a quick comparison between parts 14:23:47 so it should not be aimed towards plugin developers? 14:23:55 but rather core contributors? 14:24:05 no, probably not, unless they're interested in load information 14:24:15 however, some browsers can give you this information in-browser also 14:24:36 but this would enable someone to kill off a task within cockpit 14:25:12 sounds good. I think the stories could really help specify who this is for, because that's been a bit fuzzy for me 14:25:19 OK 14:25:27 well, I was just told that we should have task killing in 14:25:38 because at first it felt like "task killing for everyone and their brother" 14:25:41 and it sounded like a developer-focused feature from when we talked about it as a team previously 14:25:46 yeah 14:26:00 the thing is, people should not _have to_ kill tasks 14:26:05 right 14:27:23 but really good progress so far. 14:27:31 I guess that was that on that. EOT? 14:27:38 thanks! 14:27:48 I think that's everything, unless other people want to speak up about it 14:31:20 alright! 14:31:25 #topic Any other business 14:32:11 none from me 14:32:49 that's it from me 14:33:04 nice :) 14:33:09 thanks! 14:33:12 #endmeeting