13:01:55 <mvollmer> #startmeeting
13:01:56 <zodbot> Meeting started Mon Jun 29 13:01:55 2015 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:02 <mvollmer> .hello mvo
13:02:03 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:02:07 <stefw> .hello stefw
13:02:10 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
13:02:10 <Shad0w_Crux> .hello tengland
13:02:12 <zodbot> Shad0w_Crux: tengland 'Turner England Jr' <turner.england@gmail.com>
13:02:55 <mvollmer> #topic Agenda
13:03:00 <dperpeet> .hello dperpeet
13:03:03 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com>
13:03:05 <stefw> * Certificate generation fixes
13:03:09 <stefw> * Announcing compatibility issues
13:03:14 <stefw> * SSH key authentication UX
13:03:17 <stefw> * Fedora 23 jQuery change
13:03:39 <dperpeet> * journal
13:04:17 <mvollmer> * testing of master
13:04:33 <mvollmer> should be enough :-)
13:04:48 <mvollmer> #topic Certificate generation fixes
13:04:59 <stefw> so while we're dealing with compatibility fixes ...
13:05:09 <stefw> there's one more that prevents use of our generated certificates on older versions of firefox (at least)
13:05:23 <stefw> https://github.com/cockpit-project/cockpit/issues/2423
13:05:35 <stefw> this has to do with the fix we were forced to do for latest versions of firefox (where it would hang)
13:05:54 <stefw> newer firefoxes hang when they see too many certificates with CN=localhost and CA:true
13:06:03 <stefw> well really any identical CN over and over
13:06:18 <stefw> and older versions of firefox refuse to connect when the self-signed certificate has CA:false
13:06:31 <stefw> so we probably have to generate our own CA, and then make a certificate signed by that
13:06:35 <stefw> instead of using self-signed directly
13:06:54 <mvollmer> right
13:06:57 <stefw> as an aside, all of this makes me think we should use gnutls to generate the certs (since that's what we use for TLS)
13:07:03 <stefw> rather than depending on both gnutls and openssl
13:07:24 <mvollmer> does anyone else do this?  self-signed CA?
13:08:04 <andreasn> sorry for being late
13:08:08 <stefw> i think many do
13:08:11 <andreasn> .hello andreasn
13:08:12 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:08:12 <dperpeet> are we violating any sound principles?
13:08:13 <stefw> but they all prompt for a name
13:08:22 <stefw> the code we currently have was reviewed by NSS maintaniers
13:08:25 <stefw> well one of them
13:08:34 <stefw> but obviously they didn't consider older versions of NSS when they did so
13:08:52 <stefw> i wouldn't use both "x509" and "sound principles" in the same sentence
13:09:05 <mvollmer> :-)
13:09:06 <dperpeet> :)
13:09:41 <dperpeet> what I was getting at: do we need to fix our behavior or do we need a workaround for something that's weird in firefox?
13:10:43 <stefw> well self-signed certs are pretty gray area
13:10:48 <stefw> a lot of it is really a matter of opinion
13:10:57 <stefw> i'd say the real fix is to further integrate with IPA for cert generation
13:11:10 <stefw> but that would come after basic non-local users are working
13:11:24 <dperpeet> but if we can reduce our dependencies and make the certificate generation more compatible, that's good
13:11:24 <stefw> so it's a ways off
13:11:25 <stefw> for now this affects lots of pepole
13:11:25 <stefw> they just can't use cockpit
13:12:14 <dperpeet> is there a way to help users see a sane error message?
13:12:25 <dperpeet> http fallback with notice?
13:12:45 <dperpeet> I'm not familiar enough with browser mechanics to know if that could work
13:13:01 <stefw> no
13:13:06 <dperpeet> it seems like we don't have many choices if the browser decides it's unsafe to connect
13:13:10 <stefw> right
13:13:51 <dperpeet> then let's go for the generated CA
13:14:13 <stefw> alright ... unfortunately we can't use sgallagh's implementation, due to deps
13:14:16 <stefw> but i'll try to use it as a guide
13:14:26 <stefw> we also don't have the same needs as openlmi
13:14:34 <stefw> since they tried to import it into the local trusted store
13:14:55 <sgallagh> /me looks up
13:14:59 <stefw> #info Will rewrite CA generation to have a self-signed CA and a signed certificate from that to use in cockpit-ws
13:15:27 <sgallagh> stefw: What are the problematic deps?
13:15:41 <stefw> we want to use just one crypto library
13:15:44 <stefw> and not "collect the whole set"
13:15:50 <sgallagh> stefw: OK, which one are you using?
13:15:54 <stefw> gnutls
13:15:55 <stefw> via glib
13:16:28 <stefw> mvollmer, next topic?
13:16:33 <mvollmer> ok
13:16:43 <mvollmer> #topic Announcing compatibility issues
13:17:00 <stefw> so ... the question then becomes
13:17:15 <stefw> do we wait for above fix before announcing all our compatibility fixes?
13:17:19 <stefw> or just go for it now
13:17:21 <stefw> so far we have:
13:17:24 <stefw> 1. docker
13:17:33 <stefw> 2. capabilities in bridge
13:17:39 <stefw> 3. dbus not ignoring unknown messages
13:17:47 <stefw> 4. soon the self-signed cert will be fixed
13:18:24 <dperpeet> I don't believe waiting serves any good purpose
13:18:50 <dperpeet> the question is whether it'd be worth keeping a wiki page for such fixes
13:18:59 <dperpeet> and linking it from the landing page
13:19:14 <stefw> hmmm not sure
13:19:17 <dperpeet> or if there aren't enough users to warrant the effort
13:19:19 <stefw> i think we should just update cockpit-project.org
13:19:30 <stefw> and say versions later than X have no problems talking to each other.
13:19:37 <stefw> prior to that support is patchy
13:19:38 <stefw> ?
13:19:43 <dperpeet> sounds good
13:19:56 <dperpeet> less work and more informative than having to look at a whole page of version numbers
13:20:02 <stefw> right
13:20:25 <andreasn> under the Multi-server section in the website?
13:20:32 <mvollmer> another angle might be to put a message into Cockpit itself: "You should update Cockpit"
13:20:43 <mvollmer> but we need the backends for that
13:20:50 <mvollmer> to detect new versions
13:21:07 <dperpeet> but for that cockpit would need to connect to our server
13:21:10 <stefw> mvollmer, yes, not a bad idea ... but some of the errors are unpredictable
13:21:13 <mvollmer> of course, this is a generic feature
13:21:18 <stefw> for example a "protocol-error" in some cases
13:21:25 <dperpeet> something like that should be opt-in
13:21:38 <stefw> i don't think we should overcomplicate this
13:21:48 <stefw> andreasn, what multi-server section in the website?
13:21:51 <mvollmer> i was thinking that the bridge figures out in a OS-specific way whether there is an update for itself.
13:21:54 <dperpeet> and it sounds like an optional future feature
13:22:02 <andreasn> stefw: under the 3rd screenshot
13:22:03 <dperpeet> hm
13:22:06 <mvollmer> but that blends into the "you have updates" features
13:22:20 <dperpeet> yes, we haven't really laid all the groundwork for updates I think
13:22:22 <andreasn> stefw: we can figure out the details on where on the website after the meeting
13:22:25 <mvollmer> anyway, maybe this can help in the longer term.
13:22:31 <stefw> ok, andreasn, it could go in the docs
13:22:34 <stefw> and then link it from the website
13:22:39 <andreasn> sure
13:22:41 <dperpeet> it's a good idea, once cockpit is good with updates
13:22:53 <dperpeet> should be considered during design, andreasn
13:23:24 <andreasn> right
13:24:06 <stefw> petervo, what are the updates that need to be pushed out for the compatibility fixes to take?
13:24:27 <stefw> i guess there's this: https://admin.fedoraproject.org/updates/FEDORA-2015-10740/cockpit-0.62-1.fc22?_csrf_token=53967988c9a359a2794cc4f8487da31509d07f0a
13:24:36 <petervo> the capabilities and the cockpit js change
13:25:09 <stefw> this is a start: https://admin.fedoraproject.org/updates/FEDORA-2015-10740/cockpit-0.62-1.fc22
13:25:19 <petervo> yes
13:25:51 <stefw> lets give karma to that for starters
13:27:47 <stefw> ok, next topic?
13:28:23 <andreasn> yup
13:29:01 <andreasn> mvollmer: ?
13:29:14 <mvollmer> yup
13:29:30 <mvollmer> #topic SSH key authentication UX
13:29:56 <stefw> petervo is working on SSH key authentication
13:30:14 <stefw> so that you can use ssh keys in the account of the first s erver you connect to then connect to other servers
13:30:25 <stefw> one use case is connecting to localhost
13:30:31 <andreasn> what does this mean exactly? Placing a .pub key and avoid passwords?
13:30:46 <stefw> so it means placing id_xxx and id_xxx.pub
13:30:48 <stefw> in ~/.ssh
13:30:52 <stefw> on the first serevr you connect to
13:30:59 <stefw> encrypted with your login password, or no password
13:31:10 <andreasn> ah, right
13:31:15 <stefw> i'm wondering if we can list these or help people with them in the "Administrator Accounts" stuff
13:31:19 <stefw> at least for your own account
13:31:33 <andreasn> there is some good prior art with github
13:31:35 <mvollmer> can we use existing keys as well?
13:31:36 <andreasn> 's keys here
13:31:42 <stefw> yes existing keys would be supported
13:31:49 <stefw> as long as they have the right password or no password
13:31:57 <stefw> or the user changes it
13:32:00 <mvollmer> right makes sense
13:32:14 <dperpeet> filesystem based or ssh-agent, too?
13:32:20 <stefw> ssh-agent based
13:32:25 <stefw> we start the ssh-agent in the session
13:32:29 <stefw> peter has a pull request that's WIP
13:32:34 <stefw> about half done, i think
13:32:43 <stefw> petervo, could you start a: https://github.com/cockpit-project/cockpit/wiki/New-Features
13:32:44 <stefw> ?
13:32:51 <stefw> and then we can contribute and fill it out?
13:32:51 <petervo> sure
13:33:02 <stefw> andreasn, are you interested in working on the UX?
13:33:07 <andreasn> stefw: totally
13:33:39 <stefw> #info petervo, andreasn, will start up a feature page for key based SSH UX
13:34:13 <stefw> maybe the actual work can be a separate pull request?
13:34:23 <stefw> but probably shouldn't be considered done, until normal people can actually use it
13:34:40 <stefw> big use case is cloud OS's like Atomic Host that usually get deployed without password auth
13:34:55 <stefw> anyway, that's all i wanted to say on that.
13:35:06 <andreasn> good stuff
13:36:03 <mvollmer> next?
13:36:10 <andreasn> sure
13:36:19 <mvollmer> #topic Fedora 23 jQuery chang
13:36:31 <stefw> there's a Fedora 23 change suggesting that everyone uses one copy of jQuery
13:36:36 <stefw> this is problematic for us
13:36:42 <stefw> not only because we gzip and bundle stuff
13:36:59 <andreasn> doesn't every project that use patternfly also use jquery?
13:37:01 <stefw> but also because jQuery ends up as part of our public API, and it will be hard to support people upstream if distributions randomly change out our deps
13:37:04 <stefw> andreasn, yes
13:37:12 <stefw> sgallagh, ^^ do you have anything to say about this?
13:37:39 <mvollmer> i think the idea is not to "randomly" change it, no?
13:38:00 <stefw> well if every distro did this
13:38:03 <stefw> it would *feel* pretty random
13:38:05 <sgallagh> stefw: We
13:38:17 <sgallagh> 're basically back to the old bundled vs. system lib argument
13:38:22 <dperpeet> I'm not sure if we'd really have a problem since we don't use anything really version specific in jquery, do we?
13:38:36 <dperpeet> from what I've seen we pretty much stick to the solid basics
13:38:38 <stefw> how do we know that?
13:38:59 <dperpeet> the problem I see is with diverging loading paths for fedora and the rest
13:39:01 <stefw> sgallagh, right, which is getting pretty tried in a container world
13:39:09 <dperpeet> it spreads our testing tree further
13:39:25 <stefw> loading paths are far from the issue. we wouldn't even be able to load the files they have in place
13:39:38 <dperpeet> I mean we would have to do things differently
13:39:49 <dperpeet> what speaks against just bundling anyway?
13:39:57 <dperpeet> would it be mandatory?
13:40:04 <dperpeet> to use that one version
13:40:13 <mvollmer> sgallagh, now we get jQuery via bower, would it be enough to get it via a rpm at build time?
13:40:29 <stefw> anyway this is not set in stone
13:40:33 <sgallagh> dperpeet: Basically, yes. It's a request to change the packaging guidelines to drop the bundling exception now that there's a way to use a central copy
13:40:33 <stefw> it's up to us to speak up against this
13:40:35 <stefw> if it ruins Cockpit
13:40:37 <mvollmer> or is the idea to not have any jQuery inside the cockpit binray rpms?
13:40:47 <stefw> and what about every other dependency from github?
13:41:06 <stefw> this is a proposed change
13:41:11 <sgallagh> It'll be discussed at FESCo this week, but as of right now I'm against making this mandatory before F24. (I have no problem with carrying a library that people can try)
13:41:19 <stefw> so my point is that we should oppose it in its current form
13:42:03 <stefw> Fedora should do its own full stack CI and support before changing upstream apps like this
13:42:24 <stefw> because right after jquery comes angularjs and other stuff
13:42:26 <dperpeet> I don't like the idea of jquery versions just changing on us, without control
13:42:41 <dperpeet> it's difficult enough to support the different flavors that we do test
13:42:45 <stefw> yes, jquery may be the most stable javascript library out there but even it is problematic in this context
13:42:55 <stefw> it all goes down hill from there
13:43:01 <stefw> especially things like patternfly
13:43:03 <stefw> or angularjs
13:43:07 <stefw> term.js
13:43:07 <stefw> etc.
13:43:30 <andreasn> a certain version of patternfly relies on a certain version of jquery, right?
13:43:34 <stefw> right
13:43:36 <dperpeet> hubbot/f22/x86-64/jquery1.1/patternfly1.4 doesn't look good :)
13:44:02 <stefw> but if there was a mandated central version of patternfly
13:44:20 <stefw> then fedora can start hiring tech support staff
13:44:23 <stefw> :D
13:44:55 <andreasn> I can send a mail about the fedora change to the patternfly list
13:45:22 <andreasn> because it would affect them quite a bit I would imagine
13:45:35 <stefw> sgallagh, so if this sets a precedent
13:45:44 <stefw> as in, will go beyond jquery
13:45:55 <stefw> then Fedora becomes a really really bad place to package your software
13:46:02 <stefw> well web applications
13:46:21 <stefw> if the change proposal is changed significantly (ie: to include CI of the apps) then perhaps jQuery could be manageable
13:46:26 <stefw> anything beyond that just plain isn't
13:46:37 <stefw> if anyone wants to respond to the proposal: https://lists.fedoraproject.org/pipermail/devel/2015-June/211698.html
13:47:08 <sgallagh> stefw: Yeah, I'm with you. As I said, I plan to oppose any attempt to make this mandatory in F23.
13:47:28 <mvollmer> what are the reasons for the change anyway?
13:47:40 <stefw> sgallagh, alright, let us know if you need any further feedback or help
13:48:12 <andreasn> mvollmer: better potential protection against security holes in jquery
13:48:20 <mvollmer> ahh, found the "benefit" section.
13:49:36 <mvollmer> and the fix should be roll-out-able by simply updating the jQuery rpm?  Or is it ok to recompile?
13:49:57 <stefw> so we would recompile our deps on the fly?
13:50:05 <mvollmer> no, not on the fly
13:50:05 <sgallagh> mvollmer: As with other libs, I think the intent is that the one package should be updated only
13:50:06 <stefw> like how would we get back to our jquery.min.js.gz?
13:50:17 <sgallagh> If all the deps need updating, then it's functionally identical to bundling
13:50:20 <stefw> our bundle of jquery which includes about 8 javascript modules
13:50:21 <sgallagh> except without the control
13:50:38 <mvollmer> jquery update -> cockpit update -> logout/login -> user has fix
13:50:39 <stefw> except it's not
13:50:39 <stefw> see above ^^
13:50:45 <stefw> how do you update part of a minified javascript gzipped file?
13:50:52 <stefw> without recompiling?
13:51:01 <sgallagh> stefw: I think we're agreeing, but I phrased it poorly.
13:51:08 <stefw> oh sorry
13:51:17 <stefw> alright, i'm done on this topic i guess.
13:51:30 <stefw> we only have ten more minutes
13:51:32 <mvollmer> right
13:51:59 <mvollmer> personally, I think I wouldn't balk at getting jQuery from Fedora instead of bower at build time.
13:52:13 <mvollmer> getting it at runtime is a whole different story.
13:52:14 <stefw> if we can request a specific version from Fedora, yes
13:52:20 <stefw> build-time wouldn't be a problem
13:52:34 <stefw> and they can keep the specific versions all patched
13:52:43 <stefw> it would be a crazy amount of work for Fedora
13:52:53 <mvollmer> so Fedora should prepare itself to recompile reverse build-depebds when updating jQuery
13:53:01 <dperpeet> and the package would have to include the minified, gzipped file
13:53:27 <mvollmer> well, gzipped is not necessary,
13:53:28 <stefw> dperpeet, browsers don't support concatenating gzipped files
13:53:30 <stefw> even though the spec does
13:53:45 <stefw> dperpeet, we have more than just jQuery in our jquery.min.js.gz
13:53:50 <mvollmer> next? :-)
13:53:51 <stefw> it's a bundle of jquery and jquery plugins
13:53:52 <dperpeet> true
13:53:53 <stefw> next
13:54:08 <mvollmer> #topic journal
13:54:24 <dperpeet> so, I've been working on the new journal layout https://trello.com/c/if88ORZv/73-new-journal-look
13:54:37 <dperpeet> the templates are pretty finished, after some iteration with andreasn last week
13:54:49 <dperpeet> note to andreasn: they now work entirely without float elements
13:54:54 <stefw> wow cool
13:55:01 <stefw> are you using bootstrap-selectize for the search thingy?
13:55:05 <stefw> because it makes that *really* really easy
13:55:12 <dperpeet> not yet, I'm working on that section
13:55:13 <stefw> and the openshift guys want us to use it on the kubernetes page as well
13:55:24 <dperpeet> thanks for the pointer to openshift, I'll look at that
13:55:43 <stefw> dperpeet, http://brianreavis.github.io/selectize.js/
13:55:46 <dperpeet> the search has two components
13:55:48 <stefw> that's what they're using
13:55:53 <dperpeet> one is server-side via journalctl parameters
13:56:04 <dperpeet> where we also get a list of tags we can set
13:56:18 <dperpeet> those are basically the "columns" in the data we can see
13:56:24 <dperpeet> when we look at journal details
13:56:32 <dperpeet> the other part is wildcard searching client-side
13:56:49 <dperpeet> but that aside, there is a larger issue
13:57:02 <dperpeet> regarding preparation for multi-host journals
13:57:16 <dperpeet> if we have multiple hosts, do we just add a host column?
13:57:27 <dperpeet> or do we want to do that differently, somehow?
13:57:39 <andreasn> I can't remember what I sketched out regarding that
13:57:42 <dperpeet> I believe such an "interleaved" mode would be best for troubleshooting
13:57:45 <andreasn> let me see if I can find something
13:57:49 <dperpeet> I didn't see anything for multihost
13:58:03 <stefw> right, we talked about making this a dashboard across all the servers you have
13:58:09 <stefw> or at least moving it there when you have more than 1 server?
13:58:30 <stefw> should we talk about this in the Feature page?
13:58:35 <stefw> there is a Feature page right?
13:58:37 <andreasn> yeah, that would be good
13:59:06 <dperpeet> I would have to look, I've been using trello, issues and the mockups
13:59:11 <stefw> dperpeet, i don't see a feature page here: https://github.com/cockpit-project/cockpit/wiki/Features
13:59:19 <stefw> if we have one, we should probably link it there
13:59:20 <andreasn> no, we don't have any feature page. I can create one
13:59:23 <stefw> oh ok
13:59:29 <dperpeet> yeah, I think merging the current design into a feature page would be good
13:59:33 <stefw> because that'll help answer a lot of questions
13:59:38 <dperpeet> andreasn, want me to start one and we iterate?
13:59:39 <stefw> such as how this is supposed to be used
13:59:39 <stefw> etc.
13:59:43 <andreasn> dperpeet: sure
13:59:55 <dperpeet> ok, then we can discuss things there
13:59:58 <andreasn> sure
13:59:59 <stefw> dperpeet, the ideas you listed aren't bad
14:00:08 <stefw> but better to hash them out on a feature page with the use cases nearby
14:00:20 <dperpeet> I also switched to mustache templates
14:00:28 <stefw> any performance data?
14:00:33 <dperpeet> I performed some js performance tests
14:00:33 <stefw> and partial loading?
14:00:38 <dperpeet> and they were good
14:00:51 <dperpeet> especially considering that mustache does proper html escaping
14:01:06 <dperpeet> which would relieve a few security headaches in that part of cockpit
14:01:09 <stefw> right. and i guess you just run it through mustache multiple times to do partial loading?
14:01:20 <dperpeet> I have a template for a log-line
14:01:22 <stefw> because that's a key feature of the page, obviously
14:01:24 <stefw> ah ok
14:01:25 <dperpeet> and the template is preparsed
14:01:27 <stefw> cool
14:01:39 <dperpeet> and there's a template for a "section" (i.e. day)
14:01:57 <dperpeet> tests showed performance losses of 2-5%
14:02:03 <dperpeet> string concat vs mustache
14:02:22 <dperpeet> totally acceptable when considering the cleaner code
14:02:43 <dperpeet> I can tweak the loading if necessary as well
14:02:49 <dperpeet> but we'll discuss on the feature page
14:02:52 <dperpeet> end of topic
14:03:30 <dperpeet> #info dperpeet, andreasn will start feature page in wiki for new journal layout
14:04:08 <mvollmer> #topic master testing
14:04:25 <mvollmer> ok, only briefly, I guess
14:04:36 <mvollmer> so master testing right now is pretty uninteresting
14:04:44 <mvollmer> it just retests the most recent PR
14:04:59 <dperpeet> but we had a discussion to make it more interesting
14:05:03 <mvollmer> the idea has been for some time that we do more interesting master testing
14:05:18 <mvollmer> so I propose this:
14:05:30 <mvollmer> ohh, pr has been merged. :-)
14:05:45 <mvollmer> https://github.com/cockpit-project/cockpit/pull/2445
14:05:55 <mvollmer> no selinux policy overwrite
14:06:02 <mvollmer> always latest packages from the distro
14:06:17 <mvollmer> downside is that master testing takes a lot longer
14:06:31 <mvollmer> also we are going to test f22-updates-testing separately.
14:06:55 <dperpeet> the idea is that master should be checked like that daily
14:07:07 <mvollmer> so we have rhel-7, f22, f-rawhide, f22-plus-updates-testing, f22-atomic
14:07:21 <dperpeet> since our pull requests are rebased on master anyway, when they are tested before merging
14:07:23 <mvollmer> and we shouldn't shy away from testing more
14:08:13 <mvollmer> so, should we throttle master checking to once per day for each config before enabling --clean, or after?
14:08:41 <dperpeet> before
14:08:55 <dperpeet> I can fix the priority system also, that shouldn't take more than half a day
14:09:00 <mvollmer> we should add centos, arm, maybe debian just for kicks.
14:09:11 <mvollmer> ok, great.
14:09:27 <dperpeet> that way our pull requests don't get railroaded my long master checks
14:09:30 <dperpeet> *by
14:09:57 <mvollmer> it might still happen, but that's life
14:10:17 <mvollmer> i guess one test run will take about 30 minutes
14:10:24 <mvollmer> or less
14:11:44 <mvollmer> #action dperpeet make sure that master testing doesnt happen too often
14:11:55 <mvollmer> what about testing only tags?
14:12:00 <mvollmer> i.e., releases?
14:12:12 <mvollmer> that would be a bit backwards, no?
14:12:23 <mvollmer> better to test before release
14:13:14 <mvollmer> anyway, the improved image creation machinery is almost fun to use.
14:13:29 <mvollmer> making the stock images was quite easy, for example
14:13:43 <mvollmer> ok, eot?
14:13:52 <dperpeet> yes, the change was good :)
14:14:13 <mvollmer> we are accumulating a lot of images already
14:14:18 <mvollmer> let's see how the gc works.
14:14:28 <mvollmer> f22 is up to version 8.
14:14:39 <mvollmer> but it's good to make that visible
14:14:56 <mvollmer> ok
14:14:59 <dperpeet> maybe we should show the version on hubbot status
14:15:08 <dperpeet> we can discuss that separately
14:15:15 <mvollmer> yeah, why not
14:15:23 <mvollmer> but there are many versions per pr
14:15:53 <mvollmer> let's close
14:15:57 <mvollmer> #topic open floor
14:17:17 <mvollmer> someone?
14:17:23 <mvollmer> ok
14:17:26 <mvollmer> #endmeeting