16:14:03 <puiterwijk> #startmeeting Cockpit public meeting 2014-11-03 16:14:03 <zodbot> Meeting started Mon Nov 3 16:14:03 2014 UTC. The chair is puiterwijk. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:14:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:14:05 <puiterwijk> #meetingname Cockpit 16:14:05 <zodbot> The meeting name has been set to 'cockpit' 16:14:07 <puiterwijk> #chair puiterwijk andreasn mvollmer stefw sgallagh jscotka 16:14:07 <zodbot> Current chairs: andreasn jscotka mvollmer puiterwijk sgallagh stefw 16:14:09 <mvollmer> jscotka, any topics from you? 16:14:09 <puiterwijk> #topic Welcome 16:14:14 <puiterwijk> .hellomynameis puiterwijk 16:14:15 <zodbot> puiterwijk: puiterwijk 'Patrick Uiterwijk' <puiterwijk@redhat.com> 16:14:22 <jscotka> mvollmer, nothing important 16:14:37 <sgallagh> .hello sgallagh 16:14:38 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 16:14:42 <jscotka> last week I didn't have much time to work with cockpit 16:14:52 <mvollmer> .hellomynameis mvo 16:14:53 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com> 16:15:08 <stefw> .hellomynameis stefw 16:15:11 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com> 16:15:31 <puiterwijk> no Andreas today? 16:15:49 <puiterwijk> #topic Agenda 16:15:51 <puiterwijk> * dbus-json3 16:15:53 <puiterwijk> * binary channels 16:15:55 <puiterwijk> * state of host switcher 16:15:57 <puiterwijk> * blockers for porting next page into a package 16:16:09 <puiterwijk> #topic General status 16:16:49 <puiterwijk> err, sorry, that got stuck in there somehow 16:16:51 <puiterwijk> #undo 16:16:51 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x323f8f50> 16:16:53 <puiterwijk> #topic dbus-json3 16:16:58 <stefw> it's merged :) 16:17:14 <puiterwijk> stefw: hah, that's a short discussion :) 16:17:23 <puiterwijk> #info dbus-json3 merged 16:17:26 <stefw> mvollmer, did some follow up pull requests 16:17:55 <mvollmer> yep, i think we'll lerarn more as we use it more. 16:18:21 <mvollmer> for example, should we have a proxy.release or similar method? 16:18:44 <mvollmer> that will unsubscribe the signals 16:19:08 <mvollmer> i am now writing the new dashboard with dbus-json3 and it works very well. 16:19:20 <stefw> cool 16:19:31 <stefw> mvollmer, i thought about proxy.release 16:19:36 <stefw> but really closing the channel is more ideal 16:20:08 <mvollmer> on the dashboard I now want to stop the resource monitor signals when it is not visible. 16:20:21 <stefw> yes, unsubscribe makes a lot of sense there 16:20:23 <mvollmer> but we already have a channel that we can use 16:20:36 <stefw> i would suggest not using a proxy there 16:20:41 <stefw> but custom code, since it needs better performance 16:20:55 <mvollmer> yes, that's what I am doing, and works well. 16:21:42 <mvollmer> ok, so summary, no new code with anything except dbus-json3. :-) 16:22:04 <jscotka> mvollmer, I would like to mention that I've tested cockpit with google chrome, and it works perfectly and I plan to test epiphany with proper certificate this week. 16:22:28 <stefw> ... so i guess we could change the topic to browser testing 16:22:31 <stefw> i have something to report there 16:22:35 <mvollmer> ok 16:22:54 <stefw> ... 16:22:58 <puiterwijk> err, next is binary channels? 16:23:00 <puiterwijk> but sure 16:23:03 <puiterwijk> #topic Browser testing 16:23:08 <stefw> well jscotka wanted to discuss browser testing 16:23:17 <stefw> i posted a branch that shows the reason why cockpit cannot run 16:23:18 <jscotka> stefw, no no, I only mention that :-) 16:23:21 <stefw> it shows it on the login screen 16:23:26 <jscotka> but okay :-) 16:23:36 <stefw> jscotka, if you could test that branch, that would be helpful 16:23:47 <stefw> https://github.com/cockpit-project/cockpit/pull/1419 16:23:55 <jscotka> stefw, perfect I'll do that. 16:24:03 <stefw> in the case of konquerer on F20 it indicates more clearly what the problem is 16:24:09 <stefw> konqueror doesn't appear to do WebSockets 16:24:11 <jscotka> tomorrow I'll also test IE 16:24:12 <stefw> at least that version 16:24:16 <stefw> jscotka, great 16:24:21 <stefw> IE10 should be our minimum 16:24:36 <stefw> we need to add something to the guide about supported browsers 16:24:37 <jscotka> stefw, it is in which wersion of windows? 16:24:49 <stefw> jscotka, i think you can install it on windows 2003 and later 16:24:51 <stefw> not sure 16:24:54 <stefw> exactly 16:24:58 <jscotka> stefw, or would it be possible to test it also via wine emulator? 16:25:03 <andreasn___> hi! sorry for being late! 16:25:03 <stefw> again, not sure 16:25:07 <puiterwijk> I think Vista+ (for client). XP is stuck on IE8 if I recall correctly 16:25:20 <jscotka> stefw, okay, it would be possible. 16:25:28 <stefw> jscotka, i think figuring out and documenting how to do IE10 testing in wine would be an awesome project 16:25:33 <stefw> it would allow us to cross check stuff more easily 16:25:51 <stefw> but i'll put a list in the guide of what's supported 16:26:22 <puiterwijk> jscotka: just checked. IE10 is available for Win7+ 16:26:22 <jscotka> stefw, will see. I'm not sure if it is possible, I saw only IE8 running in wine 16:27:05 <stefw> interesting 16:27:27 <jscotka> stefw, thanks for debugging output for troubles discovery. I'll test it tomorrow 16:27:30 <stefw> jscotka, in addition it would be nice to have the login page readable (the failure message) on unsupported browsers 16:27:41 <stefw> that includes crap like IE6 16:27:48 <stefw> i think the layout could be wrong, but at least be readable 16:27:57 <stefw> another thing we need to do is produce a good messag ewith noscript 16:28:00 <stefw> would be interesting to test that 16:28:04 <jscotka> stefw, yes, with some suggestion, like link to firefox download page for example 16:28:58 <andreasn> nice idea½ 16:29:00 <stefw> puiterwijk, one more agenda point, updating our website, now that we have more stuff online 16:29:01 <andreasn> ! 16:29:03 <jscotka> it would be nice to see cockpit running everywhere, also some broken or unsupported features but still readable 16:29:12 <stefw> it won't run everywhere 16:29:13 <puiterwijk> stefw: sure, appended 16:29:17 <stefw> we've specifically made the decision 16:29:20 <stefw> light on the server 16:29:22 <stefw> rich on the client 16:29:28 <stefw> the client needs to be quite powerful to run cockpit 16:29:35 <jscotka> like disabled consoles, or some javascript features or some HTML5 elements but still working 16:29:36 <stefw> our goal should be to make it run on all sorts of servers 16:29:38 <stefw> not all sorts of client 16:29:53 <stefw> we should run on browsers that are installable on all the main OS's 16:30:01 <stefw> but not any ol browser and version 16:30:01 <jscotka> for example some view only mode. 16:30:14 <stefw> unfortunately that's not gonna happen 16:30:18 <stefw> everything, and i mean everything, uses javascript 16:30:23 <jscotka> no, it is only idea 16:30:51 <jscotka> stefw, propably javascript is supported for long time, but question is if every features are supported in older browsers 16:31:15 <andreasn> how old is older browsers? 16:31:17 <puiterwijk> jscotka: well, there's caniuse.com to see in wha browser versions what features are supported 16:31:28 <jscotka> andreasn, no idea :-) it is up to you 16:31:29 <stefw> yes, and you can just do caniuse.com and type WebSocket 16:31:32 <stefw> that's the ones we can support 16:31:44 <stefw> i specifically haven't started requiring features that come after WebSocket support 16:31:51 <stefw> http://caniuse.com/#search=WebSocket 16:31:54 <stefw> so IE10 16:32:00 <stefw> Firefox 11+ 16:32:03 <stefw> Chrome 16+ 16:32:11 <stefw> Safari 7+ 16:32:16 <stefw> Opera 12.1+ 16:32:27 <stefw> IOS Safari 6.1+ 16:32:34 <stefw> Android 4.4+ 16:32:37 <jscotka> stefw, perfect. it is good page also to link from login page in case something wrong happen 16:32:42 <andreasn> and both Firefox and Chrome is on a automatic update mode on most OSes 16:33:00 <puiterwijk> #info To determine minimum supported browser versions, see http://caniuse.com/#search=WebSocket 16:33:14 <stefw> there are other features we require than WebSocket 16:33:23 <puiterwijk> #undo 16:33:23 <zodbot> Removing item from minutes: INFO by puiterwijk at 16:33:00 : To determine minimum supported browser versions, see http://caniuse.com/#search=WebSocket 16:33:23 <stefw> but they almost always are implemented earlier that WebSocket in a given browser 16:33:35 <stefw> if there are some strange selbst-gebastelte browsers 16:33:37 <puiterwijk> #info To determine minimum supported browser versions that support websockets, see http://caniuse.com/#search=WebSocket 16:33:43 <stefw> er... like home made browsers 16:33:52 <jscotka> so websocket is the most imporatnt and killing feature, isn't it? 16:33:54 <stefw> that some dude made, that supports WebSocket but not some of the other requisites we have 16:33:58 <stefw> then we also won't run there 16:34:03 <stefw> jscotka, yes 16:34:45 <jscotka> okay, perfect, it is good to know. 16:35:00 <github> [cockpit] stefwalter closed pull request #1422: bridge: Fix use of 0 instead of NULL (master...null-vs-zero) http://git.io/U0AQOw 16:35:07 <puiterwijk> stefw: I think WS is the most important feature and javascript support, not? the rest is mostly CSS and HTML stuff, and I don't think we do that many fancy stuff there 16:35:17 <stefw> there are other javascript features that we depend on 16:35:23 <stefw> Object.defineProperty (especially now in dbus-json3 code) 16:35:47 <stefw> http://kangax.github.io/compat-table/es5/#Object.defineProperty 16:35:49 <jscotka> probably virtual consoles? 16:36:00 <stefw> that's not a browser feature 16:36:01 <andreasn> we use border-radius, a css3 only feature for example 16:36:10 <andreasn> but that falls back to just square borders 16:36:17 <puiterwijk> ah, right. maybe we should get a list of the most important of those things and then determine minimum supported browser based on that? 16:36:20 <stefw> we use JSON parsing 16:36:26 <andreasn> so should be ok on browsers that don't support that 16:36:27 <stefw> localStorage 16:36:45 <stefw> although i think localStorage/sessionStorage is not that critical 16:36:48 <puiterwijk> andreasn: right. but the CSS stuff is making it look nice. if the browser doesn't have that, the UI is just not as pretty, but should still work, not? 16:36:49 <stefw> JSON, WebSocket 16:36:52 <stefw> and now Object.defineProperty 16:37:04 <jscotka> puiterwijk, perfect 16:37:04 <stefw> those are the things we require so far 16:37:07 <andreasn> puiterwijk: correct 16:37:08 <stefw> with WebSocket being the watermark 16:37:09 <puiterwijk> stefw: is that the complete list? 16:37:18 <stefw> well obviously lots of other stuff is asumed 16:37:26 <stefw> so no, it's not a complete list 16:37:48 <stefw> look at src/static/login.html for the things we check for before we allow cockpit to even start 16:38:09 <stefw> the requisite-verbose branch (linked above) adds a couple more 16:38:23 <jscotka> we should to have to hard requirements and some optional, which allows to have nice look 16:38:27 <puiterwijk> right. so to make it easy for users I'd say swe should just maintain a list of browsers that should work, and a list that we tester work? 16:38:41 <stefw> puiterwijk, https://github.com/stefwalter/cockpit/commit/b56b02b8acd6887998874374393e165341ea4882#diff-3e53449b5753406e10eb7da08e1fd98cR48 16:39:05 <stefw> jscotka, yes, for example in the binary work 16:39:14 <stefw> there's a TextEncoder() feature included in some browsers 16:39:20 <stefw> for utf8 -> ArrayBuffer encoding 16:39:32 <stefw> that is optional 16:39:39 <stefw> and a fallback will be used if not available 16:40:47 <jscotka> sounds good. I can still imagine some admins with some oldschool tablets/paltops or something similar to be harkerish :-) 16:41:00 <jscotka> hacker-ish :-) 16:41:10 <puiterwijk> but that means Cockpit won't work with lynx? :-) 16:41:37 <stefw> puiterwijk, if you implement websocket for lynx then it will :P 16:41:45 <stefw> and javascript 16:41:54 <jscotka> or super browser http://links.twibright.com/ working also in framebuffer mode :-) 16:41:55 <stefw> and ascii rendering of stuff 16:41:58 <puiterwijk> stefw: hah. would be fun to see: Cockpit test-based :-) 16:42:12 <puiterwijk> text-based* 16:42:39 <stefw> ssh 16:42:45 <puiterwijk> anyway, guess we're getting silly here. next item on the agenda, or are there more browser testing-related things? 16:42:47 <stefw> i think this agenda topic has expired 16:42:55 <puiterwijk> #topic Binary channels 16:43:03 <jscotka> stefw, hmm, it is not bad idea, to have something like - recompile web stutt for example to n-curses 16:43:15 <stefw> i'm working on making our channels support binary 16:43:16 <jscotka> okay, flame end ;-) 16:43:31 <stefw> they encode to base64 when the feature is not available in the WebSocket 16:43:41 <mvollmer> major blocker is the old websocket proto, right? 16:43:43 <stefw> this means we can do stuff like decode docker logs 16:43:57 <stefw> mvollmer, yes, but working around that isn't that hard 16:44:01 <mvollmer> ok 16:44:11 <stefw> working with ArrayBuffer, base64, and utf8 stuff in the browser isn't fun 16:44:20 <stefw> but with some polyfills from mozilla it works 16:44:32 <stefw> so i'll have something to show probably tomorrow 16:44:42 <stefw> i was just going to do a server side tool that read docker logs and forwarded the text 16:44:50 <mvollmer> great 16:44:50 <puiterwijk> #info Binary support for channels in the works 16:45:06 <stefw> but putting the work into binary channels is the proper thing to do, so we don't have to do that for every thing that happens to have a null character in it 16:45:29 <stefw> also, this is the sorta thing we have to work out before the protocol is considered stable 16:45:41 <stefw> enough to interoperate between different versions of cockpit 16:46:09 <stefw> the protocol itself doesn't change 16:46:18 <stefw> just some some options passed in channel open 16:46:34 <stefw> to know whether a channel should be base64 encoded, and/or allow non-utf8 data 16:47:04 <stefw> i think that's all on that 16:47:09 <mvollmer> ok. 16:47:22 <stefw> any comments welcome of course 16:47:25 <mvollmer> would it make sense to use it for dbus? 16:47:35 <stefw> i don't think so 16:47:46 <stefw> the benefits we get from cleaning up the dbus on the server side are massive 16:48:01 <stefw> in fact for many messages our JSON messages are smaller than the original DBus messages 16:48:02 <stefw> no padding 16:48:07 <stefw> no repeated dbus names 16:48:28 <stefw> just as an example: a textual '1' is shorter than a uint32 16:48:31 <stefw> and so no 16:48:32 <stefw> on 16:48:41 <mvollmer> ok 16:48:54 <mvollmer> and parsing is also not an issue. 16:49:10 <puiterwijk> #topic State of the host switcher 16:49:15 <puiterwijk> err, sorry. 16:49:16 <mvollmer> since JSON.parse is probably much faster than what we can cook up in JS 16:49:17 <puiterwijk> #undo 16:49:17 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x328bb150> 16:49:26 <stefw> indeed 16:49:50 <mvollmer> alright, next? 16:49:55 <puiterwijk> #topic State of the host switcher 16:50:33 <mvollmer> andreasn is reviewing it, some graphics missing, I'd say, otherwise it's done. 16:50:45 <andreasn> looks really good! great work 16:50:46 <mvollmer> andreasn, what do you say? 16:50:53 <stefw> i need to try it out :) 16:50:54 <mvollmer> cool 16:50:57 <puiterwijk> #info Host switcher under review by andreasn, just missing some graphics 16:51:10 <andreasn> yep 16:51:24 <andreasn> it doesn't include the revised overview page, right? 16:51:24 <mvollmer> so how do we change the host avatar? 16:51:31 <andreasn> I have no idea yet 16:51:37 <mvollmer> andreasn, correct, that's next. 16:52:02 <jscotka> In version 0.29 there is missing one thing what was possible in previous versions of cockpit ( I think taht in 0.26 it was possible) 16:52:12 <mvollmer> andreasn, should we somehow bundle the avatar and the host color for the graphs? 16:52:40 <mvollmer> do we want people to set the host color manually? 16:52:54 <andreasn> that was was stefw suggested too. Maybe 16:52:54 <jscotka> I was able to add one host moretimes. now it is not possibe. I'm not sure if it is feature, or but and should it be possible 16:53:10 <andreasn> so I use color coding for my servers, a little strap around the ethernet cables 16:53:16 <andreasn> but I have no idea how common that is 16:53:43 <andreasn> around the power cables too 16:53:47 <mvollmer> we could put that in the same dialog as the avatar 16:54:04 <andreasn> and some good default colors 16:54:09 <stefw> andreasn, i think choosing colors is really good, along with defaults 16:54:17 <stefw> you can highlight servers to stand out, etc. 16:54:21 <andreasn> yeah, it needs great defaults 16:54:26 <stefw> it's accessible too for color blind people 16:54:29 <stefw> they can choose stuff that works 16:54:32 <andreasn> indeed 16:55:16 <andreasn> I'm thinking a good place might be in the hostname dialog. It kind of belongs together, but not 100% sure yet 16:55:27 <mvollmer> ahh, good idea. 16:55:28 <andreasn> I'll post ideas on the bug about it 16:55:30 <puiterwijk> andreasn: I think I would agree with it being in the hostname dialog 16:55:32 <stefw> host name shouldn't change 16:55:35 <stefw> once server is setup 16:55:41 <stefw> so i think it belongs in the avatar dialog 16:55:44 <stefw> not with the host name 16:55:51 <stefw> the host name should go into initial setup 16:56:04 <mvollmer> the pretty name might change 16:56:08 <stefw> true 16:56:12 <stefw> i guess all those should be together 16:56:13 <mvollmer> it's like the color, in a way 16:56:17 <stefw> pretty name, color, avatar 16:56:19 <puiterwijk> and I think display name and avatar belong together 16:56:20 <mvollmer> yeah 16:56:33 <andreasn> so hostname, yes, that is more dangerous to change, but would you change the host image more than once? 16:56:42 <andreasn> maybe that is also initial setup material 16:56:58 <puiterwijk> andreasn: maybe if you add another role to a server or something. I'd say you change color easier than the actual machine server name 16:57:12 <andreasn> could be 16:57:27 <andreasn> we have nothing at all for Roles right now 16:57:44 <puiterwijk> with "role" I meant configuration in this case :) 16:57:47 <github> [cockpit] mvollmer closed pull request #1417: C: Location API (master...location-api) http://git.io/FMlN9A 16:57:55 <andreasn> oh, I see 16:57:57 <andreasn> yeah 16:58:29 <puiterwijk> like I have a mail server and I add DNS to it. then I might want to change the way it's shown 16:59:27 <puiterwijk> #agreed Display name, host color and host avatar modified in the same dialog 16:59:39 <andreasn> right, because you might have called it "Mailserver" before with a image of a letter or something 16:59:45 <andreasn> so yeah 16:59:56 <andreasn> lets talk more about it in the bug 17:00:02 <andreasn> bug...err...issue 17:00:05 <puiterwijk> sure 17:00:08 <puiterwijk> #topic Blockers for porting next page into a package 17:00:37 <andreasn> https://github.com/cockpit-project/cockpit/issues/1415 17:01:43 <puiterwijk> stefw: ^ 17:01:52 <stefw> mvollmer, so lets say we wanted to port networking 17:01:54 <stefw> any further blockers 17:02:01 <stefw> once the location-api is in? 17:02:14 <mvollmer> let me think... 17:02:24 <mvollmer> plots might be a problem 17:02:32 <stefw> hmmm, true 17:02:33 <mvollmer> or require some reworking 17:02:42 <stefw> yes, interesting 17:02:54 <stefw> i imagine they would go into a another javascript file in the base package? 17:02:56 <mvollmer> there is not super much value in cockpit-plot 17:03:25 <jscotka> do you think something like "traceroute" map of connected machines in cockpit? 17:04:11 <mvollmer> stefw, I would consider starting the plot support from scratch. 17:04:22 <stefw> is that a lot of work? 17:04:24 <mvollmer> maybe more modular 17:04:32 <mvollmer> no, I don't think so. 17:04:35 <stefw> cool 17:04:35 <mvollmer> a day or so. 17:05:15 <mvollmer> for the dashboard we have to combine multiple ResourceMonitor proxies into one plot. 17:05:34 <mvollmer> so I wrote that code from scratch directly with flot. 17:05:54 <mvollmer> requires some thinking about indices, but it's quite straightforward in the end. 17:06:32 <stefw> yes, i imagine it would be different 17:06:35 <stefw> we could port the journal without that, right? 17:06:38 <mvollmer> so I'd say we should have something that turns a Resource Monitor into a life sample array, and some way to specify default options. 17:06:49 <stefw> and i guess user accounts? 17:06:54 <mvollmer> yes 17:07:12 <mvollmer> for user accounts, i would like to stop using cockpitd, if possible. 17:07:20 <stefw> yes, that would be nice 17:07:24 <stefw> we need file monitors for that, i think 17:07:30 <stefw> but that shouldn't be too hard 17:07:31 <mvollmer> yeah 17:07:45 <stefw> right now we pummel docker with polling 17:07:46 <stefw> i think file monitor should also fix that 17:07:50 <mvollmer> is that something for the bridge? 17:07:54 <stefw> yes, i think so 17:08:05 <stefw> getting file contents, and monitoring files 17:08:08 <mvollmer> how would a file monitor help with docker? 17:08:18 <stefw> we can monitor files in /var/lib/docker and be aware of when it changes 17:08:21 <stefw> certain files 17:08:27 <mvollmer> hmm, right 17:09:10 <mvollmer> so, journal? 17:09:20 <stefw> yup 17:09:21 <stefw> i can work on that 17:09:24 <mvollmer> storage? 17:09:33 <mvollmer> but that should also be ported away from cockpitd. 17:09:46 <mvollmer> and get a nice model ala networking 17:10:21 <mvollmer> stefw, you had #server pretty much ported, no? 17:11:01 <stefw> yes 17:11:08 <stefw> yeah, but it's changed a lot 17:11:11 <stefw> it was really easy though 17:11:14 <stefw> i can do it again 17:11:24 <mvollmer> stefw, also, where do you see the multi-dashboard? in an iframe or as a "shell builtin"? 17:12:04 <stefw> i think the question is where does the server shell go 17:12:05 <stefw> does it get loaded from the server 17:12:16 <mvollmer> stefw, for #server, we should port the realmd stuff away from cockpitd 17:12:17 <stefw> or is it the same for all servers 17:12:21 <stefw> mvollmer, true 17:12:34 <stefw> mvollmer, i think we should discuss that later, perhaps 17:12:58 <mvollmer> yeah, let's wrap up. 17:13:10 <mvollmer> road map check? 17:13:13 <puiterwijk> still one more subject on my list 17:13:15 <puiterwijk> #topic Updating the website 17:13:24 <mvollmer> right 17:13:27 <stefw> once we have more of the various components in place, we can make a better decision on how the server-shell/dashboard should fall in and whether we think that the server shell would ever load differently from multiple servers 17:13:27 <stefw> ie: when you go from one server to another 17:13:35 <stefw> we have a guide now 17:13:41 <stefw> http://files.cockpit-project.org/guide/latest/ 17:13:42 <stefw> and a wiki 17:13:56 <stefw> should we add a Documentation and Wiki links to our website? 17:14:06 <stefw> our website looks quite dead right now 17:14:12 <stefw> that is 17:14:13 <andreasn> yeah, good idea 17:14:15 <stefw> cockpit-project.org 17:14:31 <puiterwijk> yeah 17:14:33 <andreasn> and more screenshots and screencastsa 17:14:38 <andreasn> screencasts 17:15:02 <puiterwijk> Maybe it's an idea to also submit the "What changed in Cockpit last week" to the website as a blog post-ish, so that people can see the website is still being updated and it's being worked on? 17:15:24 <puiterwijk> (github pages supports jekyll, so that should be pretty easy to do) 17:15:29 <stefw> we would need some sorta blogging there 17:15:30 <stefw> i've been thinking about doing a series of articles about cockpit 17:15:38 <stefw> and so yeah, maybe we could post them there 17:15:38 <andreasn> like just the commits? 17:16:11 <puiterwijk> andreasn: well, raw commits is a bit too much I guess 17:16:19 <puiterwijk> but the weekly "What changeD" posts are perfect, I'd guess 17:16:40 <puiterwijk> and as said, github pages supports jekyll, so we can use that for blogging 17:17:53 <stefw> no, more like tutorials, examples, 17:17:53 <stefw> discussion of a new feature 17:17:53 <stefw> how to do X with cockpit 17:17:54 <stefw> etc. 17:17:54 <stefw> videos 17:17:55 <github> [cockpit] mvollmer closed pull request #1420: D: Load external pages from target host (master...packages-terminal-from-host) http://git.io/I2eRXQ 17:18:13 <puiterwijk> stefw: ah, right. so more "human"-written posts? 17:18:14 <andreasn> stefw: sounds good 17:18:24 <stefw> yeah i think so 17:18:31 <puiterwijk> yeah, that sounds good as well 17:19:00 <puiterwijk> I mostly mentioned the "What changed" posts as then you'd be sure to always have a reason to post, rather than a few posts now and then nothing 17:19:13 <jscotka> sounds good. It will be also good for testing. 17:19:45 <jscotka> ideally with some importance of the issue. 17:20:07 <andreasn> I don't think we would be able to keep up one post for every week 17:20:29 <puiterwijk> andreasn: well, that's why I mentioned that "What changed", because we already write those, so just posting them there is easy 17:21:11 <puiterwijk> anyway, shall we move on? or more website stuff? 17:22:08 <andreasn> I can post a mockup for a structure for all new content, because I don't think the current layout is good for that stuff 17:22:17 <andreasn> for the website 17:22:18 <puiterwijk> andreasn: yeah, that sounds good 17:22:33 <puiterwijk> #action andreasn to make a mockup for new website for more stuff 17:22:34 <stefw> andreasn, maybe a list of links to stuff hosted elsewhere would be good enough 17:22:44 <stefw> because then we can use whatever format works best 17:22:53 <stefw> link to youtube, our blogs, etc.. 17:23:05 <stefw> and it's not so much work on remaking cockpit-project.org 17:23:24 <andreasn> true 17:24:28 <andreasn> I wanted to clean up at some point anyway. I want to create a proposal at least, and then we can decide 17:25:37 <puiterwijk> okay. let's do that 17:25:43 <puiterwijk> #topic Roadmap check 17:25:55 <jscotka> I have to go. Bye 17:26:08 <stefw> o/ 17:26:23 <andreasn> later! 17:27:07 <puiterwijk> okay, so who's up for roadmap updating? 17:27:18 <andreasn> so, for the roadmap, one thing that is not on there, but that we touched upon earlier is Initial Setup 17:27:29 <andreasn> I guess that is "within 2 years" 17:27:59 <andreasn> there is some stuff in the wiki about that already I think 17:29:03 <puiterwijk> okay. any other updates? 17:29:06 <puiterwijk> stefw, mvollmer? 17:29:27 <stefw> i don't think so 17:29:40 <puiterwijk> okay. then let's go to the last part 17:29:43 <puiterwijk> #topic Open Floor 17:30:02 <puiterwijk> so I wanted to bring up at least one thing here: the meeting time :-) 17:30:36 <puiterwijk> so far, in the emails, we've set them to 15:00 UTC. but seems you meant 17:00 Central European time. What do we put it on? 17:31:04 <andreasn> oh, right, daylight saving 17:31:04 <stefw> CET time, most of us are here 17:31:24 <puiterwijk> stefw: okay. so 17:00 CET? 17:31:29 <stefw> yes, i think so 17:31:38 <andreasn> yeah 17:31:53 <puiterwijk> #info Meeting time agreed on 17:00 CET, to follow timezones in Central Europe 17:32:00 <puiterwijk> I'll update my meeting minutes email with the new time 17:32:14 <puiterwijk> anyone else got anything? 17:32:15 <andreasn> thanks! 17:32:18 <andreasn> nope 17:32:30 <puiterwijk> if nothing else, I'm closing in a minute 17:33:30 <puiterwijk> Okay, thanks all for attending the meeting 17:33:32 <puiterwijk> #endmeeting