14:00:04 #startmeeting Workstation WG 14:00:04 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:04 The meeting name has been set to 'workstation_wg' 14:00:06 #meetingname workstation 14:00:06 The meeting name has been set to 'workstation' 14:00:07 #topic Roll call 14:00:14 .hello pfrields 14:00:15 stickster: pfrields 'Paul W. Frields' 14:00:16 .hello catanzaro 14:00:18 mcatanzaro: catanzaro 'Michael Catanzaro' 14:00:22 .hello x3mboy 14:00:23 x3mboy: x3mboy 'Eduard Lucena' 14:00:32 .hello petersen 14:00:33 juhp: petersen 'Jens Petersen' 14:01:18 .hello mclasen 14:01:19 mclasen: mclasen 'Matthias Clasen' 14:01:46 #chair mcatanzaro juhp mclasen cschalle_ 14:01:46 Current chairs: cschalle_ juhp mcatanzaro mclasen stickster 14:02:29 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 .hello kalev 14:02:53 kalev: kalev 'Kalev Lember' 14:02:55 #info meeting will end at :55 so chair can get to next meeting :-) 14:02:58 #chair kalev 14:02:58 Current chairs: cschalle_ juhp kalev mcatanzaro mclasen stickster 14:05:01 #chair otaylor 14:05:01 Current chairs: cschalle_ juhp kalev mcatanzaro mclasen otaylor stickster 14:05:23 #topic Flatpak production 14:05:28 * stickster turns mic over to otaylor 14:05:50 OK - so a quick status report on building flatpaks 14:06:16 The goal of the project is to build flatpaks from fedora rpm content 14:06:55 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 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 In one sense, it's pretty similar to server side containers - taking packages, putting them into aggregated filesystems, shipping that 14:08:33 But there are a couple of wrinkles that make it different and (in some ways) trickier 14:08:59 The main issue is the split in flatpak between /usr and /app 14:09:14 There is a "runtime" that has files in /usr shared between many applications 14:09:39 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 So the application and the bundled libraries need to be rebuilt with a different rpm configuration to build with PREFIX=/app 14:10:38 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 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 there are still some major decisions to be made 14:12:03 The most important is probably to decide whether we make a module per application or not 14:12:35 do we know how that is decided on the docker side ? 14:12:37 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 for packagers 14:13:35 the complication I assume comes in the form of needing to locate/notate/include all the deps for the flatpak bundle? 14:13:37 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 ok 14:14:47 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 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 stickster: and have to deal with understanding module metadata to handle that 14:15:16 I think we're saying the same thing in different ways, so yeah -- understood 14:15:48 mclasen: Yes, think you can go pretty far on an automated levell 14:16:30 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 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 I see 14:17:05 otaylor, seems to me going the module route is probably more ongoing work than what we would want for this effort 14:17:18 so maybe the automation would be more a 'setup-flatpak-module' script 14:17:26 ? 14:17:41 cschalle_: on going work on the infrastructure side or on the packager side/ 14:17:52 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 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 but we can, and it is more true to the goals of flatpak 14:18:25 I was expecting this to be more like what kalev suggests. 14:18:25 mcatanzaro: flatpaks would be 1:1 with modules - it's not like they would be compoable 14:18:39 but maybe not right in terms of getting many flatpaks done with minimal overhead 14:18:55 Maybe I'm misunderstanding something. 14:18:56 Nor in getting those flatpaks to become more universal 14:19:15 Oh wait, maybe it wouldn't hurt that goal, if the bundling still happens 14:19:18 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 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 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 otaylor: the former sounds like something that can be automated, the latter not so much 14:22:13 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 but there's no good reason to then go and build a gimp-2.8-using-f27-rpms 14:22:28 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 just because f27 was released 14:22:46 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 otaylor: makes sense 14:23:25 right, I don't disagree with kalev about the automation side 14:23:44 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 and simultaneously find out more about what our container vs. module story is 14:24:20 that makes a lot of sense to me 14:24:38 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 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 seems reasonable 14:25:48 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 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 I'm not sure we're keeping a namespace for tests 14:26:56 stickster: ok, that was what I heard last - another namespace but with the same branches as packages, but maybe that changed 14:27:05 Would it be confusing to use the same namespace - at least it would need some naming convention? 14:27:13 Wouldn't * 14:27:24 It would need a naming convention but this is all bikeshed painting 14:28:05 juhp: "same namespace" - you'd just drop gimp.json next to gimp.spec in the same branch with extra metadata 14:28:08 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 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 Could the flatpak rpms also be installable? 14:28:26 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 r upstream to do. 14:28:40 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 and we don't get sent around to factory 2.0 again 14:29:15 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 mclasen: yes, agreed. 14:29:43 juhp: that generally doesn't make sense - other than as part of a flatpak 14:29:52 okay 14:30:05 mclasen: yes, we can expect little time on factory 2.0 team side to help here 14:30:15 by which I mean "none" 14:30:19 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 "factory 2.0"? 14:31:02 mcatanzaro: https://fedoraproject.org/wiki/User:Ralph/Drafts/Infrastructure/Factory2 14:31:43 otaylor: So what are next steps here? We need to move on to other agenda items 14:32:33 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 #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 #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 OK. anything else here before we move on, then? 14:35:06 #topic Workstation features F26/F27 14:36:05 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 i.e. over and above "we have new improved GNOME" (regardless of how nice that continues to be) ;-) 14:38:02 I hope we will deliver mixed hidpi support in wayland, that was ready for review last I checked 14:38:33 ! 14:38:44 we also have fully fleshed out wacom support in wayland 14:38:47 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 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 jeischma is also talking with the jboss people to see if we can get the jboss studio available for F26 14:39:34 I hope it works :-) 14:39:38 lol 14:40:03 and by F27 if not sooner we should have out of the box Steam support 14:40:45 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 we will also ship a working ide for flatpak development (gnome builder) 14:41:09 x3mboy: I believe the Marketing team has collected screenshots in the wiki for previous releases. 14:41:10 I guess we can take screenshots from GNOME release notes 14:41:29 x3mboy: https://fedoraproject.org/wiki/Marketing/F25_Screenshots?rd=F25_screenshots_library 14:41:30 Which will be available at the end of March 14:41:36 mcatanzaro, we just need to make sure any screenhots we use got the fedora branding etc. 14:41:52 gnome builder will also support rust, which might get some people excited 14:41:54 Good point; they can be used for inspiration at least 14:42:29 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 stickster, ok, sorry, I was out of scope then 14:42:58 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 x3mboy: it's ok, it's a fair question to ask :-) 14:43:16 we should probably also announce the improved hybrid graphics support even if part of that is going into F25 14:43:35 hybrid graphics for Wayland should also be done for F26 or F27 at latest 14:43:43 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 a little bit more unsure at this point in time where HDR support will arrive 14:43:58 stickster, I do :D 14:44:15 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 But certainly all these features do sound good 14:44:50 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 #info reminder that we will have a call for F26 Talking Points coming in the next ~month 14:45:46 OK, no need to drive this topic into the ground... moving on 14:45:54 #topic Performance tuning follow-up 14:45:59 #link https://pagure.io/fesco/issue/1684 14:47:16 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 This needs an owner with time to write those down and do the work 14:48:26 I suggested the change, but it won't happen if you expect me to own it, sorry. :( 14:49:00 what was the suggestion based on ? hearsay, or "ubuntu does it" or something else ? 14:49:03 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 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 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 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 If no one's doing that, we shouldn't expect a change 14:52:44 #info topic on hold until we have an owner for the work 14:52:58 mclasen: My suggestion was based on hearsay. 14:53:07 Someone from the performance team already weighed in on the list. 14:53:18 Mmm, this tends to favor benchmarkable loads against interactive loads.... 14:53:46 But it would be good to figure out what the appropriate benchmarks are 14:53:53 Right, the point is to favor responsiveness rather than throughput, so if the benchmarks don't measure responsiveness they're useless. 14:54:15 And also the extent we care about spinning disks or not 14:54:40 Anecdotally Ubuntu performs much better than we do under high I/O load, which is why I suggested this. 14:54:42 We have 1 min left, mclasen, are you OK with continuing ostree WS discussion to next meeting? 14:54:49 because spinning vs. ssd is *extremely* different, and you can't optimize for one for IO while testing on the other 14:54:50 sure 14:55:02 Give me a sec to find my link 14:55:10 * mcatanzaro can end the meeting 14:55:13 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 That would be useful to pull into the ticket 14:57:07 Maybe sesivany__ can help, I'll hit him up in IRC 14:57:13 In the meantime, I need to run 14:57:14 Ah yeah, I was looking for response from Jiri Hladky but apparently it never reached the list. 14:57:21 So thanks for coming, everyone! 14:57:22 "I briefly spoke with Jiri Hladky, the manager of the FS perf team in 14:57:22 in terms of finding an owner maybe this could be owned by aruiz and his laptop enablement team 14:57:24 Red Hat, and he says that deadline is clearly better for SSD. Results 14:57:26 for rotating disks are mixed, but he'd still prefer deadline there, 14:57:28 too. He can provide more detailed info if we need it." 14:57:45 cschalle_: *nod 14:57:49 #endm 14:57:49 So we should follow up with performance team I guess. 14:57:51 argh 14:58:16 #endmeeting