16:30:16 <jbrooks> #startmeeting fedora_coreos_meeting
16:30:16 <zodbot> Meeting started Wed Sep 26 16:30:16 2018 UTC.
16:30:16 <zodbot> This meeting is logged and archived in a public location.
16:30:16 <zodbot> The chair is jbrooks. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:16 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:27 <jbrooks> #topic roll call
16:30:28 <sanja> .hello2
16:30:29 <zodbot> sanja: sanja 'Sanja Bonic' <sanja@redhat.com>
16:30:31 <ajeddeloh> .helloo2
16:30:32 <jbrooks> .fas jasonbrooks
16:30:32 <ajeddeloh> .hello2
16:30:32 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:30:35 <geoff-> geoff-: Geoff Levand <geoff@infradead.org>
16:30:35 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:30:42 <dustymabe> .hello2
16:30:43 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:53 <rfairley> .hello rfairleyredhat
16:30:54 <zodbot> rfairley: rfairleyredhat 'Robert Fairley' <rfairley@redhat.com>
16:31:38 <jlebon> .hello2
16:31:38 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:31:45 <dustymabe> jbrooks: I removed the meeting item from one of the tickets (one we discussed last week)
16:32:01 <jbrooks> #chair sanja ajeddeloh geoff- dustymabe rfairley jlebon
16:32:01 <zodbot> Current chairs: ajeddeloh dustymabe geoff- jbrooks jlebon rfairley sanja
16:32:08 <jbrooks> dustymabe, ok
16:32:24 <ksinny> .hello sinnykumari
16:32:25 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:33:08 <jbrooks> #chair ksinny
16:33:08 <zodbot> Current chairs: ajeddeloh dustymabe geoff- jbrooks jlebon ksinny rfairley sanja
16:33:11 <slowrie> .hello2
16:33:12 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:33:20 <jbrooks> #chair slowrie
16:33:20 <zodbot> Current chairs: ajeddeloh dustymabe geoff- jbrooks jlebon ksinny rfairley sanja slowrie
16:33:25 <jbrooks> #topic Action items from last meeting
16:33:45 <jbrooks> Looks like there were none?
16:33:55 <jbrooks> https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-09-19/fedora_coreos_meeting.2018-09-19-16.29.txt
16:33:58 <dustymabe> jbrooks: yeah I don't think there were any
16:34:51 <jbrooks> OK, tickets tagged w meeting: https://github.com/coreos/fedora-coreos-tracker/issues?q=is%3Aopen+is%3Aissue+label%3Ameeting
16:34:56 <sayan> .hello sayanchowdhury
16:34:57 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:35:05 <jbrooks> #topic Determine how to handle automatic rollback
16:35:13 <jbrooks> #link https://github.com/coreos/fedora-coreos-tracker/issues/47
16:35:24 * jbrooks wonders, is link a thing?
16:35:33 <jbrooks> I guess it's info?
16:35:39 <jbrooks> #info https://github.com/coreos/fedora-coreos-tracker/issues/47
16:35:40 <ajeddeloh> do we have lorbus[m] ?
16:35:51 <bgilbert> .hello2
16:35:52 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:35:59 <jbrooks> #chair sayan bgilbert
16:35:59 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe geoff- jbrooks jlebon ksinny rfairley sanja sayan slowrie
16:36:15 <dustymabe> ajeddeloh: I think he is moving this week.. we'll definitely have him next week
16:36:20 <ajeddeloh> +1
16:36:25 <jbrooks> ajeddeloh, Do we need lorbus for this one?
16:36:38 <dustymabe> i think it would help
16:36:52 <jbrooks> OK, we can save it
16:36:58 <ajeddeloh> not _need_ but he worked on some related stuff so haivng him would be nice. I'm fine delaying a week
16:37:08 <dustymabe> +1
16:37:14 <jbrooks> #topic Allow binaries written in Python via a "platform python" style approach
16:37:19 <jbrooks> #info https://github.com/coreos/fedora-coreos-tracker/issues/32
16:37:22 * dustymabe waves
16:37:29 <dustymabe> sorry this one took a large part of the meeting last week
16:37:45 <dustymabe> we had two proposals floating around at the end of the meeting
16:38:11 <dustymabe> we had discussed the number of security issues in python
16:38:22 <dustymabe> i was proposing that we make a statement about that
16:38:27 <jligon> .hello2
16:38:28 <zodbot> jligon: jligon 'Jeff Ligon' <jligon@redhat.com>
16:38:34 <dustymabe> #proposed we think security issues for python (#4) aren't significant enough to cause us great hardships during releases
16:38:42 <dustymabe> bgilbert: was +0.5
16:38:48 <jbrooks> #chair jligon
16:38:48 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe geoff- jbrooks jlebon jligon ksinny rfairley sanja sayan slowrie
16:38:56 <mnguyen_> .hello mnguyen
16:38:56 <dustymabe> can we make any counter proposals for that point?
16:38:56 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:40:07 <jbrooks> #chair mnguyen_
16:40:07 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe geoff- jbrooks jlebon jligon ksinny mnguyen_ rfairley sanja sayan slowrie
16:41:13 <jbrooks> dustymabe, I agree w/ your proposal
16:41:19 <jbrooks> so, not a counter
16:41:35 <dustymabe> any acks/nacks on above proposal?
16:42:09 <dustymabe> note that this proposal does not state that we will ship python, it's more just concentrating on point #4 from the list of reasons to not ship python
16:42:23 <bgilbert> I'm looking through the CVE updates from the ticket
16:42:26 <ajeddeloh> I'm with bgilbert on a +0.5
16:42:44 <bgilbert> I think I could go for +1
16:42:52 <ajeddeloh> i.e. it alone is not even to force us to not ship python
16:43:07 <dustymabe> ajeddeloh: yep, that's another way of wording it
16:43:36 <bgilbert> there's some stuff, but some of it would probably not require backports
16:44:13 <bgilbert> several of the Python issues are in sort of obscure modules that might not be used by anything we'd ship
16:44:20 <ajeddeloh> looking at the package lists, some of those (specifically nfs-utils and xfsprogs) don't even have python USE flags for gentoo and I wonder what python they need
16:44:36 <ajeddeloh> s/what python they need/what they need python for
16:44:41 <dustymabe> any more acks/nacks ? jlebon mnguyen_ slowrie geoff- sayan
16:44:56 <slowrie> I don't have a particularly strong opinion either way
16:45:11 <dustymabe> ajeddeloh: yep, and the depedency in container-selinux was already removed so that's one less too
16:45:56 <jlebon> I agree with "it alone is not even to force us to not ship python"
16:46:34 <jbrooks> dustymabe, Is that sufficient?
16:46:51 <dustymabe> ok so we've got like 3/4 +0.5 a few +1
16:46:55 <ajeddeloh> dustymabe: that list is just runtime requirements, yes? not build time as well?
16:47:35 <dustymabe> ajeddeloh: correct. I have not evaluated buildrequires, but honestly I don't think that's something we care about too much
16:48:02 <ajeddeloh> agreed, just double checking
16:48:15 <jbrooks> dustymabe, There's that narrow proposal, but the bulk of the issue remains
16:48:22 <dustymabe> ok since I've got no "No" votes I think we can put this one in the bag
16:48:38 <dustymabe> #agreed we think security issues for python (#4) aren't significant enough to cause us great hardships during releases
16:48:42 <dustymabe> jbrooks: yes
16:48:50 <dustymabe> I was then moving to the other proposal
16:48:57 <jbrooks> :)
16:49:03 <dustymabe> #proposed we'd really really like to remove python, but if we choose that we want to keep a tool or a few tools in fedora coreos that use python then we think the system python approach given that it solves #1 and #3, which are our primary concerns, would be reasonable.
16:49:46 <dustymabe> i.e. the above point gives us the option to ship "system python" if we find a tool that we "need" that requires python
16:50:05 <dustymabe> it doesn't say that we will ship python
16:50:09 <jbrooks> dustymabe, Would this approach involve us maintaining our own separate python packages
16:50:22 <dustymabe> jbrooks: ideally not, no
16:51:03 <dustymabe> there are a few ways we could achieve the goal, but maybe worth another discussion, unless we do want to dig into that here?
16:53:15 <jbrooks> dustymabe, Do we need a re-summary on the issue?
16:53:34 <jbrooks> Refocus, comment and take it up next time?
16:53:58 <dustymabe> jbrooks: meaning a "summary comment" in the issue itself?
16:54:08 <dustymabe> or want me to summarize here in the meeting?
16:54:44 <jbrooks> I was thinking in the issue, there's kind of a lot in there now
16:55:11 <jbrooks> But it could be here, too -- what do others think?
16:55:30 <ajeddeloh> I'll take an action item to investigate _why_ some of the packages depend on python that seem like they shouldn't
16:55:31 <dustymabe> yeah, was hoping to put this one to bed soon. either way works for me.. waiting to hear from all the pretty faces that are also here :)
16:56:16 <bgilbert> eh, +1
16:56:38 <jbrooks> Personally, I'm cool w/ python, I expect it to be in fedora, so I don't have a lot to say on the removing it front
16:56:38 <dustymabe> +1 for proposed, or +1 for wait til next time and add summary to issue ?
16:57:24 <jbrooks> I expect many will just shoehorn it in for things like ansible as they do now w/ CL
16:57:28 <bgilbert> +1 for proposed
16:57:37 <ajeddeloh> jbrooks: I think it's important to not think of fcos as "fedora-like" in many ways
16:57:39 <ksinny> +1 for proposed
16:57:47 <ajeddeloh> +1 for proposed though
16:57:47 <bgilbert> ajeddeloh++
16:57:51 <jbrooks> just the name ;)
16:57:57 <jbrooks> and the packages
16:58:08 <jbrooks> Anyway, minimal is always nice
16:58:13 <dustymabe> ok 3 +1, jbrooks was that a +1 from you ?
16:58:20 <jbrooks> Yes, +1
16:58:25 <dustymabe> 4 +1
16:58:29 <mnguyen_> +1 for proposed
16:58:45 <dustymabe> slowrie: sayan walters ?
16:59:33 <slowrie> +1 for proposed
16:59:44 <dustymabe> #agreed we'd really really like to remove python, but if we choose that we want to keep a tool or a few tools in fedora coreos that use python then we think the system python approach given that it solves #1 and #3, which are our primary concerns, would be reasonable.
17:00:00 <dustymabe> ok. I'll add this information to the tickets
17:00:15 <bhavin192> .hello2
17:00:16 <zodbot> bhavin192: bhavin192 'Bhavin Gandhi' <bhavin7392@gmail.com>
17:00:36 <jbrooks> #action dustymabe to update python ticket w/ acked proposals
17:00:37 <dustymabe> the next step that I'm looking at is compiling a list of python dependent software that we think we want or need (obviously the list of installed software needs to be analyzed)
17:01:07 <dustymabe> and then we can go from there. If it's "only" firewalld then we are a lot closer to removing python altogether
17:01:15 <bgilbert> +1
17:01:29 <dustymabe> if it's a bigger list then it'll take longer for us to break apart things
17:01:39 <dustymabe> thanks all for the discussion
17:01:45 <jbrooks> OK, next topic?
17:02:07 <jligon> i think walters isn't around at this time slot
17:02:30 <dustymabe> jbrooks: +1
17:02:37 <jbrooks> #topic Allow binaries written in Python via a "platform python" style approach
17:02:43 <jbrooks> wait
17:02:45 <jbrooks> sorry
17:02:59 <jbrooks> #topic Major release and update cycle for Fedora CoreOS
17:03:16 <jbrooks> #info https://github.com/coreos/fedora-coreos-tracker/issues/22
17:03:39 <bgilbert> and in particular, https://github.com/coreos/fedora-coreos-tracker/issues/22#issuecomment-409694543
17:04:51 <jbrooks> bgilbert, Would next just be the same as testing most of the time, or would it be regenerated each day w/ the newest pkgs
17:05:22 <dustymabe> i think next would be like next release (i.e. f29 right now)
17:05:40 <jbrooks> But when there isn't an f29 yet?
17:05:44 <jbrooks> Would it be rawhide?
17:05:47 <bgilbert> dustymabe: next would track the next release when it's baked "enough"
17:05:49 <bgilbert> never rawhide
17:05:58 <bgilbert> the idea is that someone should be able to safely run next all the time
17:06:15 <dustymabe> right, so for a period of time next would either not exist or just follow stable ?
17:06:19 <bgilbert> jbrooks: interesting question.  I was assuming it'd track testing
17:06:56 <bgilbert> I don't think we want to push nightly updates; too much churn
17:07:20 <jbrooks> That's the fedora atomic ref I'm usually on -- the nightly one, composed of stable pkgs
17:07:46 <jbrooks> How often is the least stable CL updated currently?
17:08:01 <bgilbert> "there's not an official schedule"
17:08:06 <bgilbert> but every 2 weeks
17:08:22 <bgilbert> plus very occasional out-of-cycle releases for fixes
17:09:23 <jbrooks> I use the updates-testing ref to give karma to atomic pkgs
17:09:53 <bgilbert> right, so the idea is that even "next" would be useful for servers that aren't actively managed
17:10:08 <bgilbert> we don't want to reboot them every day, and if we keep changing their package sets, they're less useful for catching regressions
17:10:44 <dustymabe> bgilbert: are you suggesting for next that we try some sort of stability guarantee ?
17:10:45 <bgilbert> the idea is not that there's a human actively paying attention, giving karma etc.
17:10:58 <jbrooks> Yeah, I think if we're to have three usable streams, those are three good ones to target
17:11:05 <bgilbert> dustymabe: what does guarantee mean?
17:11:16 <bgilbert> for CL, we expect all three channels to be usable in prod
17:11:25 <jbrooks> pkgs we care about will need karma to move through bodhiu
17:11:28 <geoff-> I think the cadence of the 'next' would depend on how much confidence we have in the automated testing of it
17:11:30 <bgilbert> it's just that alpha is more likely to regress than beta is more likely than stable
17:11:50 <dustymabe> bgilbert: yeah. that
17:11:56 <dustymabe> just wondering what the expectations are
17:11:57 <jbrooks> Maybe an updates-testing ref could be behind the scenes, testing only, or something
17:12:16 <bgilbert> jbrooks: sure, I don't mind some additional refs for technical purposes
17:12:21 <bgilbert> as long as we're not advising them to be used in prod
17:12:26 <dustymabe> bgilbert: +1
17:12:39 <jbrooks> I'm +1 to the straw proposal
17:12:42 <dustymabe> i think we're going to need multiple
17:12:49 <dustymabe> ok let me take a second
17:12:51 <bgilbert> geoff-: I don't think our automated testing is within a stone's throw of adequate to catch e.g. driver regressions on bare metal
17:12:52 <ajeddeloh> +1 here as well
17:13:10 <dustymabe> so we have next, testing, stable
17:13:19 <bgilbert> geoff-: the point of the channels is, in part, so users can help us catch regressions before they promote
17:13:20 <dustymabe> we've discussed next already
17:13:47 <dustymabe> testing would be basically packages that are already in fedora's stable yum repos but we have not yet released as a stable FCOS ?
17:14:00 <bgilbert> dustymabe: yes
17:14:10 <dustymabe> and how often would we push out testing ref ?
17:14:27 <bgilbert> dustymabe: the straw proposal was every two weeks
17:14:41 <dustymabe> bgilbert: so one problem with that
17:14:41 <ksinny> About testing: Periodic snapshot of the current Fedora release + updates, perhaps every two weeks.
17:14:43 <dustymabe> that I see
17:15:02 <dustymabe> let's say today an update hits a stable yum repo
17:15:07 <bgilbert> in CL, there's a new beta every unspecified *cough*4 weeks*cough*
17:15:21 <dustymabe> and we do a testing release
17:15:37 <dustymabe> and tomorrow another update hits stable
17:15:37 <ksinny> here, what does updates mean? do we make updates packages available once in two week or pull in once they are available?
17:15:55 <dustymabe> in two weeks the first update would hit stable, but in four weeks the second update would make it to users
17:16:05 <bgilbert> dustymabe: right
17:16:18 <dustymabe> that seems a little "long" in Fedora pace terms
17:16:31 <ksinny> +1 to what dustymabe said
17:16:39 <bgilbert> we're not necessarily trying for Fedora pace  :-)
17:16:41 <dustymabe> since that update already spent some time in the updates-testing yum repo before it ever hit stable
17:16:45 <jbrooks> I feel that, too, but we're expecting ppl to use testing
17:16:48 <jbrooks> and next
17:16:50 <jbrooks> and stable
17:17:10 <jbrooks> So stable is conservative
17:17:25 <dustymabe> right. I'm actually ok with that
17:17:29 <bgilbert> btw, as with CL I don't expect the release cadence to be contractual, so we can adjust as needed
17:17:41 <dustymabe> but I wonder if we should adjust the name
17:18:08 <dustymabe> well maybe not
17:18:11 <ajeddeloh> massive +1 to "not contractual"
17:18:23 <jbrooks> You need RHEL for that ;)
17:18:41 <ajeddeloh> a +2 you might even say :)
17:18:50 <dustymabe> either way i'm actually OK with the proposal, just some of the expectations in *fedora* are that once they hit "stable" in bodhi there bug or security issue should be "fixed" if they update
17:19:04 <dustymabe> their*
17:19:16 <jbrooks> That's why I think of the nightly option
17:19:19 <dustymabe> and I wonder if we'll feel any pain as a result of the disconnect
17:19:29 <bgilbert> sure, part of the FCOS value is batching updates for people
17:19:33 <jbrooks> Like, access to what fedora has deemed stable
17:19:34 <ajeddeloh> so we'd definitely need to backport secutiry fixes
17:19:39 <jbrooks> as soon as its available
17:19:40 <bgilbert> right, backports are a part of this
17:19:47 <bgilbert> certainly for stable, maybe even for testing
17:19:55 <walters> .hello2
17:19:56 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
17:20:04 <bgilbert> we'd need to look at the security update and bugfix stream and backport things that were important
17:20:04 <jbrooks> #chair walters
17:20:04 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe geoff- jbrooks jlebon jligon ksinny mnguyen_ rfairley sanja sayan slowrie walters
17:20:08 <jbrooks> welcome, Colin
17:20:08 <bgilbert> note: backport, not promote
17:20:31 <dustymabe> hmm, define that?
17:20:51 <dustymabe> i.e. we wouldn't promote the fixed build? we'd take the patch and do our own build ?
17:21:05 <bgilbert> if there's an important CVE fix in the kernel, we'd probably patch for the CVE rather than take a new kernel version
17:21:31 <bgilbert> I'll elide the rant about how many regressions we've been seeing in stable kernels
17:21:45 <dustymabe> yeah, i wonder how much pain that opens us up to
17:21:56 <bgilbert> but we'd want to make sure we're not promoting regressions to stable, cuz we want it to be stable
17:22:01 <bgilbert> dustymabe: indeed.
17:22:28 <jbrooks> We're doing our own kernels?
17:22:35 <dustymabe> i.e. I think we'd need someone to basically be really close, *secret handshake* close, with the kernel team
17:23:04 <bgilbert> ideally, yes.  but I don't know if that's required?
17:23:14 <bgilbert> i.e. reading changelogs should be sufficient
17:23:29 <bgilbert> there's an interesting question about what sort of SLO we're providing on catching Every Last Security Update
17:23:39 <bgilbert> the usual answer, for all distros everywhere, is "none at all"
17:24:05 <jbrooks> We're coming close to the end of the (half) hour -- do we have actions on this?
17:24:15 <dustymabe> bgilbert: so I guess the kernel point is one we're going to have to discuss further
17:24:21 <bgilbert> so, call it a best effort thing.  but if there's something like SegmentSmack, we want to get it fixed.
17:24:35 <ksinny> Backporting CVE patch instead of using updated kernel means we will get limited testing as well becasue regular Fedora users won't be tetsing it
17:24:37 <bgilbert> kernel was an example.  also things like docker or curl
17:25:08 <dustymabe> ksinny: yeah
17:25:21 <dustymabe> bgilbert: let's take this to comments in the issue and sync back up next week
17:25:29 <bgilbert> dustymabe: +1
17:25:38 <jbrooks> Sounds good
17:25:39 <ajeddeloh> there's a sorta damned if you do, damned if you dont thing with kernel regressions too. If you promote, you get all the regressions in the new kernel, if you backport, you get all bad backports
17:25:46 <ajeddeloh> +1
17:25:46 <bgilbert> ajeddeloh++
17:26:06 <jbrooks> #topic Open Floor
17:26:13 <jbrooks> Any open floor items?
17:26:16 <dustymabe> ajeddeloh: yeah, so might as well choose the one that requires less work of you :)
17:26:19 <sanja> Fedora CoreOS logo: https://github.com/coreos/coreos.fedoraproject.org/blob/master/public/images/fedoracoreos-logo.svg
17:26:37 <dustymabe> sanja: nice
17:26:41 <dustymabe> is that open up to feedback
17:26:42 <ksinny> yay! nice
17:26:43 <bgilbert> dustymabe: or the one with less code churn :-)
17:26:43 <ajeddeloh> sanja++
17:26:43 <zodbot> ajeddeloh: Karma for sanja changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:26:50 <dustymabe> or is that capital D done
17:26:52 <ksinny> sanja++
17:27:12 <sanja> And I'd like to move the website to be GitHub Pages - means the repository stays as is BUT it'll be a slightly different structure. It'll be same as buildah.io and podman.io - makes it easier for all of us. I'll just have to tell Fedora infra to point the DNS to there. Everyone ok with that?
17:27:17 <bgilbert> sanja: seconding dustymabe's question
17:27:30 * ajeddeloh is slightly disappointed we're not rolling with the "corehat"
17:27:41 <sanja> Dusty, it's kind of Capital D done because branding approved and unless you want to go through another month or two of waiting, consider it a capital D.
17:27:41 <bgilbert> sanja: +1 to moving it
17:27:54 <dustymabe> sanja: +1 for the move
17:27:55 <sanja> What would you like to change?
17:28:08 <bgilbert> sanja: some sort of visual distinction between "core" and "os" would make it easier to read
17:28:09 <sanja> ok, moving will be initiated today then and I'll see when I can get it done the earliest with Fedora infra
17:28:26 <sanja> anyone else got comments on the logo because I'll collect them now and send them over to Mo
17:28:27 <bgilbert> e.g. letter weight
17:28:33 <dustymabe> sanja: i think it would be cool to have it be light blue on the outside, dark blue on the middle core and white in the middle :)
17:28:56 <dustymabe> right now the core doesn't look that much different than CL, right ?
17:28:59 <jligon> was the COREOS text sans serif before?
17:29:10 <ajeddeloh> it was
17:29:21 <sanja> dusty so no pink basically?
17:29:25 <ajeddeloh> see https://coreos.com/
17:29:26 <sanja> just light blue, dark blue, white?
17:29:42 <dustymabe> right, for FCOS - just a suggestion :)
17:30:03 <dustymabe> or dark blue, light blue, white, whichever one looked better
17:30:16 <bgilbert> dustymabe: I like that
17:30:20 <dustymabe> i don't even know if it would look good or not, that's just what I had in my head
17:30:36 <sanja> Ok, so I'll take to Mo: * consider color change where outer core is light blue or dark blue, inner core the remaining of light/dark, and inner white, * change coreos text so it's more easily distinguishable
17:30:46 <jligon> the pink from the logo might be nice =)
17:31:07 <bgilbert> sanja++
17:31:07 <zodbot> bgilbert: Karma for sanja changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:31:07 <sanja> The pink is a slight hint to IoT and closer to the old than if it's all blue
17:31:28 <sanja> I'll get those two points to her, anyone else?
17:31:29 <jligon> I trust mo with the serif/sans decision, but it was startling to see first time.
17:31:58 <dustymabe> sanja++ obviously I'm not the only person with an opinion so I won't mind if it doesn't end up happening
17:31:58 <zodbot> dustymabe: Karma for sanja changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:31:59 <jligon> made me wonder if there was a font error in inkscape
17:32:07 <sanja> hehe
17:32:31 <jbrooks> OK, anything else for this week?
17:32:37 <sanja> ok, let's see what she comes back with, I think she also didn't want to include too many fonts and there is already a distinction between fedora and coreos in the texts but I'll tell her those
17:32:38 <dustymabe> distinguishing between the old and new logo would be nice too
17:32:47 <sanja> thanks everyone bgilbert++, dustymabe++, jligon++
17:32:47 <zodbot> sanja: Karma for jligon changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:32:47 * ksinny has one quick item
17:32:51 <ksinny> #info Thanks to Ed vielmetti for giving access and getting account set-up on packet.net to use aarch64 machine for Fedora CoreOS related work.
17:32:58 <ksinny> #link https://github.com/WorksOnArm/cluster/issues/110
17:32:59 <dustymabe> thanks ed-packet!
17:33:01 <jbrooks> awesome
17:33:05 <ksinny> I am getting familar to the Packet web intreface and options available
17:33:11 <sanja> dustymabe++
17:33:18 <sanja> bgilbert++
17:33:18 <zodbot> sanja: Karma for bgilbert changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:33:22 <dustymabe> ksinny: kola also can work with packet too (correct me if I'm wrong slowrie )
17:33:28 <dustymabe> so it might be worth trying that out
17:33:34 <slowrie> kola does indeed support packet
17:34:02 <ksinny> nice
17:34:38 * ksinny will take a look later on
17:34:58 <bgilbert> ksinny: I wrote that code in kola; let me know if you have any problems
17:35:08 <jbrooks> All right, let's close this out
17:35:15 <ksinny> bgilbert: sure
17:35:22 <ksinny> bgilbert++
17:35:22 <zodbot> ksinny: Karma for bgilbert changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:35:28 <jbrooks> #endmeeting