14:00:13 <stickster> #startmeeting Workstation WG
14:00:13 <zodbot> Meeting started Wed Jul 20 14:00:13 2016 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:13 <zodbot> The meeting name has been set to 'workstation_wg'
14:00:17 <stickster> #meetingname workstation
14:00:17 <zodbot> The meeting name has been set to 'workstation'
14:00:22 <stickster> #topic Roll call
14:00:24 <stickster> .hello pfrields
14:00:25 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
14:04:38 <stickster> cschalle: kalev-afk-travel mclasen___ rdieter rdieter_work juhp -- ping
14:04:54 <cschalle> pong
14:05:21 <stickster> cschalle: I expect people are still getting here from other meetings (like the one I just came from) ;-)
14:07:28 * cprofitt waves that he is here
14:08:06 * mcatanzaro late
14:08:10 <stickster> o/
14:08:13 <stickster> #chair cschalle mcatanzaro
14:08:13 <zodbot> Current chairs: cschalle mcatanzaro stickster
14:08:26 <mcatanzaro> Just us three?
14:08:33 <stickster> We're still waiting on a few people, probably because there was a meeting some of us just got out of at the same time a couple minutes ago
14:09:10 <otaylor> sorry to be late
14:09:10 <mcatanzaro> OK then. (mclasen___, rdieter rdieter_work)?
14:09:13 <stickster> cschalle: Maybe we should go ahead with our bit
14:09:18 <stickster> o/ Owen
14:09:19 <mclasen___> .hello
14:09:19 <zodbot> mclasen___: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
14:09:20 <stickster> #chair otaylor
14:09:20 <zodbot> Current chairs: cschalle mcatanzaro otaylor stickster
14:09:23 <stickster> #chair mclasen___
14:09:23 <zodbot> Current chairs: cschalle mcatanzaro mclasen___ otaylor stickster
14:09:28 <mclasen___> .hello mclasen
14:09:29 <zodbot> mclasen___: mclasen 'Matthias Clasen' <mclasen@redhat.com>
14:09:40 <otaylor> .hello otaylor
14:09:41 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
14:09:43 <cschalle> .hello cschalle
14:09:44 <zodbot> cschalle: Sorry, but you don't exist
14:09:54 <stickster> existential crises are a bummer
14:10:34 <stickster> cschalle: let's do our bit first to give mclasen___ time to collect thoughts/info/coffee
14:10:42 <stickster> #topic Update on third party software policy discussion
14:10:44 <Southern_Gentlem> .hello jbwillia
14:10:44 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@yahoo.com>
14:10:58 <cprofitt> .hello cprofitt
14:10:59 <stickster> #link https://fedorahosted.org/council/ticket/57
14:10:59 <zodbot> cprofitt: cprofitt 'Charles Profitt' <fedora@cprofitt.com>
14:12:32 <stickster> So the good thing is the Council has made it past some of their budget and other planning discussions, and has started to address this policy, and mattdm provided a proposal in the ticket. However I see hughsie has some (valid) concerns about what it's asking for
14:13:19 <mcatanzaro> They are minor concerns though; hughsie is asking about details, but it looks like mattdm's major requests are all fairly close to what we already have.
14:13:50 <stickster> Some of it is -- it's hard to tell whether mattdm has tried the latest Software to see how close the experience is
14:15:16 * stickster wonders if anyone else is paying attention here :-)
14:15:57 <stickster> One thing that might help is a screenshot tour since I doubt a ton of people will go off and install Rawhide to get answers.  I could take on the task of doing that, shouldn't be too time-consuming
14:16:02 <mcatanzaro> The biggest issue is that mattdm wants nonfree results to be hidden by default; I think it's fine to just have the current nonfree labels, they work pretty well. Maybe the wording about use of nonfree software could be tightened a bit.
14:16:21 <mcatanzaro> Don't need to install rawhide, I think F24 would probably suffice.
14:16:42 <stickster> mcatanzaro: hughsie recommended trying 3.21.4 which is in Rawhide only AFAIK
14:16:50 <mcatanzaro> OK then :)
14:17:03 <stickster> Maybe I could update to it, but not sure what would break :-)
14:18:01 <stickster> cschalle: Anything you wanted to bring up here? If not I guess I'll just take the #action and we move on
14:18:45 <cschalle> yeah, got nothing extra here, waiting to see if a wider part of the community will end up chimming in, but in general I Think the level of controvery here has greatly diminshed
14:18:58 <mclasen___> I'm concerned about the level of detail at which this is negotiated
14:19:10 <mclasen___> we can't really have button placement decisions go through the council...
14:20:11 <stickster> mclasen___: I second that, which is why I think the labeling is a good approach. However, I'm willing to put some time into a tour that shows how this works in practice, so we can set some minds at ease. I think hughsie's point about what happens when someone searches for e.g. Chrome is a particularly important one
14:20:26 <mclasen___> right
14:20:46 <mclasen___> I need to reread the ticket to have more informed opinions (just back from travel this morning)
14:20:48 <mcatanzaro> Well when the user searches for Chrome, we obviously want to show Chrome.
14:21:00 <stickster> mclasen___: sure, np
14:21:26 <mcatanzaro> All else equal, we should weight nonfree lower in the search results, but that doesn't mean showing bad free results on top of what the user is actually searching for. Name matches should always take precedence.
14:21:27 <stickster> #action stickster make a screenshot tour or video to show what happens in Rawhide
14:23:10 <stickster> Yeah, that sounds reasonable to me too
14:23:25 <stickster> Moving on so we can avoid spinning wheels this hour
14:23:41 <stickster> #topic Installer story for new Workstation bits
14:24:01 <mcatanzaro> This is the ostree installer?
14:24:04 <stickster> mclasen___: did you want to update here? I know you've been gone for a bit, sorry to drag you to podium first thing :-)
14:25:02 <mclasen___> yeah, I don't really have an update at hand; I did ask David for a status update before I left, but haven't seen one yet (maybe deep in my inbox somewhere)
14:25:41 <mclasen___> I have a few other updates
14:25:54 <mclasen___> colin has set up a jenkins job here: https://ci.centos.org/job/atomic-fedora-ws/
14:26:04 <stickster> I think one thing to note is that when I last tuned into this stuff, the ostree installation part actually should work already IIRC
14:26:09 <mclasen___> which builds an atomic workstation image based on our config
14:26:15 <stickster> or rather, the ability to install from ostrees *in general*
14:26:18 <mclasen___> with a recent rpm-ostree in it that supports package layering
14:26:54 <mclasen___> stickster: yes, anaconda does support atomic installation; so in theory it is just putting the pieces together, which is what I want to get confirmed by David
14:27:08 <stickster> mclasen___++
14:27:45 <mclasen___> I've asked hughsie to use that jenkins build to test the gnome-software support for ostree updates and flatpak installation
14:29:34 * stickster not sure how to read that Jenkins page, but will figure it out later unless someone has a pointer/URL handy
14:29:48 <mclasen___> oh, wait, I have a better link, I think
14:30:31 <mclasen___> https://pagure.io/fork/walters/workstation-ostree-config/branch/f24-continuous
14:31:10 <stickster> Oh, that's helpful, thanks mclasen___
14:31:43 <stickster> #info Jenkins job is setup to build atomic-based workstation edition
14:31:49 <stickster> #link https://ci.centos.org/job/atomic-fedora-ws/
14:33:40 <stickster> I'm not sure where we are on flatpak or other "container on top" stuff -- mclasen___, is it generally expected that whatever this latest rpm-ostree does, is compatible somewhat generically?
14:34:34 <mclasen___> yes, I expect that it is; but then thats what I am asking hughsie to put to the test
14:34:48 <stickster> *nod
14:34:53 <otaylor> stickster: the rpm layering stuff is something separate and different
14:36:05 <stickster> otaylor: Hm, OK -- I would expect that Docker containers et al. would work on top of the rpm-ostree, though, since that was one of the primary use cases for an Atomic host in general
14:36:27 <otaylor> stickster: yes, it doesn't in any way restrict the ability to use flatpaks and docker containers
14:36:28 <stickster> whereas RPM layering is somewhat more complicated
14:36:38 <stickster> ok, good to know, thanks otaylor
14:36:53 <otaylor> and that's what we need to design around for user experience (IMO) - rpm layering is more of an escape hatch
14:37:13 * stickster not sure what else to state here, I think next step is just as Matthias said, which is to check in with David to see where his work stands and report to list
14:37:30 <stickster> mclasen___: anything else you wanted to point out?
14:38:01 <mclasen___> nothing atm
14:38:21 <stickster> OK, thanks for the discussion mclasen___ !
14:38:45 <stickster> #topic Maps tile outage
14:39:03 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1356484
14:39:27 <mcatanzaro> For this, it would be really nice to have an upstream solution rather than a Fedora-specific solution.
14:39:59 <andreasn1> it's in the works
14:40:09 <mcatanzaro> I see some action in the upstream bug as recently as yesterday; maybe we don't need to do anything.
14:40:13 <andreasn1> a couple of different providers have reached out
14:40:30 <stickster> This is already under some discussion in GNOME upstream but I think there are a couple things we should note for Workstation purposes; one of them being status of this app in our default install -- i.e. knowing that there's a solution in place in order to have this in our default (I believe it's not at the moment)
14:40:46 <mcatanzaro> stickster: No, it is installed by default.
14:40:51 <andreasn1> and offered 6 months to 1 year things for free, so it's like a temporary fix
14:41:01 <mclasen___> the maps team is actively looking for alternatives (obviously somewhat pressing, since this breaks all released versions of maps)
14:41:25 <mcatanzaro> andreasn1: OK, so the maps folks are only looking into short-term solutions, and we need to set up our own tile server regardless?
14:41:32 <stickster> mcatanzaro: Oh, I thought my F24 install here was by default and yet I didn't have it -- but it's possible I did something along the way
14:41:36 <mclasen___> the long term solution is probably to stop relying on tile servers and do client-side rendering from osm data
14:41:42 <andreasn1> mcatanzaro: no, long term as well
14:42:52 <mcatanzaro> andreasn1: What action is required from Fedora? Do we need to work with upstream to set up a tile server for GNOME, or is upstream handling it and we can expect the service outage to end soon?
14:42:52 <andreasn1> marcus lundblad said he wanted to backport the fix to earlier releases, but maybe he needs help for older version. Not sure what version RHEL7 uses
14:42:57 * otaylor hopes that whatever long term solution is taken upstream a) there will be no harcoding of non-gnome.org URLs into the code b) we end up with knowledge of what sort of usage is being seen
14:43:31 <andreasn1> otaylor: yeah, I think th plan is to set up a proxy that goes via gnome.org somehow
14:43:36 <mclasen___> part of the short-term discussion has been to get a proxy in place on gnome.org
14:44:00 <andreasn1> and yeah, usage data load is what every single provider asked for, and mapquest couldn't get us that data
14:44:34 <andreasn1> mcatanzaro: jonas and mattias is looking into it, but they probably appreciate a hand
14:44:41 * stickster ponders service that is setting up tier plan based on no data  o_O
14:45:29 <andreasn1> and longer plan, it we want to switch to vector tiles, no idea if that affects server load or not though
14:46:21 <andreasn1> so yeah, quite embarrising overall that mapquest pulled the rug under our feet :/
14:46:32 <andreasn1> and that we didn't see that coming
14:46:39 <stickster> It does sound to me like GNOME is actively working on solving the problem though -- and that it's not going to be helpful for Fedora to do something different or duplicative downstream right now
14:46:54 <otaylor> stickster: No, I don't think so.
14:47:40 <mcatanzaro> I wonder if anyone from Fedora infrastructure team is available to assist with this. I just checked comps to confirm and indeed gnome-maps is installed by default.
14:47:41 <stickster> otaylor: sorry, was that agreeing or disagreeing? :-)
14:48:04 <otaylor> stickster: That was agreeing with you
14:48:10 <stickster> otaylor: OK, I was hoping so :-)
14:48:16 <andreasn1> stickster: yeah, sounds about right
14:48:36 <otaylor> mcatanzaro: I dont' think Fedora infrastructureis going to be any happier with a blank check...
14:48:53 <stickster> otaylor++
14:49:30 <mclasen___> andreasn1: it was announced in advance, and we knew about it, if you read the upstream bug
14:49:31 <andreasn1> oh, and the faster the backports can be packaged for fedora 22/23/24, once the fix is in, the better
14:49:37 <mclasen___> its just that nobody acted in time
14:49:44 <andreasn1> yeah
14:49:47 <otaylor> mcatanzaro: We could set something on GNOME or Fedora infrastructure temporarily to test the waters but it would have to be monitored, and willing to turn it off it turns out to be serving non-moderate amounts of data
14:51:04 <otaylor> mcatanzaro: but if someone else is willing to temporarily serve while we collect usage data, I don't see any advantage to that
14:52:10 <mcatanzaro> andreasn1: We can have backports out to F23/F24 within a day of upstream releases (just ping me or kalev) so that's not a problem. F22 is EOL.
14:52:12 <mclasen___> from a 'doing the right thing' perspective it might be nice to donate some hw/bw/money to osm, if we're using their resources
14:52:37 <stickster> mclasen___: that's a good point, probably would need to run through OSAS for that
14:52:45 <andreasn1> mcatanzaro: nice. Oh, right, it's EOL
14:52:48 <stickster> or at least would be a first step
14:54:34 <stickster> It's a bit annoying that MQ couldn't help with sizing the load at all.  If we want to ask Fedora Infra to serve something, at a minimum it'd need to (1) live on the OpenStack cloud with limited/no SLA; (2) be set up, maintained, and monitored by GNOME folks; (3) start with https://fedoraproject.org/wiki/Request_For_Resources
14:54:34 <andreasn1> Marble for KDE is able to use osm tiles directly apparently, because their usage of the osm tiles directly is a lot older than the guidelines for external projects to not rely directly on the OSM servers
14:54:35 <mcatanzaro> mclasen___: Do you have funding for it? I bet OSM could make our problem go away, but we don't know how much they'd want, do we?
14:54:57 <andreasn1> and if one ask OSM nicley, it's possible to use their servers directly
14:55:06 <mclasen___> cschalle is the guy with the money bags
14:55:26 <andreasn1> (I think)
14:55:30 <mcatanzaro> Probably should use money bags as a last resort, anyway.
14:55:45 <stickster> What should our next action be here, then?
14:56:04 <mcatanzaro> Anyway, there is upstream progress as of yesterday, let's defer this issue to the next meeting and revisit based on what upstream does in the next two weeks.
14:56:25 <andreasn1> sounds good
14:56:40 <mcatanzaro> Understanding that this is a critical issue with a default app, and we want a short term solution ASAP if not much happens before the next meeting.
14:56:59 <stickster> mcatanzaro: agreed
14:57:38 <stickster> #action defer this until next meeting while we watch GNOME upstream, which is already actively addressing the issue and we hope will have a short term solution that can go into F23/24
14:57:45 <stickster> #topic All other business (open floor)
14:57:49 <jkurik> Hi
14:57:56 <jkurik> I just would like to check whether there are any plans to do changes in PRD ?
14:57:57 <jkurik> or whether the WG is fine with the current varsion of it ?
14:58:18 <mcatanzaro> Hi jkurik, we haven't discussed any changes so I guess it's considered fine.
14:58:28 <stickster> jkurik: I don't think we've looked at updating the PRD yet, would need to discuss on list but we should be able to do so before Flock
14:58:45 <stickster> the answer may be "no changes" but would be worth a look
14:59:16 <jkurik> ok, thanks for the info
14:59:18 <stickster> #info PRD changes -- will discuss on list and be able to report back by Flock
14:59:41 <stickster> One thing to point out here -- kalev tells me the gnome-software update that allows F23->F24 upgrades has been finally OK'd and should go out soon
14:59:46 <stickster> \o/
14:59:48 <mcatanzaro> \o/
15:00:01 <mcatanzaro> stickster you asked a while back about default apps for F25. The only change I propose is shotwell -> gnome-photos, which has been discussed thoroughly already
15:00:03 <stickster> #info gnome-software update for F23 should go out soon
15:00:05 <stickster> #link https://bodhi.fedoraproject.org/updates/FEDORA-2016-fad11727bf
15:00:29 <stickster> mcatanzaro: Let's revive that on list, should be able to put it to bed there
15:00:32 <mcatanzaro> Unfortunately none of the other upcoming apps are feeling ready to me.
15:00:40 <mcatanzaro> Yeah, OK
15:00:46 <stickster> #action mcatanzaro revive F25 default apps on list (basically, shotwell -> gnome-photos)
15:00:54 <stickster> and with that, I'll close on time if no one objects
15:01:15 <stickster> OK then
15:01:16 <stickster> #endmeeting