fedora_coreos_meeting
LOGS
16:29:22 <dustymabe> #startmeeting fedora_coreos_meeting
16:29:22 <zodbot> Meeting started Wed Apr  7 16:29:22 2021 UTC.
16:29:22 <zodbot> This meeting is logged and archived in a public location.
16:29:22 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:29:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:29:22 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:29:26 <dustymabe> #topic roll call
16:29:28 <bgilbert> .hello2
16:29:29 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:29:29 <dustymabe> .hello2
16:29:31 <cyberpear> .hi
16:29:31 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:29:37 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:30:02 <jdoss> .hello2
16:30:03 <dustymabe> oh nice.. is .hi an alias for .hello2 ?
16:30:15 <jlebon> .hello2
16:30:16 <zodbot> jdoss: jdoss 'Joe Doss' <joe@solidadmin.com>
16:30:19 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:30:34 <jaimelm> ./hello jaimelm
16:30:42 <lorbus> .hello2
16:30:43 <jaimelm> .hello jaimelm
16:30:45 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:30:48 <zodbot> jaimelm: jaimelm 'Jaime Magiera' <jaimelm@umich.edu>
16:31:52 <dustymabe> #chair bgilbert cyberpear jdoss jlebon jaimelm lorbus
16:31:52 <zodbot> Current chairs: bgilbert cyberpear dustymabe jaimelm jdoss jlebon lorbus
16:32:05 <travier> .hello siosm
16:32:06 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:32:19 <dustymabe> #chair travier
16:32:19 <zodbot> Current chairs: bgilbert cyberpear dustymabe jaimelm jdoss jlebon lorbus travier
16:32:27 <jbrooks> .hello jasonbrooks
16:32:28 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:32:33 <dustymabe> #chair jbrooks
16:32:33 <zodbot> Current chairs: bgilbert cyberpear dustymabe jaimelm jbrooks jdoss jlebon lorbus travier
16:33:12 <dustymabe> #topic Action items from last meeting
16:33:25 <dustymabe> * travier  to summarize outcome in https://github.com/coreos/fedora-coreos-tracker/issues/768
16:33:28 <lucab> .hello2
16:33:29 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:33:31 <dustymabe> * PanGoat to file an issue about FCOS docs discoverability
16:33:35 <dustymabe> #chair lucab
16:33:35 <zodbot> Current chairs: bgilbert cyberpear dustymabe jaimelm jbrooks jdoss jlebon lorbus lucab travier
16:33:38 <walters> .hello2
16:33:39 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:33:44 <dustymabe> #chair walters
16:33:44 <zodbot> Current chairs: bgilbert cyberpear dustymabe jaimelm jbrooks jdoss jlebon lorbus lucab travier walters
16:33:52 <dustymabe> nice crowd today.. good to see everyone here!
16:33:58 <fifofonix> .hello2
16:33:59 <zodbot> fifofonix: fifofonix 'Fifo Phonics' <fifofonix@gmail.com>
16:33:59 * jdoss waves
16:34:06 <dustymabe> #chair fifofonix
16:34:06 <zodbot> Current chairs: bgilbert cyberpear dustymabe fifofonix jaimelm jbrooks jdoss jlebon lorbus lucab travier walters
16:34:36 <dustymabe> travier: update on your action item? Is PanGoat here today?
16:35:04 <cverna> hello o/
16:35:22 <travier> I still have to do mine
16:35:48 <dustymabe> #action travier  to summarize outcome in https://github.com/coreos/fedora-coreos-tracker/issues/768
16:35:50 <travier> PanGoat is jaimelm if I'm not mistaken
16:35:59 <dustymabe> correct :)
16:36:02 <jaimelm> Correct. That's me.
16:36:09 <jaimelm> Yes, it's here... https://github.com/coreos/fedora-coreos-docs/issues/271
16:36:41 <dustymabe> #info PanGoat opened https://github.com/coreos/fedora-coreos-docs/issues/271 to discuss docs discoverability (search)
16:37:17 <dustymabe> #topic podman cp is broken in 33.20210301.3.1
16:37:21 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/771
16:37:38 <jaimelm> I'll be using this nick moving forward. I've put in a cloak request.
16:37:59 <dustymabe> I added the meeting label to this one. We're doing an ad-hoc release for `testing`/`next` to get the new podman and newer openssl
16:38:28 <dustymabe> can track those here: https://github.com/coreos/fedora-coreos-streams/issues/290 https://github.com/coreos/fedora-coreos-streams/issues/291
16:38:53 <dustymabe> any concerns with doing the ad-hoc release for this?
16:39:16 <jdoss> +1 glad it is going out. The volume issues with podman 3.0.1 are pretty painful.
16:39:24 <jaimelm> none. the podman issue needs to be addressed.
16:39:32 <travier> dustymabe: +1
16:40:12 <dustymabe> #info we are planning to do an ad-hoc release to address the podman cp issue and also openssl CVEs
16:40:45 <dustymabe> i'll move to next topic in 30s unless we have further discussion
16:41:19 <dustymabe> #topic cgroups v2 strategy
16:41:22 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/292
16:41:29 <dustymabe> jlebon: want to give us an update here?
16:41:37 <jlebon> yup sure
16:42:19 <jlebon> so next-devel is now on cgroupsv2, which means we're in position for cgroupsv2 in the next release  next week
16:42:32 <jlebon> we have documentation for moving from v1 to v2 and v2 to v1 (thanks travier!)
16:43:04 <jlebon> we've drafted an email to send out re. this change in https://hackmd.io/O4NOJCBNQQWUMBA7v9RHcw
16:43:44 <jlebon> but i think it'd be great if we also pinned down when we want to move testing and stable over so that we can include that as part of the same message
16:44:27 <jdoss> are we treating next as fedora 34 beta until it goes GA?
16:44:46 <jlebon> e.g. let's say... roughly two months from now? releases the week of june 7th
16:44:56 <jlebon> s/roughly//
16:44:58 <dustymabe> jlebon: I think the dates for `testing`/`stable` depend on how the testing goes
16:45:24 <cyberpear> when do we switch testing stream to 34? GA freeze is in effect now for f34
16:45:39 <cyberpear> (I guess it's called Final Freeze)
16:45:58 <jlebon> dustymabe: i guess so, though i'm hoping it should be pretty smooth, especially since it doesn't affect existing nodes.
16:46:10 <jlebon> i think we can have a target and then revise later if needed
16:46:12 * jaimelm adds some language suggestions
16:46:33 <dustymabe> right but the cgroups v2 change is coupled with f34.. there's usually some hiccups that need to be chased down
16:47:18 <dustymabe> I guess I prefer to shy away from actual dates and either link to issues or give generic guidance ("coming month")
16:47:47 <travier> we kind of said we wanted to do that for F34
16:47:52 <dustymabe> cyberpear: we don't have an official policy, ideally we get closer and closer to the GA date
16:47:53 <jdoss> Maybe we should keep 34 in next until Fedora 34 hits GA then move it to Testing in 2 weeks or so after that date.
16:48:15 <jlebon> dustymabe: hmm, generic guidance WFM. and then another email closer to that with an exact date
16:48:40 <jlebon> jdoss: that's more or less the plan :)
16:49:06 <jdoss> It would be nice if we had a policy (or rough guidelines)  on the cadence of FCOS moving between Fedora releases
16:49:17 <jdoss> That way we can set expectations for users and document it on the docs site
16:49:44 <jdoss> AFAIK we don't have that written down.
16:49:45 <travier> If we can do that, it would be great to have F34 in testing for GA so that stable gets it 2 weeks later.
16:49:46 <jlebon> we established some during the last rebase, but i don't think it was moved out of the tracker issue where it was discussed
16:49:59 <dustymabe> yeah, we did discuss it last time..
16:50:45 <jdoss> to be clear, written down for end users out of an issue. I am glad it is already being talked about.
16:50:48 <dustymabe> jdoss: if you want to create an issue and we can write down the output of that somewhere, that works
16:51:00 <jdoss> Yah I'll put my money where my mouth is.
16:51:05 <jlebon> +1
16:51:08 <jaimelm> +1
16:51:48 <dustymabe> in general though, it will be guidance and not absolute guarantees
16:52:09 <bgilbert> in particular, it's more about stability gating than a calendar
16:52:19 <bgilbert> "stability" including "known regressions"
16:52:38 <dustymabe> #info we're planning to switch over `next` to cgroupsv2 in next week's set of releases
16:52:51 <jlebon> so to circle back to cgroupsv2, let's just say "in a few months" in that email for now?
16:53:29 <jdoss> bgilbert: I'd agree with that. Sometimes you have to wait for stuff to get stable.  It would just be nice to communicate expectations to end users on when they should start seeing releases.
16:53:43 <bgilbert> makes sense
16:53:44 <jaimelm> You could even wrap it in estimation: "We're estimating this will happen in the next few months"
16:53:44 <dustymabe> how about we just say something along the lines of "when testing/stable rebase to F34"
16:53:54 <jlebon> jdoss: ideally, users shouldn't care too much about the actual major version :)
16:54:10 <jdoss> In a perfect world ya :D
16:54:16 <travier> maybe we should decouple cgroupsv2 from the rebase to F34
16:54:37 <dustymabe> travier: docker in f33 doesn't support cgroupsv2
16:54:42 <jdoss> Hopefully we don't have a game breaker change like cgroupsv2 in the future.
16:54:50 <travier> I'm not saying doing it earlier
16:55:03 <jlebon> travier: that's what i assumed we were doing
16:55:17 <travier> ok, that was not my understanding, sorry
16:55:43 <dustymabe> jlebon: travier: hmm. clear that up for me?
16:55:58 <jlebon> (travier: or maybe i'm the one who misread :) )
16:56:04 <dustymabe> I thought we were coupling it?
16:56:18 <travier> I was assuming we were going to do cgroupsv2 & F34 switch at the same time
16:56:25 <dustymabe> same ^^
16:56:52 <jlebon> we didn't do that for next, and we don't have to do that for testing/stable
16:57:09 <dustymabe> right, we didn't do that for next, but ideally IMHO we would have
16:57:20 <dustymabe> and I think it is what we should do for `testing`/`next`
16:57:25 <dustymabe> oops
16:57:29 <dustymabe> `testing`/`stable`
16:57:53 <jlebon> i think it goes back to the argument of spreading out changes vs bundling them
16:58:07 <travier> true
16:58:42 <dustymabe> yeah I oscillate on that one quite a bit
16:58:44 <walters> i think it makes sense to do some testing separately but for users we might as well bundle the changes
16:58:44 <travier> last bgilbert asked for a couple of months before cgroups v2 hit stable by default
16:58:52 <travier> last time*
16:59:30 <travier> But I'm not sure we can wait that long for the F34 rebase
16:59:33 <dustymabe> I think we just need to get the information out there to users ASAP
16:59:46 <dustymabe> it will still be some time at this point before the f34 rebase happens in stable
16:59:59 <travier> agree
16:59:59 <dustymabe> at least 4 weeks, if not 6
17:00:00 <bgilbert> I'm in favor of getting the info out immediately, but separating the change from f34
17:00:27 <bgilbert> when we push a bunch of bundled changes at once, it makes trouble tickets more complicated
17:00:36 <fifofonix> I'm appreciating being able to test f34 on next before mixing in cgroups2.  Imagine some would like that opportunity in test.
17:00:45 <jlebon> bgilbert: yeah, i lean towards that as well
17:00:55 <lucab> yup, same
17:01:29 <dustymabe> feels like we've waited so long for cgroupsv2 :)
17:01:38 <dustymabe> can we at least do it in the subsequent release ?
17:02:02 <bgilbert> I think we had previously discussed providing two months notice
17:02:06 <jaimelm> ^^
17:02:32 <jaimelm> several meetings ago it was narrowed down to 2 months.
17:02:34 <bgilbert> it is a breaking change
17:02:41 <jdoss> dustymabe: yah ripping the bandaid off on cgroupsv2 is a doozy.
17:02:47 <dustymabe> bgilbert: but doesn't affect upgrading nodes
17:03:04 <bgilbert> dustymabe: but does affect launches of new nodes in existing deployments
17:03:24 <dustymabe> ok, so let's say 2 months from next week's next release ?
17:03:40 <jlebon> right, any script/app that assumes v1 will break.  how common that is, i'm not sure
17:03:42 <dustymabe> so.. the communication is: "here is where you can test this $now"
17:03:57 <dustymabe> you have two months before new deployments get this new shiny
17:04:41 <dustymabe> is that reasonable?
17:04:49 <jlebon> dustymabe: that's why i threw out the june 7th date earlier :)
17:05:16 <jlebon> so we could say, "we're planning to move over this date, but it might change depending on $reasons"
17:05:30 <jlebon> so they have a concrete date to put in their calendars
17:05:33 <dustymabe> jlebon: would need to be June 14th (2 months from next week's next), right?
17:06:09 <jdoss> So those that want to get new software from F34 have to run Next for two months. Oof.
17:06:12 <jlebon> hmm, i think that's a non-release week, let me check
17:06:25 <bgilbert> jdoss: no, we'd proceed with the f34 rebase
17:06:44 <jlebon> dustymabe: right, either june 7th or june 21st. either WFM
17:06:45 <jdoss> bgilbert: ahhh sorry for the confusion. Thanks.
17:07:16 <dustymabe> jlebon: let's go with June 7th (hopefully we've already moved over stable before then) :)
17:07:24 <dustymabe> to f34, that is
17:07:40 <jlebon> +1
17:07:48 <jaimelm> proposal time?
17:07:50 <dustymabe> ok let me try to summarize
17:07:52 <lucab> put the notice in a forum/discussion post, link to it, then refine the date there (as it can be amended)
17:07:55 <walters> also fine by me
17:08:08 <travier> Should we also announce count me changes at the same time or is that too much for one mail?
17:08:17 <jaimelm> separate
17:08:25 <dustymabe> too much for one email I would say
17:08:28 <travier> ok
17:09:55 <dustymabe> #proposed we will decouple the rebase of the testing and stable streams from the f34 rebase in order to reduce the number of changes in an update. We will also announce the planned changes for cgroupsv2 and give approximately 2 months time before stable gets switched over to cgroupsv2 for newly deployed nodes.
17:10:09 <dustymabe> one sec let me fix that up
17:10:11 <dustymabe> #undo
17:10:11 <zodbot> Removing item from minutes: INFO by dustymabe at 16:52:38 : we're planning to switch over `next` to cgroupsv2 in next week's set of releases
17:10:41 <dustymabe> #proposed we will decouple the move to cgroupsv2 for newly deployed nodes from the f34 rebase in order to reduce the number of changes in an update. We will also announce the planned changes for cgroupsv2 and give approximately 2 months time before stable gets switched over to cgroupsv2 for newly deployed nodes.
17:11:31 <jlebon> ack
17:11:40 <fifofonix> +1
17:11:59 <dustymabe> bgilbert: does that reflect what you were advocating for?
17:12:17 <copperi_> +1
17:12:20 <bgilbert> +1
17:12:25 <jaimelm> +1
17:12:58 <dustymabe> #agreed we will decouple the move to cgroupsv2 for newly deployed nodes from the f34 rebase in order to reduce the number of changes in an update. We will also announce the planned changes for cgroupsv2 and give approximately 2 months time before stable gets switched over to cgroupsv2 for newly deployed nodes.
17:13:07 <dustymabe> #action jlebon to send communication about cgroupsv2 to coreos-status@ and coreos@ mailing lists.
17:13:16 <dustymabe> jlebon: ack ^^ ?
17:13:19 <jlebon> ack
17:13:41 * dustymabe will re-look over hackmd considering the most recent #agreed
17:14:06 <dustymabe> moving on to next topic? sorry that one took a while
17:14:15 <dustymabe> #topic Standardize on filename extensions for Butane and Ignition configs
17:14:21 <jlebon> yeah, let's hack on the hackmd together after
17:14:24 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/780
17:14:43 <dustymabe> This one is relatively simple
17:14:52 <jaimelm> famous last works
17:14:55 <jaimelm> words*
17:14:57 <dustymabe> 1. convention: .bu / .ign
17:15:07 <dustymabe> 2. convention: .bu.yaml / .ign.json
17:15:30 <dustymabe> 3. 2 until we do work in editors to enable identifying new extensions and then use 1
17:16:01 <bgilbert> 3 is really 2 unless someone wants to work on it
17:16:14 <jaimelm> heh, true
17:16:16 <dustymabe> bgilbert: good point. to me 3 and 1 both require work
17:16:29 <bgilbert> what work is required by 1?
17:16:36 <bgilbert> .ign/.fcc have been the convention for a long time
17:16:47 <dustymabe> sorry, I should have been more clear
17:17:17 <dustymabe> if the goal exists (albeit maybe a secondary goal) to have editors identify the format, then 3 and 1 both require work
17:17:23 <travier> 1 & 3 require editor work
17:17:36 <dustymabe> if we don't care about that, then 1 doesn't require work
17:18:22 <travier> with 1, we just accept that until work on editor gets done, the format won't be recognized
17:18:46 <jlebon> i mean, it's not very hard to configure most editors to say "treat this extension like if it were that extension". so for people like us who work with these configs all the time, it's fine. thinking more about newcomers
17:18:48 <jaimelm> ultimately, I think we do to make a nicer experience for people using it.
17:19:03 <bgilbert> jaimelm: +1
17:19:05 <jdoss> sorry for my ignorance but since these files are just yaml and json why not just be boring and stick with those extensions?
17:19:05 <jaimelm> +1 jlebon
17:19:27 <bgilbert> jdoss: because those extensions describe a particular property of the contents, not the contents
17:20:02 <travier> and while those are yaml & json, not all json & yaml files are valid bu or ign configs
17:20:16 <dustymabe> yeah I agree with bgilbert that it does make it nicer when you have some indication of where the file is supposed to be used (is this a kube yaml, or a xyz program yaml, or a butane yaml?
17:20:18 <jaimelm> e.g. "Is this an OKD yaml file? a FCOS yaml file? a...."
17:20:39 <travier> it is fine for syntax highlight to treat them the same way however
17:20:41 <dustymabe> to be clear though. nothing we're doing is going to require the user to make changes
17:20:49 <jdoss> mycool_fcc.yml run through ~fcct~ Butane = mycool_ign.json
17:20:51 <dustymabe> you can still name your files jdoss.yaml if you want
17:21:11 <bgilbert> right, to be clear, this is all about documentation conventions.  the code doesn't care.
17:21:13 <dustymabe> this is purely our conventions and what is put in our documentation
17:21:24 * jaimelm names every one jdoss.yaml
17:21:26 <jdoss> Maybe sufix something. IDK, we are just going to confuse new people I feel with these changes.
17:21:41 <jdoss> Non blocking. Just my 2cents.
17:21:52 <dustymabe> anyone else with points to bring up? bgilbert suggestions for how to proceed with $decision ?
17:21:59 <jdoss> jaimelm: I do love me some yaml
17:22:04 <travier> I suggested 3 but almost think 1 would be cleaner and simpler
17:22:36 * jaimelm votes for 1
17:22:36 <jdoss> Do 1 and document how to map your editor to yaml n json those files.
17:22:37 <bgilbert> travier: do you have any interest in doing the editor work?
17:22:42 * jdoss votes 1
17:22:43 <travier> :D
17:22:47 <jaimelm> jdoss +1
17:22:52 <travier> was expecting that one
17:22:52 <bgilbert> travier: asking because you proposed it
17:22:54 <jaimelm> and publish the documentation
17:22:54 <bgilbert> :-)
17:22:59 <travier> :D
17:23:10 <bgilbert> "no" is a valid answer
17:23:14 <lorbus> I don't feel strongly about this either, but I'd prefer to keep syntax highlighting working
17:23:23 <jaimelm> it lives.
17:23:33 <jdoss> oh bgilbert lol
17:23:42 <travier> I could give it a shot, should not be hard. And would be correlated with making those proper mimetypes too
17:23:49 <jaimelm> If I have time, happy to help with editor mod docs.
17:24:11 <dustymabe> should we remove option 3 from the table?
17:24:12 <fifofonix> 2 but I'm not religious about it.  I've renamed to .ign.json personally so newbies might find it easier.  but non-blocking.
17:24:16 <bgilbert> (that last was to travier)
17:24:20 <jaimelm> dustymabe: sounds like it
17:24:41 <dustymabe> travier: sound good if we remove option 3 from the table?
17:24:42 <jaimelm> double dot always feels messy to me.
17:24:59 <bgilbert> Ignition already has a proper mimetype
17:25:01 <bgilbert> we need to update it though
17:25:30 <lucab> #link https://www.iana.org/assignments/media-types/application/vnd.coreos.ignition+json
17:25:36 <travier> well, going 2 and doing the mimetype work is doing 3 without telling it so, fine :)
17:25:37 <jdoss> renaming fcct to butane is news to me but I like it.
17:25:53 <bgilbert> lucab: oh, interestingly, "File extension(s): ign, ignition"
17:26:00 <bgilbert> I have never seen .ignition
17:26:06 <dustymabe> travier: i think options 1 or 3 indicate our long term direction is .bu/.ign
17:26:24 <dustymabe> lets simplify and remove option 3 from the table
17:26:29 <jdoss> +1
17:26:32 <travier> ok +1
17:26:33 <jaimelm> +1
17:26:38 <lucab> bgilbert: same, I actually never realized there was a suffix suggestion in the registration
17:26:44 <dustymabe> ok vote time (please vote, even if you have already) below this line
17:26:45 <dustymabe> 1. convention: .bu / .ign
17:26:47 <dustymabe> 2. convention: .bu.yaml / .ign.json
17:26:49 <dustymabe> --------------------------------------------
17:26:52 <bgilbert> maybe this sounds odd, but that registration moves me toward option 1
17:27:00 * jdoss votes 1
17:27:12 * jaimelm votes 1
17:27:36 <copperi_> 1
17:27:54 <bgilbert> 1
17:27:54 <lucab> slightly on 2, but not strongly attached
17:27:55 <travier> 1 :)
17:27:56 * lorbus abstains
17:27:59 * dustymabe votes 2
17:28:24 <jlebon> no preference overall
17:28:47 <dustymabe> travier? anyone else?
17:28:53 <bgilbert> travier voted
17:29:00 <travier> voted 1.
17:29:00 <jaimelm> travier voted 1
17:29:17 <dustymabe> the "please vote, even if you have already" :)
17:29:22 <dustymabe> oh yeah I see it now
17:29:22 <jaimelm> 5/2
17:29:23 <dustymabe> whoo
17:29:34 <jdoss> i'll vote again if it makes you happy Dusty
17:29:41 <bgilbert> "add editor support for formats X" would make a good `good first bug`
17:30:13 <dustymabe> #proposed we'll go with the .bu .ign extension for new files in our documentation and we'll try to use those suffixes for consistency in issues/examples we post
17:30:17 <bgilbert> maybe even a good coreos@l.fp.o or d.fp.o post
17:30:31 <dustymabe> #agreed we'll go with the .bu .ign extension for new files in our documentation and we'll try to use those suffixes for consistency in issues/examples we post
17:30:45 <dustymabe> I short circuited to #agreed since we already voted
17:30:56 <dustymabe> did that statement reflect our discussion ?
17:31:01 <bgilbert> +1
17:31:04 <fifofonix> +1
17:31:06 <jaimelm> +1
17:31:19 <dustymabe> would be nice to do the editor work if someone would like to take that on :)
17:31:20 <lorbus> +1
17:31:30 <bgilbert> does anyone want to drive asking for community contributions on that?
17:31:40 <jaimelm> I will
17:31:43 <jaimelm> drive
17:31:48 <bgilbert> jaimelm: +1
17:31:51 <jaimelm> and help with editors
17:31:56 <jdoss> I will take the Sublime Text Editor since I am using that.
17:32:09 <jaimelm> Let's make a list and work through it.
17:32:17 <bgilbert> #action jaimelm to work on engaging with community on adding .ign/.bu editor support
17:32:24 <dustymabe> thanks jaimelm
17:32:27 <jaimelm> Perfect opportunity for the community outreach I've been hoping to do.
17:32:32 <dustymabe> too bad .but didn't take off :)
17:32:40 <bgilbert> #action bgilbert to investigate updating the Ignition type registration
17:32:49 <copperi_> .but.but ?
17:32:49 <dustymabe> #topic open floor
17:33:38 <travier> bgilbert: and create one for Butane?
17:33:40 <dustymabe> OK I just wanted to point out https://github.com/coreos/fedora-coreos-tracker/issues/767 - it's a bit of a gap for us right now. Is anyone driving closing that gap for us? If not I'll probably try to see what we can do.
17:34:02 <bgilbert> travier: yeah, we probably should
17:34:22 <dustymabe> also we should probably try to organize a test day like we did last time, which pretty much ends up being a "let's all get together and make sure our documentation still works" day
17:34:30 <travier> dustymabe: I need to find some time to try typhoon...
17:34:42 <dustymabe> travier: you and me both
17:34:55 <jlebon> dustymabe: good idea re. test day
17:35:03 <dustymabe> anybody want to run with organizing a test day?
17:35:25 <dustymabe> any other topics for open floor? sorry we are running over time
17:36:08 <dustymabe> will end meeting in 60s if no more discussion
17:36:11 <jaimelm> I can organize. Let's discuss specific needs at the next meeting.
17:36:46 <dustymabe> jaimelm: perfect. I'll open a ticket and tag you.
17:36:54 <jlebon> jaimelm++
17:36:54 <zodbot> jlebon: Karma for jaimelm changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:36:57 <jdoss> travier: typhoon is fantastic
17:37:02 <dustymabe> jaimelm++
17:37:02 <zodbot> dustymabe: Karma for jaimelm changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:37:15 <dustymabe> #endmeeting