13:00:07 <stickster> #startmeeting Workstation WG
13:00:07 <zodbot> Meeting started Mon Mar 26 13:00:07 2018 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:07 <zodbot> The meeting name has been set to 'workstation_wg'
13:00:09 <stickster> #meetingname workstation
13:00:09 <zodbot> The meeting name has been set to 'workstation'
13:00:12 <stickster> #topic Roll call
13:00:12 <ryanlerch> .hello ryanlerch
13:00:13 <zodbot> ryanlerch: ryanlerch 'Ryan Lerch' <rlerch@redhat.com>
13:00:14 <stickster> .hello pfrields
13:00:16 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
13:00:29 <kalev> .hello kalev
13:00:30 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
13:00:58 <stickster> #chair ryanlerch juhp[m] kalev mclasen rdieter
13:00:58 <zodbot> Current chairs: juhp[m] kalev mclasen rdieter ryanlerch stickster
13:01:28 <juhp[m]> .hello petersen
13:01:29 <zodbot> juhp[m]: petersen 'Jens Petersen' <petersen@redhat.com>
13:01:38 <mclasen> .hello mclasen
13:01:39 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com>
13:01:49 <rdieter> .hello rdieter
13:01:50 <zodbot> rdieter: rdieter 'Rex Dieter' <rdieter@gmail.com>
13:02:47 <stickster> Hi all
13:02:56 <ryanlerch> morning!
13:03:01 <stickster> #info Agenda link: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting
13:03:28 <stickster> #info Overall issues link: https://pagure.io/fedora-workstation/issues?status=Open -- if you see something not covered in agenda that should be, speak up now :-)
13:04:08 <kalev> https://pagure.io/fedora-workstation/issue/41 maybe as well?
13:04:58 <stickster> kalev: maybe -- what do we need to decide there?
13:05:14 <mcatanzaro> .hello catanzaro
13:05:15 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org>
13:05:30 <stickster> #chair mcatanzaro
13:05:30 <zodbot> Current chairs: juhp[m] kalev mcatanzaro mclasen rdieter ryanlerch stickster
13:05:52 <mclasen> I haven't gotten to try the latest build
13:05:57 <stickster> In the meantime... let's forge ahead
13:06:03 <stickster> #topic Cantarell in F28
13:06:10 <stickster> #link https://pagure.io/fedora-workstation/issue/40
13:06:30 * cschalle hi
13:07:28 <stickster> #chair cschalle
13:07:28 <zodbot> Current chairs: cschalle juhp[m] kalev mcatanzaro mclasen rdieter ryanlerch stickster
13:08:00 <otaylor> .here otaylor
13:08:21 <otaylor> sorry to be late
13:08:45 <juhp[m]> I haven't had a chance to test the new version of Cantarell, but given the reduced glyph coverage also, I think reverting is a good idea
13:09:24 * kalev doesn't have strong opinions either way.
13:09:26 <juhp[m]> .bug 1556854
13:09:28 <zodbot> juhp [m] : Bug 1556854 – Wrong cyrillic font - https://bugzilla.redhat.com/1556854
13:09:40 <aday> the new version is a significant improvement, aesthetically. we're making use of the new font weights on the lock screen and it looks great
13:09:56 <mclasen> I don't think coverage can be a strong argument, since cantarell had relatively weak coverage to begin with
13:10:01 <juhp[m]> Let me add a similar comment to the ticket
13:10:05 <mclasen> unless we loose coverage in en_US
13:10:29 <mclasen> is there a screenshot of spacing issues somewhere ?
13:10:45 <mclasen> I see severe font issues on this system, but it doesn't have the latest cantarell
13:10:57 <juhp[m]> Dunno how easy it is to fix the spacing issue Adam reported
13:11:11 <mclasen> what is the "spacing issue adam reported"
13:11:14 <mclasen> ?
13:11:22 <aday> i'd be interested to see a screenshot too. i haven't seen spacing issues in my testing
13:11:29 <juhp[m]> Is there a bug? Okay mentioned in the ticket
13:12:14 <kalev> hm, I think I saw screenshots somewhere, let me try and hunt them down
13:12:18 <mclasen> "many issues with spacing between words" is really too vague without a screenshot
13:12:36 * mclasen will abstain without a way to test this himself
13:12:55 <juhp[m]> Agreed
13:13:12 <kalev> aha, found, trying to get a link to the mailing list post now
13:13:15 <aday> i've been using the latest version for some time and haven't noticed any significant issues
13:13:22 <juhp[m]> I think we should wait for more details
13:13:24 <aday> (not a font expert though)
13:13:33 <stickster> I updated to the new .101 and there are some weird things I notice -- like "m" and "n" characters have odd rendering in default weights on the Top Bar
13:13:46 <stickster> But I'm not on a hiDPI screen here
13:14:21 <kalev> https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/AF7TZUABMVN2HIV5VPODWSVNURE7PDDO/ has screenshots
13:14:47 <stickster> https://koji.fedoraproject.org/koji/buildinfo?buildID=1058449
13:15:17 <mclasen> we're under time pressure here, I guess
13:15:36 <otaylor> mclasen: Do you know what Nikolaus meant about subpixel positioning?
13:15:37 <mcatanzaro> FWIW my opinion is that the new version is clearly inferior, based on adamw's screenshots and the lack of Cyrillic coverage, but my inclination is to go with the wishes of the font designer and I presume he wouldn't have released it if he didn't think it was better....
13:15:39 <kalev> hm, or at least it claims to have screenshots, I'm not sure how to actually see the new font changes there
13:15:55 <mclasen> otaylor: I assume he means that we have a crippled freetype
13:16:13 <otaylor> WRT hinting? It didn't sound like that, no
13:16:29 <juhp[m]> Might be good to test the font build on f27 too...
13:16:48 <otaylor> it sounded more like he was designing the font to be rendered with multiple horizontal phases, and Qt was doing that?
13:17:11 <stickster> https://openqa.fedoraproject.org/tests/204833#step/disk_custom_ext3/11 is a screenshot that shows some issues
13:17:15 <otaylor> (nwould cause a significant glyph cache size increase...)
13:17:31 <mclasen> yes
13:17:32 <juhp[m]> mcatanzaro: actually no... See his comments in the above bug
13:17:51 <stickster> some letters are really smooshed together in that screen shot (look at "SP" in "SPACE" at lower left, or the word "Installation" at lower right
13:18:00 <otaylor> mclasen: Would be good to catch up with him, and make sure that our text stack plans and how our default font is being developed are in sync
13:18:27 <mclasen> otaylor: yes, we should try to sit down with him in #gnome-design and figure out what concretely needs to happen
13:18:40 <mclasen> but first I need to see the font on my system
13:18:45 * mclasen should package layer it
13:18:53 <otaylor> stickster: Oy, collisions
13:19:43 <otaylor> INSTALLATION in the upper right shows some bad kerning - would be a test case to compare to see if kerning tables were dropped (as it sounded for what adamw quoted)
13:19:53 * juhp[m] is in a train from the airport...
13:20:09 <mcatanzaro> juhp: It looks like all he says in that bug is "I think it's easier to prepend cantarell to the default font list for supported languages?"
13:20:27 <mcatanzaro> Nikolaus is the Cantarell designer, not Nicolas
13:20:40 <stickster> Oh wait, that screenshot I'm looking at predates the .101 version
13:20:52 <mcatanzaro> Anyway, the difference is subtle enough that I'm not sure people are going to notice except when comparing screenshots side-by-side, or on the login screen where the letters are huge.
13:21:13 <mcatanzaro> But users with Cyrillic locales are going to notice for sure.
13:21:44 <aday> mcatanzaro: i'm not sure "users will notice" is the relevant heuristic here...
13:21:50 <kalev> if we go with the new cantarell for F28, we'll need to figure out the fallback font changes so that at least cyrillic falls back to noto
13:22:02 <otaylor> aday: But if the font looks *worse* as rendered, then it isn't an improvement
13:22:15 <otaylor> kalev: I think we figured that out
13:22:27 * kalev nods.
13:22:29 <mcatanzaro> Yeah, Akira is around to help with that.
13:22:38 <aday> otaylor: sure, unnoticed changes can go in either direction
13:22:40 <mcatanzaro> We just need to follow-up and make sure it happens.
13:22:58 <aday> my point was that quality changes aren't always consciously registered
13:23:22 <juhp[m]> mcatanzaro: sorry I think I meant quotes in the corresponding Pagure ticket, which I just managed to lose
13:24:23 <mcatanzaro> """thanks for the feedback :) cantarell's spacing does indeed look a bit funky... in gtk3 and firefox. that's due to a missing technical detail called "subpixel positioning". Spacing looks more consistent in Qt apps and Chrome. there also isn't any kerning yet, so things like AVA, To, etc. look gap-y"""
13:24:32 <otaylor> I think we need some AB screenshots or text samples and some follow up by mclasen or someone else who deals with the text stack (weirdly not me any more... :-/) for what adamw reported discussing with madigens (Nikolaus)
13:24:35 <mcatanzaro> That doesn't look like a request for us to stick to the old version, though.
13:25:34 <mcatanzaro> Since the difference is subtle, my inclination is to bat this down to the Cantarell developers and let them decide how to handle it. I'm not sure this qualifies as a major issue the WG should have to deal with.
13:25:44 <otaylor> well, it looks like an admission that the new version might not be finished, or might not be optimally working with our text stack compared to the old version.
13:25:51 <mclasen> unless we can somebody with sufficient knowledge of the font stack and time to sit down and sort through the issues this week, I guess reverting to the old version for the beta is the responsible approach
13:26:03 <stickster> mcatanzaro: perhaps not, but it also doesn't include a plan/ETA for addressing
13:26:12 <stickster> (nor does it *have* to, but that's something we should care about)
13:26:18 <kalev> the beta ship has already sailed, I think. this is more about what to do for the final release
13:26:19 <mclasen> and work out the issues in rawhide
13:26:24 <stickster> kalev: agreed
13:26:28 <mclasen> oh, ok
13:26:30 * mclasen is behind
13:26:36 <juhp[m]> (hmm can't find that yet: fwiw - https://pagure.io/fedora-workstation/issue/36)
13:27:07 <cschalle> ok, so lets revert for now and if this gets resolved I guess there is little stopping us from doing an post release update bringing the new version back?
13:27:42 <otaylor> cschalle: well, adamw will definitely not be happy if we juggle fonts back and forth from a OpenQA qa-by-screenshot perspective
13:28:17 <mclasen> changing fonts post-release seems dubious to me
13:28:23 <aday> the lock screen looks fairly different with the new version, due to the use of the thin weight. could be a surprising change
13:28:28 <mcatanzaro> cschalle: If we revert it, then the new version should wait until F29, especially since it reduces glyph coverage
13:28:40 <cschalle> ok, well I am fine with delaying the new version to F29 too
13:28:51 <kalev> agreed with that mcatanzaro just said
13:29:15 <stickster> mcatanzaro: +1
13:29:27 <ryanlerch> +1 from me too.
13:29:40 <kalev> I think it's ok to change the font between beta and the final freeze, but not after that
13:29:51 <mcatanzaro> #proposal: Revert to old Cantarell for F28 but leave it be in rawhide, revisit in six months to see if regressions are still unaddressed.
13:29:51 <juhp[m]> +1
13:30:15 <juhp[m]> Right
13:30:15 <mcatanzaro> #proposed Revert to old Cantarell for F28 but leave it be in rawhide, revisit in six months to see if regressions are still unaddressed.
13:30:24 <stickster> mcatanzaro: +1
13:30:29 <rdieter> +1
13:30:30 <cschalle> +1
13:30:31 <otaylor> +1 from the working groups perspective, but clearly action now is needed to understand the nature of the regression
13:30:42 <ryanlerch> does the things in the shell matter if there arent the right weights there though?
13:30:51 <kalev> 1
13:30:55 <kalev> +1
13:31:09 <juhp[m]> +1
13:31:28 <ryanlerch> i.e. will it fall back to afont weight that exists?
13:31:29 <juhp[m]> Though don't think we need to wait 6 months :)
13:31:30 <aday> ryanlerch: i think it should fall back to the old weights if they're not available. not 100% though
13:31:42 <aday> (100% sure, i mean)
13:31:50 <mclasen> +1
13:32:16 <ryanlerch> +1
13:32:25 <mcatanzaro> OK, I think we have consensus
13:32:29 <aday> ryanlerch: https://gitlab.gnome.org/GNOME/gnome-shell/issues/45#note_56187
13:32:40 <mcatanzaro> #agreed Revert to old Cantarell for F28 but leave it be in rawhide, revisit in six months to see if regressions are still unaddressed.
13:32:53 <stickster> mcatanzaro: thanks, my copypasta not fast enough apparently
13:32:53 <kalev> thanks guys, I'll go and unpush the cantarell update from updates-testing then
13:33:36 <stickster> #action kalev unpush Cantarell update from updates-testing
13:33:50 <stickster> otaylor: What else needs to happen for follow-up here, and who should be doing it?
13:33:56 <otaylor> aday: should we have a discussion with madigens to figure out what the situation is with Cantarell vs. GNOME tech?
13:34:01 <stickster> *jinx ;-)
13:34:29 <mclasen> otaylor: I'd like to be in it too
13:34:29 <aday> otaylor: i agree that should happen! not sure what i'd have to contribute though
13:34:52 <otaylor> mclasen: Definitely a good idea to have you there
13:34:53 <aday> it'd be good to make sure that jimmac's involved
13:35:15 <mclasen> so, jimmac, rather than you ?
13:35:34 <otaylor> aday: Well, someone from the design side, so we can have a good understanding of what the tradeoffs we're making for visual appearance are.
13:35:48 <stickster> #action otaylor mclasen aday discuss Cantarell/text-stack issues with madigens, involve and/or jimmac as needed
13:36:18 <aday> otaylor: yes, for sure
13:37:34 <stickster> OK, next up is...
13:37:38 <stickster> #topic Initial setup redundancy
13:37:46 <stickster> #link https://pagure.io/fedora-workstation/issue/21
13:38:05 <stickster> juhp[m]: (or anyone): Where is https://bugzilla.gnome.org/show_bug.cgi?id=794166 at this point?
13:38:48 <mcatanzaro> Well the patch there looks good from a code perspective, but it looks like the developer has not actually tested it yet
13:39:30 <mcatanzaro> adamw also raised a concern that the default input method for Japanese appears to me nothing, so not sure if it will work in all locales.
13:39:43 <stickster> hm :-\
13:40:13 <juhp[m]> Unfortunately I have been traveling this last week - so don't really have anything to update or a chance to test
13:40:23 <mcatanzaro> I'll test the patch and see how it works
13:40:32 <juhp[m]> I will talk to pay (epico) tomorrow
13:40:34 <stickster> Are we hoping to pull this in for GA?
13:41:08 <mcatanzaro> Yeah, I'll make sure it gets pulled in for GA *if* the patch is ready in time for that
13:41:09 <stickster> We have a couple weeks remaining in which to do that, but clearly we don't want to run the clock out if so
13:41:14 <stickster> mcatanzaro: coolio
13:41:39 <stickster> OK -- does anyone disagree that we should let juhp[m] look into this with epico and get back with us in the next day or two?
13:41:42 <mcatanzaro> mclasen: Do you want to do a code review as well? Or OK with my comments?
13:41:52 <cschalle> stickster, sounds good to me
13:42:38 <mclasen> mcatanzaro: seems you are doing a fine job there
13:42:44 <stickster> :-)
13:43:10 <stickster> #agreed give juhp[m] a few days to look into the g-i-s patch with epico and report back
13:43:21 <juhp[m]> Okay
13:43:29 <stickster> #topic All other business (open floor)
13:43:51 <stickster> Next meeting is Monday April 9. I don't have the meeting chair rotation in front of me but I know it's not me ;-)
13:44:01 <juhp[m]> Review help is most welcome anyway
13:44:12 <stickster> However, I can't attend that day since there's a big Fedora hackathon that I'm facilitating all that week
13:44:24 <cschalle> stickster, I filed two tickets for 3rd party software. I think it would be good to discuss those
13:44:49 <stickster> #info kalev is listed as chair for April 9
13:44:59 <stickster> cschalle: Sure, drop the link here and we can discuss
13:45:06 <stickster> Note, we have 15 min left
13:45:34 <cschalle> Nvidia driver - https://pagure.io/fedora-workstation/issue/37 and the the same ticket for Steam is 38
13:46:43 <cschalle> Basically I want to start lining up repos for F28 that we want to include
13:47:13 <mcatanzaro> F28 or F29?
13:47:18 <cschalle> F28
13:47:30 <mcatanzaro> Seems *really* late for F28? *shrug*
13:47:32 * stickster chuckles, this really should be in the Beta but obviously missed to boat
13:47:36 <stickster> *the
13:47:52 <cschalle> yeah, I was holding off due to waiting for some fixes to the 3rd party support in GNOME Software
13:48:14 <cschalle> on the positive side, it isn't like this stuff is untested these repos are widely used and in operation for years
13:48:23 <stickster> cschalle: Is this the bit where we have some official Fedora repo showing up as 3rd party?
13:48:31 <stickster> cschalle: yeah, that's reasonable
13:48:43 <stickster> we're only talking about something in /etc/yum.repos.d after all
13:48:50 <stickster> and IIRC disabled by default
13:49:23 <cschalle> stickster, no the way it got implemented in the end is that if you choose to enable 3rd party software it will install the rpm that includes the  repo links at that point
13:49:24 <mcatanzaro> For the case of the NVIDIA driver, there is some controversy as to whether we should use Negativo or RPMFusion as the source. Spot is aware and did not complain about RPMFusion, so looks like we have our choice of either one.
13:49:46 <cschalle> mcatanzaro, well Spot agreed that having a single app repo is preferable too
13:50:04 <mcatanzaro> Looks like RPMFusion developers are happy to provide that, though, so that's not a point against RPMFusion
13:50:42 <mcatanzaro> And they're active in the issue thread. I've been trying to get them to explain why we should use their source instead of Negativo's, but I'm having trouble understanding their responses.
13:50:51 <cschalle> mcatanzaro, are they? at first I thought so, but then the discussion seemed to turn into 'we will just put any package you want into this one repo'
13:51:26 * mclasen thinks they are just defending their turf
13:51:37 <cschalle> mcatanzaro, the main argument in rpmfusion favour IMHO is that there is a group of people behind it, so in theory at least it should be less chance of lack of maintenance
13:51:39 <stickster> *sigh
13:51:43 <kwizart> mcatanzaro, we are a community, simone works is mergeable into ours, but not the other way
13:51:45 <mcatanzaro> It sounds to me like their driver is still expected to break users' computers after kernel updates, which seems unacceptable. But they are saying this is still the case for the Negativo driver as well. I don't pretend to understand.
13:51:52 <mcatanzaro> Hi kwizart!
13:51:55 <kwizart> hi
13:52:14 * rdieter is generally in favor of using rpmfusion whereever possible
13:52:17 <stickster> mcatanzaro: I thought a comment in this ticket thread specifically says they have the same (or similar) nouveau fallback
13:52:56 <kwizart> stickster, not only the same, but the nouveau fallback was designed by me (after an original idea from hans)
13:53:03 <cschalle> as a sidenote, the Nvidia driver is not the worlds greatest example though as there are efforts to get a NVidia hosted repo set up, so this is intermediate regardless
13:53:08 <kwizart> I even think we have a better iterration
13:54:07 <mcatanzaro> I was kind of under the impression that we were planning to use Negativo mainly because we assumed an RPMFusion-provided repo would be rejected by legal. But it seems like that is not the case? cschalle?
13:54:30 <cschalle> mcatanzaro, no legal doesn't care who provides the repo
13:54:41 <mclasen> a "drivers" repo that contains 'everything good' is going to be tough to get a positive review for
13:54:49 <mclasen> in particular if it is open to random future additions
13:54:55 <cschalle> mcatanzaro, they care more about the policy around the repo. ie no 'surprise' apps showing up there etc.
13:55:04 <stickster> I think Spot was clear that the preference is for a single-use repo
13:55:05 <rdieter> mclasen: random as in stuff we (WG) specifically ask to be included
13:55:08 <mcatanzaro> Then if RPMFusion provides a repo named nvidia-driver that contains just the NVIDIA driver, it would be fine?
13:55:18 <cschalle> mcatanzaro, yes
13:55:22 <stickster> *nod
13:55:25 <mclasen> rdieter: still not what we want
13:55:31 <mcatanzaro> kwizart: Sound OK?
13:55:45 <rdieter> mclasen: that's not our call either, imo (that's a legal one or policy one)
13:55:45 <mclasen> separating the repos is a risk-minimization, as explained by cschalle in the ticket
13:55:54 <kwizart> mcatanzaro, sure
13:57:00 <kwizart> just to be fully complete, as a we still at the "service design" step
13:57:37 <kwizart> would (fe-legal) accept on pre-built nvidia kernel module ? I think this is controversial, but worth to ask
13:57:41 <stickster> Is there a technical reason we couldn't change the repo definition next release?
13:58:09 <cschalle> kwizart, last we asked the answer was no, but I also know there are some discussions around that as part of the discussions for a NVidia hosted repo
13:58:46 <cschalle> stickster, shouldn't be, and the advantage of single app repos here, is that we can switch repos without collateral damage to other applications
13:59:00 <kwizart> cschalle, okay. I know nvidia provides ones for sles, so feel free to forward me anything relevant about this particular issue
13:59:25 * mclasen has to run
13:59:40 <stickster> Given where things are at the moment, maybe we should be doing this: (1) working specifically on negativo for F28; (2) set a tickler for late August to get with rpmfusion to see if we should swap over
14:00:00 <kwizart> stickster, sorry, but this is again, not acceptable
14:00:09 <mcatanzaro> I'd defer it to F29 so we don't have to switch users from one repo to the other
14:00:18 <mclasen> kwizard: but you don't have a vote in it
14:00:26 <mcatanzaro> It's still a talking point whether we have it now or in the fall
14:00:27 <rdieter> kwizart: are things working and testable now?
14:00:48 <juhp[m]> kwizart: why not?
14:01:10 <mcatanzaro> How will the transition from one repo to the other work? Do we really want to teach GNOME Software to disable the Negativo repo and enable the RPMFusion one automatically?
14:01:25 <kwizart> stickster, as pointed on the first comment, this is not acceptable to bypass the "community review" process fedora as created to allow a single party
14:01:28 <rdieter> mcatanzaro: as long as rpmfusion is "newer", it should be fine
14:01:34 * mclasen gives a +1 to going with the existing negative solution and runs offf
14:01:44 <cschalle> mcatanzaro, I assume that if we drop one repo in fedora-workstation-repos and put in another which containers a newer version that will automatically happen
14:01:51 <stickster> cschalle: mcatanzaro: right.
14:02:00 <mcatanzaro> kalev, is that right?
14:02:09 <juhp[m]> mcatanzaro: can't we just change the URL in the repo file? 😬
14:02:15 <mclasen> kwizart: nonsense
14:02:27 <rdieter> juhp[m]: that would be unwise (fragile)
14:02:28 <kwizart> mclasen, fedora is nonsense ?
14:02:39 <stickster> kwizart: I thought the community review is by this WG ;-)
14:02:57 <stickster> cschalle: ^ tell me if I'm misunderstanding how the policy works, it's been a while since I read it
14:03:08 <mcatanzaro> kwizart: Looks like everyone agrees the long-term solution is RPMFusion... that's not what I was expecting! I would be happy with this result if I were you. :)
14:03:16 <kwizart> stickster, this is a general review, not a package review ? was a packager review held by some that was fully understanding the subject ?
14:03:19 <kwizart> no
14:03:48 <kalev> mcatanzaro: yes, I believe so
14:04:11 <rdieter> I think we (worktation WG) can wash our hands of this, formally vote on accepting rpmfusion if they can provide specifically what is asked-for.
14:04:23 <kwizart> negativo is still conflicting with rpmfusion drivers, that's the point of using rpmfusion in the first step
14:04:42 <kwizart> rdieter, everything is up and running now
14:05:02 <mcatanzaro> Well we're over time
14:05:03 <rdieter> kwizart: rpmfusion has a nvidia-only repo?
14:05:08 <stickster> mcatanzaro: yes, well so
14:05:09 <kwizart> the conflict is negativo (miss-design), we cannot fix it
14:05:37 <stickster> Let's take this to #fedora-workstation
14:05:48 <stickster> I don't think anyone has this room after us, but we are overtime here
14:05:49 <kwizart> sure
14:05:56 <rdieter> ok
14:06:26 <stickster> #info Need to resolve the question of repo to carry, whether to do for F28/F29, possible update path issues
14:06:32 <stickster> Thank you for coming everyone
14:06:37 <mcatanzaro> Bye!
14:06:40 <stickster> #endmeeting