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