14:00:04 <stickster> #startmeeting Workstation WG
14:00:04 <zodbot> Meeting started Mon Feb 27 14:00:04 2017 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:04 <zodbot> The meeting name has been set to 'workstation_wg'
14:00:06 <stickster> #meetingname workstation
14:00:06 <zodbot> The meeting name has been set to 'workstation'
14:00:07 <stickster> #topic Roll call
14:00:14 <stickster> .hello pfrields
14:00:15 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
14:00:16 <mcatanzaro> .hello catanzaro
14:00:18 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org>
14:00:22 <x3mboy> .hello x3mboy
14:00:23 <zodbot> x3mboy: x3mboy 'Eduard Lucena' <eduardlucena@gmail.com>
14:00:32 <juhp> .hello petersen
14:00:33 <zodbot> juhp: petersen 'Jens Petersen' <petersen@redhat.com>
14:01:18 <mclasen> .hello mclasen
14:01:19 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com>
14:01:46 <stickster> #chair mcatanzaro juhp mclasen cschalle_
14:01:46 <zodbot> Current chairs: cschalle_ juhp mcatanzaro mclasen stickster
14:02:29 <stickster> we are also awaiting otaylor so he can speak a little to the flatpak issue. After we cover the initial items, mclasen included the ostree WS topic and we can go into that as well
14:02:52 <kalev> .hello kalev
14:02:53 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
14:02:55 <stickster> #info meeting will end at :55 so chair can get to next meeting :-)
14:02:58 <stickster> #chair kalev
14:02:58 <zodbot> Current chairs: cschalle_ juhp kalev mcatanzaro mclasen stickster
14:05:01 <stickster> #chair otaylor
14:05:01 <zodbot> Current chairs: cschalle_ juhp kalev mcatanzaro mclasen otaylor stickster
14:05:23 <stickster> #topic Flatpak production
14:05:28 * stickster turns mic over to otaylor
14:05:50 <otaylor> OK - so a quick status report on building flatpaks
14:06:16 <otaylor> The goal of the project is to build flatpaks from fedora rpm content
14:06:55 <otaylor> So it's not a new branch in how we import and build source in Fedora but rather more of a repacking existing content
14:07:37 <otaylor> and the point of that is to get as many flatpaks as soon as possible - even of applications that are no longer actively developed upstream and might not be packaged as flatpaks by the upstream authors
14:08:20 <otaylor> In one sense, it's pretty similar to server side containers - taking packages, putting them into aggregated filesystems, shipping that
14:08:33 <otaylor> But there are a couple of wrinkles that make it different and (in some ways) trickier
14:08:59 <otaylor> The main issue is the split in flatpak between /usr and /app
14:09:14 <otaylor> There is a "runtime" that has files in /usr shared between many applications
14:09:39 <otaylor> But the "application" is in "/app" and this is not just the app rpm, but all the files in bundled libraries that aren't in the runtime
14:10:01 <otaylor> So the application and the bundled libraries need to be rebuilt with a different rpm configuration to build with PREFIX=/app
14:10:38 <otaylor> this is a piece that doesn't exist with server side apps - the split between /usr and /app gives some strong benefits, but makes the process more difficult
14:11:28 <otaylor> Right now, the status is that we've prototyped and tried things a couple of different ways, but aren't yet developing on something that we think will be the final way
14:11:46 <otaylor> there are still some major decisions to be made
14:12:03 <otaylor> The most important is probably to decide whether we make a module per application or not
14:12:35 <mclasen> do we know how that is decided on the docker side ?
14:12:37 <otaylor> Having a module per application would allow maintainers a lot of flexiblity, but the added overhead would really make things a lot more complicated
14:12:51 <otaylor> for packagers
14:13:35 <stickster> the complication I assume comes in the form of needing to locate/notate/include all the deps for the flatpak bundle?
14:13:37 <otaylor> mclasen: No, I don't - my next goal is to track down langdon and see what details I can get from him for module vs. container plans in there current state
14:14:23 <mclasen> ok
14:14:47 <mclasen> question from the audience: can't most of the module definition data be derived programmatically from the runtime package list and the app package dependencies ?
14:14:47 <otaylor> stickster: Well, the complication is that suddenly you have to maintain apackage set - say "I want version 3.22 of gtksourceview in my gedit bundle, and version 2.1 of libsourcecodehighlight"
14:14:58 <otaylor> stickster: and have to deal with understanding module metadata to handle that
14:15:16 <stickster> I think we're saying the same thing in different ways, so yeah -- understood
14:15:48 <otaylor> mclasen: Yes, think you can go pretty far on an automated levell
14:16:30 <otaylor> mclasen: But that's not the way we are going with modules, and not the goal of modules - the goal of modules is that if you are depending on version 2.1 of libsourcecodehightlight, you won't end up with version 2.2 in your module unless you choose to
14:16:54 <stickster> It's a given that there's going to be more disk eaten up in that model on the consumer side, so depending on how the module model works, we should also be explicit with the user community that the Workstation is meant to be run somewhere you don't have to be stingy about disk
14:16:55 <mclasen> I see
14:17:05 <cschalle_> otaylor, seems to me going the module route is probably more ongoing work than what we would want for this effort
14:17:18 <mclasen> so maybe the automation would be more a 'setup-flatpak-module' script
14:17:26 <cschalle_> ?
14:17:41 <otaylor> cschalle_: on going work on the infrastructure side or on the packager side/
14:17:52 <kalev> for an initial implementation it would probably make sense to just mirror the exact contents of rpms, so that it would always use the same library versions as rpms do etc
14:17:54 <mcatanzaro> Maybe trying to make "modular" flatpaks should be a non-goal... we can't have 10 different versions of the same flatpak depending on which modules you want installed, that's unmaintainable.
14:18:24 <mclasen> but we can, and it is more true to the goals of flatpak
14:18:25 <mcatanzaro> I was expecting this to be more like what kalev suggests.
14:18:25 <otaylor> mcatanzaro: flatpaks would be 1:1 with modules - it's not like they would be compoable
14:18:39 <mclasen> but maybe not right in terms of getting many flatpaks done with minimal overhead
14:18:55 <mcatanzaro> Maybe I'm misunderstanding something.
14:18:56 <stickster> Nor in getting those flatpaks to become more universal
14:19:15 <stickster> Oh wait, maybe it wouldn't hurt that goal, if the bundling still happens
14:19:18 <cschalle_> otaylor, packager side I guess. My point is that the module setup is what I would suppose is the 'correct' way to do a flatpak if you are a maintainer offering your own flatpak, but for us autogenerating 500 flatpaks it seems to be pretending to maintain these as individual flatpaks instead of the reality of them being autogenerated packages from a rpm repository
14:19:19 * stickster retracts
14:19:39 <otaylor> mcatanzaro: the question is essenetially whether you have fedora 26 and fedora 27 flatpaks of the gimp, or whether you have gimp-2.8 and gimp-2.9 flatpaks
14:19:47 * stickster thinks it's a lot easier to talk about this stuff in details rather than abstractly
14:20:51 <stickster> If the goal is to make flatpaks a solid standard in the ecosystem, I would think you'd need to target the latter... gimp-2.8 and gimp-2.9
14:20:51 <kalev> otaylor: the former sounds like something that can be automated, the latter not so much
14:22:13 <mclasen> of course, if you build from rpms, then you will have to choose one release stream to pick them from, so even if you build a gimp-2.8 flatpak, it will be gimp-2.8-using-f26-rpms
14:22:27 <mclasen> but there's no good reason to then go and build a gimp-2.8-using-f27-rpms
14:22:28 <otaylor> stickster: I dont' expect the gimp maintainers to come and maintain their flatpaks within fedora dist-git - making fedora the only place to build a flatpak is not the goal  - so the gimp-2.8 and 2.9 would still be "downstream" - though perhaps if they were good enough, the gimp developers would just say "use the Fedora flatpaks, we consider them the best way to install the GIMP" (this is all hypothetical)
14:22:34 <mclasen> just because f27 was released
14:22:46 <cschalle_> I think I am with kalev here,so while I agree with stickster etc. that doing the latter makes some sense from a flatpak perspective it seems to be a painful route to take in terms of the infrastructure we are building on top of here
14:23:02 <stickster> otaylor: makes sense
14:23:25 <stickster> right, I don't disagree with kalev about the automation side
14:23:44 <otaylor> It's a real goal to keep it *simple* for the packagers, so my intention right now is to figure out how simple we can make it in the 'just rebuild the current streams into flatpaks, no modules' setup, and see if we can menaingfullly do that without reinventing modules in another name
14:24:11 <otaylor> and simultaneously find out more about what our container vs. module story is
14:24:20 <kalev> that makes a lot of sense to me
14:24:38 <stickster> otaylor: *nod... and hopefully we can reuse the paradigm (ugh, sorry) for other types of add-ons (modules/containers/etc.)... with, for example, a folder and/or metadata in dist-git
14:24:40 <otaylor> I think we can start off in the f26-gimp and then make it possible to extent that to  gimp-29-module-gimp later
14:25:15 <juhp> seems reasonable
14:25:48 <stickster> One thing to know going in is that for the most part it seems like creation of artifacts works best when we just do it in koji. This means eventually creating a koji plugin to do flatpak building
14:25:54 <otaylor> stickster: Yeah - I'm not sure if another dist-git namespace maeks sense compared to just dropping things alongside in /packages/ - I Think the parallel branch structure for tests was done for size reasons?
14:26:21 <stickster> I'm not sure we're keeping a namespace for tests
14:26:56 <otaylor> stickster: ok, that was what I heard last - another namespace but with the same branches as packages, but maybe that changed
14:27:05 <juhp> Would it be confusing to use the same namespace - at least it would need some naming convention?
14:27:13 <juhp> Wouldn't *
14:27:24 <stickster> It would need a naming convention but this is all bikeshed painting
14:28:05 <otaylor> juhp: "same namespace" -  you'd just drop gimp.json next to gimp.spec in the same branch with extra metadata
14:28:08 <mclasen> the main thing we need, really, is an agreement with the buildsystem maintainers about the shape of this, so we can write patches that they will accept
14:28:16 <kalev> I think I'd prefer putting it in the same dist git for initial implementation, just because otherwise a lot of maintainers are going to ignore flatpaks if they are separate
14:28:20 <juhp> Could the flatpak rpms also be installable?
14:28:26 <mcatanzaro> otaylor: regarding "the question is essenetially whether you have fedora 26 and fedora 27 flatpaks of the gimp, or whether you have gimp-2.8 and gimp-2.9 flatpaks". I would expect that, for applications that are not released as flatpak by upstream, releasing fedora 26 and fedora 27 flatpaks for gimp would be much easier, right? I don't see why we would want *Fedora* to maintain gimp-2.8 and gimp-2.9 flatpaks. That would be good fo
14:28:28 <mcatanzaro> r upstream to do.
14:28:40 <stickster> otaylor: You're right, but I think it was done for proof of concept reasons... and that after reflection there are many folks who think it's going to complicate other pieces of the production pipeline... in any case, not worth worrying about here as a blocker, we should simply track and fall in line with the accepted standard
14:28:51 <mclasen> and we don't get sent around to factory 2.0 again
14:29:15 <kalev> if there's a need to mass upstream flatpak fixes to fedora dist git, I'm happy to help do that with provenpackager access
14:29:31 <otaylor> mclasen: yes, agreed.
14:29:43 <otaylor> juhp: that generally doesn't make sense - other than as part of a flatpak
14:29:52 <juhp> okay
14:30:05 <stickster> mclasen: yes, we can expect little time on factory 2.0 team side to help here
14:30:15 <stickster> by which I mean "none"
14:30:19 <otaylor> juhp: ifwe're just rebuilding f26 rpms, then you would use the unrebuilt ones. And if we went module-stly,e then the dependencies of different apps would conflict
14:30:35 <mcatanzaro> "factory 2.0"?
14:31:02 <stickster> mcatanzaro: https://fedoraproject.org/wiki/User:Ralph/Drafts/Infrastructure/Factory2
14:31:43 <stickster> otaylor: So what are next steps here? We need to move on to other agenda items
14:32:33 <otaylor> stickster: Next step is for me to write up a straw man for how the no-module approach would look, and get he infrasructure team to review, and then decide the module vs. no-module question, and move on to figuring out what needs to be implemented and where the resources for that come from
14:33:26 <stickster> #info wide ranging discussion in the meeting log, recommend people read that since it's not easy to capture in simple meeting minutes
14:34:25 <stickster> #action otaylor write up straw man for flatpaks not using the module approach; drive discussion with infra team; decide on modules/no-modules, then move to figuring out implementation details and where to find people/time to do the work
14:34:39 <stickster> OK. anything else here before we move on, then?
14:35:06 <stickster> #topic Workstation features F26/F27
14:36:05 <stickster> Point of this topic is that we need to have some story around the distinguishing features of Fedora Workstation for F26/F27... ostree basis + flatpak is certainly one but not the only story
14:36:28 <stickster> i.e. over and above "we have new improved GNOME" (regardless of how nice that continues to be) ;-)
14:38:02 <mclasen> I hope we will deliver mixed hidpi support in wayland, that was ready for review last I checked
14:38:33 <x3mboy> !
14:38:44 <mclasen> we also have fully fleshed out wacom support in wayland
14:38:47 <stickster> for instance... shipping the Workstation in a new model is nice, but what about tools inside the platform, and resources on the web to help developers make use of them
14:39:22 <stickster> mclasen: that wacom bit is nice to hear, from a personal POV... will be nice to use my drawing tablet under Wayland :-)
14:39:31 <cschalle_> jeischma is also talking with the jboss people to see if we can get the jboss studio available for F26
14:39:34 <mclasen> I hope it works :-)
14:39:38 <stickster> lol
14:40:03 <cschalle_> and by F27 if not sooner we should have out of the box Steam support
14:40:45 <x3mboy> I'm kind of new with workstation SIG, but I work with marketing team, and it's always a requirement to collect screenshots from each release. Since this SIG works directly with the desktop, it will be possible to ask for collecty screenshots in some site, that helps marketing team to collect this a little faster?
14:41:05 <mclasen> we will also ship a working ide for flatpak development (gnome builder)
14:41:09 <stickster> x3mboy: I believe the Marketing team has collected screenshots in the wiki for previous releases.
14:41:10 <mcatanzaro> I guess we can take screenshots from GNOME release notes
14:41:29 <stickster> x3mboy: https://fedoraproject.org/wiki/Marketing/F25_Screenshots?rd=F25_screenshots_library
14:41:30 <mcatanzaro> Which will be available at the end of March
14:41:36 <cschalle_> mcatanzaro, we just need to make sure any screenhots we use got the fedora branding etc.
14:41:52 <mclasen> gnome builder will also support rust, which might get some people excited
14:41:54 <mcatanzaro> Good point; they can be used for inspiration at least
14:42:29 <stickster> x3mboy: I think the key is the Marketing team generally has done those screenshots, since most of the WS folks here are busy building features themselves
14:42:55 <x3mboy> stickster, ok, sorry, I was out of scope then
14:42:58 <stickster> since the work is not highly technical and can be done in VMs by any contributor with a little spare time and some bandwidth to download the test release
14:43:09 <stickster> x3mboy: it's ok, it's a fair question to ask :-)
14:43:16 <cschalle_> we should probably also announce the improved hybrid graphics support even if part of that is going into F25
14:43:35 <cschalle_> hybrid graphics for Wayland should also be done for F26 or F27 at latest
14:43:43 <stickster> x3mboy: I would suggest working with the Marketing team to make sure this task is part of the schedule around the release
14:43:58 <cschalle_> a little bit more unsure at this point in time where HDR support will arrive
14:43:58 <x3mboy> stickster, I do :D
14:44:15 <stickster> cschalle_: I guess I'm still pining for a bigger story that ties things together with a focus on the developer target
14:44:36 <stickster> But certainly all these features do sound good
14:44:50 <cschalle_> stickster, yeah, only thing I can clearly think of there is that we do a concerted effort to bring a major batch of new devtools in, like JBoss Studio etc.
14:45:13 <stickster> #info reminder that we will have a call for F26 Talking Points coming in the next ~month
14:45:46 <stickster> OK, no need to drive this topic into the ground... moving on
14:45:54 <stickster> #topic Performance tuning follow-up
14:45:59 <stickster> #link https://pagure.io/fesco/issue/1684
14:47:16 <stickster> So the prevailing opinion was that a storage scheduler change needs to be based on some results from at least a sample of workloads we're trying to benefit.
14:47:24 * mclasen thinks the people who suggested the change should maybe provide supporting evidence
14:47:38 <stickster> This needs an owner with time to write those down and do the work
14:48:26 <mcatanzaro> I suggested the change, but it won't happen if you expect me to own it, sorry. :(
14:49:00 <mclasen> what was the suggestion based on ? hearsay, or "ubuntu does it" or something else ?
14:49:03 <stickster> I think the door's open for an owner here, it doesn't need to be mcatanzaro, but it's a nontrivial change with a nontrivial testing requirement
14:50:16 <cschalle_> also if I remember correctly from the thread, aren't we using the other scheduler already on RHEL? that in itself is a pretty strong argument for using it
14:51:02 <stickster> We're probably defaulting to upstream. But with only 5 minutes left, I guess I wasn't intending to debate technical merit again on this
14:51:51 <stickster> suffice it to say, Fedora kernel team weighed in on the ticket and was looking for some benchmarking data that would show benefits/drawbacks of a change so we can anticipate how it affects general users
14:52:01 <stickster> If no one's doing that, we shouldn't expect a change
14:52:44 <stickster> #info topic on hold until we have an owner for the work
14:52:58 <mcatanzaro> mclasen: My suggestion was based on hearsay.
14:53:07 <mcatanzaro> Someone from the performance team already weighed in on the list.
14:53:18 <otaylor> Mmm, this tends to favor benchmarkable loads against interactive loads....
14:53:46 <otaylor> But it would be good to figure out what the appropriate benchmarks are
14:53:53 <mcatanzaro> Right, the point is to favor responsiveness rather than throughput, so if the benchmarks don't measure responsiveness they're useless.
14:54:15 <otaylor> And also the extent we care about spinning disks or not
14:54:40 <mcatanzaro> Anecdotally Ubuntu performs much better than we do under high I/O load, which is why I suggested this.
14:54:42 <stickster> We have 1 min left, mclasen, are you OK with continuing ostree WS discussion to next meeting?
14:54:49 <otaylor> because spinning vs. ssd is *extremely* different, and you can't optimize for one for IO while testing on the other
14:54:50 <mclasen> sure
14:55:02 <mcatanzaro> Give me a sec to find my link
14:55:10 * mcatanzaro can end the meeting
14:55:13 <stickster> I really want to get to it but clearly we don't have time today :-( ... however, we should keep discussion going on list since IMHO it's quite important
14:55:44 * stickster notes Jiri Hladky didn't weigh in on our list but we got some secondhand info, and we can get more data from him if needed
14:56:00 <stickster> That would be useful to pull into the ticket
14:57:07 <stickster> Maybe sesivany__ can help, I'll hit him up in IRC
14:57:13 <stickster> In the meantime, I need to run
14:57:14 <mcatanzaro> Ah yeah, I was looking for response from Jiri Hladky but apparently it never reached the list.
14:57:21 <stickster> So thanks for coming, everyone!
14:57:22 <mcatanzaro> "I briefly spoke with Jiri Hladky, the manager of the FS perf team in
14:57:22 <cschalle_> in terms of finding an owner maybe this could be owned by aruiz and his laptop enablement team
14:57:24 <mcatanzaro> Red Hat, and he says that deadline is clearly better for SSD. Results
14:57:26 <mcatanzaro> for rotating disks are mixed, but he'd still prefer deadline there,
14:57:28 <mcatanzaro> too. He can provide more detailed info if we need it."
14:57:45 <stickster> cschalle_: *nod
14:57:49 <stickster> #endm
14:57:49 <mcatanzaro> So we should follow up with performance team I guess.
14:57:51 <stickster> argh
14:58:16 <stickster> #endmeeting