15:00:22 #startmeeting Workstation WG 15:00:22 Meeting started Wed Nov 25 15:00:22 2015 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:22 The meeting name has been set to 'workstation_wg' 15:00:24 #meetingname workstation 15:00:24 The meeting name has been set to 'workstation' 15:00:26 #topic Roll call 15:00:29 .hello pfrields 15:00:30 stickster: pfrields 'Paul W. Frields' 15:01:16 hello! 15:01:27 kalev: mclasen: cschalle_: ryanlerch: rdieter_work: o/ 15:01:34 * mclasen is here 15:01:36 yo 15:01:39 hola 15:01:44 \o/ 15:02:04 #chair kalev mchua cschalle_ rdieter_work 15:02:04 Current chairs: cschalle_ kalev mchua rdieter_work stickster 15:02:35 phracek: Are you around? 15:02:47 stickster: sure I am here. 15:02:53 excellent! 15:02:56 and hopefully prepared. 15:02:57 #chair phracek 15:02:57 Current chairs: cschalle_ kalev mchua phracek rdieter_work stickster 15:03:05 OK, we have quorum so let's get started 15:03:09 * otaylor is here too 15:03:12 #chair otaylor 15:03:12 Current chairs: cschalle_ kalev mchua otaylor phracek rdieter_work stickster 15:03:13 yay! 15:03:16 #topic Developer Portal 15:03:24 I should leave after 30 minutes let's say 15:03:55 We have a meeting regarding Fedora Developer Portal with our guys and feature issues are: 15:04:28 Include new section called: "Start a project" 15:04:52 Where you should be able to start a project from scratch like arduino, GUI application , Web application. 15:05:22 Another feature is to integrate it with fedora-hubs. 15:06:06 Content of Fedora Developer Portal is here: https://github.com/developer-portal/content 15:06:12 phracek: Is the intention that a developer would have downloaded Fedora Workstation, and could refer to the portal for more information? (perhaps not just starting a project, but also for ideas or to understand where to find docs, API help, etc.)? 15:06:28 stickster: No, of course. 15:06:50 * mcatanzaro apologizes for tardiness 15:06:58 #chair mcatanzaro 15:06:58 Current chairs: cschalle_ kalev mcatanzaro mchua otaylor phracek rdieter_work stickster 15:06:58 Portal is not targeting to Workstation. 15:07:38 stickster: It should be definitely used on Cloud and Server 15:07:46 phracek: The portal does assume a Fedora installation, though, correct? 15:08:07 as a sidenote here, I talked to matthew miller yesterday, and I promised to draft a policy document for 3rd party docs, basically a policy/howto for what you need to do as a 3rd party to be considered for inclusion in Software, I think hosting this document on the developer portal is probably a good idea 15:08:08 phracek: DO you mean that you are targeting non-Fedora (non-Linux) development systems? 15:08:18 stickster: Fedora installation is needed of course. 15:08:25 what does it mean to use it on a server ? I guess a developer would still use a workstation / laptop while developing stuff thats targeted at servers 15:08:38 s/3rd party docs/3rd party apps/ 15:09:33 I have meant Workstation, Cloud, Server editions. Like is mentioned on getfedora.org. 15:10:04 phracek: I guess what we are asking is what is sitting in front of the developer - they aren't sitting in front of a cloud or a server 15:10:08 otaylor: No. Only Fedora. No other systems are supported. 15:10:49 otaylor: I think it doesn't matter if developer use Cloud, Server or workstation. 15:11:49 Technically, it may not, since they can get the same tools; but in terms of how much we make the developer do before they can be productive, it could make a difference. 15:12:11 currently, it feels a bit like a recipes website to me - there's lists of commands I can run to set up certain things 15:12:18 stickster: Yes. But from my point of view I think that Server and Workstation are preferable. 15:12:37 do you think about integrating it a bit more tightly with the local system, like 1-click installs ? 15:12:43 I could not imagine how Cloud can be used from portal point of view. 15:13:03 jstribny: joined the meeting 15:13:06 I'm interested in finding out: What is the most efficient way we can connect a developer with the resources they need (whether docs, tools, or something else) 15:13:16 mclasen: what do you mean? 15:13:32 mclasen: Like click on icon and install worstation/cloud/server? 15:13:48 phracek: Well, click on an icon and install tool(s) needed for a procedure 15:14:06 mclasen: speak up if I misinterpreted, though 15:14:10 phracek, you usually run cloud variant in vagrant 15:14:16 stickster: Yeah, it could be be awesome. But we should specify a group for it. 15:14:27 stickster: no, you got it right 15:14:39 phracek: What do you mean by group? a dnf group? 15:14:43 re 1 click installs, I hacked up support for something similar in gnome-software for F24 15:14:53 have a 'install go' button on the website instead of a recipe for what to run 15:14:55 Install 0ad now opens up 0ad web page, for example 15:15:07 could do something similar for a random rpm as well, if there's need 15:15:18 stickster: E.g. Worstation (docker, vagrant, devassistant) Cloud (vagrant, docker), ... 15:15:22 err, opens up 0ad page in gnome-software, not web page 15:15:25 dnf not of course. 15:15:38 kalev: Would it be possible to do that with a set of objects so we don't either need more than one button, or have to continually add dnf metadata somewhere else? 15:15:40 kalev: Ironic that your method requires one-quarter as many clicks as our competitor's "one-click install." 15:16:06 stickster: I'm sure something is possible :) 15:16:27 kalev: like 'install [pkg1, pkg2, pkg3]' 15:16:32 Nowadays portal contains just static pages, but for future it can install packages on a system. 15:16:40 * stickster just pseudocoding here obviously, because well, he's stickster 15:17:22 phracek: Something to consider here is that if the developer isn't using a pre-installed system that supports the one-click, their experience would be... degraded 15:17:33 stickster: But your idea is awesome. Developers will install their languages/tools on their system. Really Awesome. 15:17:49 not my idea, it sounds like kalev was already all over it :-) 15:18:09 yeah i like the idea in general 15:18:12 I'll do a demo screencast, sec :) 15:18:45 * stickster not sure he is solving the issue that made us want to invite the Portal guys, but is happy with ideas/progress 15:20:03 We discussed the connection (or lack thereof) between the Portal and upstream docs like GNOME Developer Docs, which we don't want to rewrite, but would like a clear path for developers to find if they are writing native apps for Workstation 15:20:18 ^ mclasen, does that sound like a fair summary? 15:21:03 when we have start section /with how to start with gui apps/ i think we link GNOME Developer Docs there 15:21:10 yeah, would be good to get hear about ideas for integration existing upstream docs with more concrete fedora-specific instructions 15:21:37 not just for gnome stuff, I'm sure the same applies, to say, programming in go 15:21:47 true dat 15:22:15 Also, speaking only for myself, I'm very interested in having a "frictionless" start for anyone who downloads Fedora Workstation with the intent of learning programming in any of a small set of popular languages 15:23:11 We could perhaps install @development-tools and @c-development by default? 15:23:19 This may not need a lot of original content, but some sort of learning path that collects and/or delivers the right tools and reading material quickly 15:23:20 stickster: Do you have any idea what is missing on the portal? 15:23:29 devloper portal seems to be targeted at experienced developers who want to know how to install their tools of choice on fedora? 15:23:35 First thing I do after a new install is 'sudo dnf install @development-tools @development-libs @c-development @gnome-software-development' 15:23:36 * phracek_ nods 15:23:53 mcatanzaro: This could be an aim for DevAssistant. 15:23:59 www.devassistant.org 15:24:22 There is an assistant which install all dependencies for PyGTK, e.g. 15:24:46 phracek: One problem is, we're not sure what we're going to do with DevAssistant. 15:24:52 how you see da and this portal cooperate or overlap ? 15:24:57 ok, here's the 1 click install demo: https://kalev.fedorapeople.org/gnome-software-1click-install.webm 15:24:57 there is also gui for DevAssistant. 15:25:05 will the portal supersede da ? 15:25:06 I think we and the DevAssistant folks have more or less agreed to remove the GUI app. 15:25:26 Nice kalev 15:25:32 We added support to Epiphany to allow packaging web apps as RPMs, but we haven't agreed that we want a DevAssistant server running locally.... 15:25:40 mclasen: No. Portal is not about DA. Portal is about helping developers. 15:25:41 kalev, we would need to somehow prepare metadate for it right? 15:25:51 *metadata 15:25:56 phracek_: ...but so is da ?! 15:26:13 kalev: Nice. I am voting for your demo. It is useful for us. 15:26:25 kalev: we could probably change the firefox defaults somehow so it doesn't ask you if you want to open it in Software and just opens it straight away 15:26:25 jstribny: no, nothing special needed, any app that's currently discoverable through gnome-software can be installed just like that 15:26:27 da is DevAssistant. 15:26:38 elad: sure :) 15:26:55 kalev: would be nice to make it a little more 1-clicky, by starting the installation right away, maybe 15:26:57 it is command line name 15:27:11 phracek_: both DA and the portal are "about helping developers" 15:27:17 kalev, yeah...but i have seen idea about executing the commands from the portal 15:27:23 ^^ 15:27:31 kalev: Does that work in WebKit? 15:27:44 phracek_: sorry, I was unclear. What I meant to say is that if the goal of the portal is to help developers, isn't that exactly the same as da's goal ? 15:27:44 mcatanzaro: I don't know, but let me try 15:27:45 kalev: mclasen: Could you please create an issue here: https://github.com/developer-portal/content and provide steps or what is needed? 15:27:46 mcatanzaro: it should, it's not a browser plugin 15:27:49 kalev, or you are refering to devass only? 15:28:36 jstribny: look at https://kalev.fedorapeople.org/appstream-url.html , that's all that a web page has to do 15:28:38 elad: We have had debates about whether to support custom URI handlers... Apple was skeptical so I think it hasn't happened yet. 15:28:52 oh. 15:28:58 I guess you could special case this one? 15:29:23 kalev, I know! but my concern was different....we don't have Vagrant with libvirt as an app in software 15:29:36 mclasen: yes. As da as portal do it. They want to help developers. 15:29:45 so where's the overlap between DA and the portal? they both have the same (very abstract) goal 15:30:10 "help developers" doesn't mean much 15:30:21 jstribny: ahh. for that, I think we could do a similar custom URI handler, but instead of x-appstream, we'd use x-rpm and allow installing any rpms 15:30:28 although it is a noble goal :-) 15:30:35 jstribny: or something along those lines :) 15:30:41 elad, i think the problem is in directions of DA = nobody knows what will happen with it 15:30:47 elad: I guess, that there is not overlap. We have missed developer.fedoraproject.org and therefore we have tried to create it. 15:30:54 like another portals. 15:31:15 kalev, i like the idea definitely 15:31:29 Portal tries to show what languages/tools/deployment are available in Fedora. 15:31:42 And of course how to use it on Fedora. 15:31:44 phracek_: Is it fair to say that DA was created *as a tool* because we didn't have a clear way to give developers information on how to do the things the Portal can now show? 15:31:47 jstribny: We've been told the DA GUI app is being replaced with a web page, that would be run as a local server. 15:32:25 mcatanzaro: which sounds like a can of worms on multi user systems, btw 15:32:27 mcatanzaro: It is planned but I don't know what is the progress. 15:32:27 mcatanzaro, not really yet...there are just being discussion what the next version (if) should look like 15:32:44 Hm.... 15:33:08 stickster: Many pages on portal refers to DA. But not all. 15:33:44 stickster: Some of them are about building RPM from scratch, how to use vagrant, and soon, how to use openshift. 15:33:50 right 15:33:56 Why would a developer need DA if the portal already lists all the steps they need to take to, for example, install developer tools? 15:34:35 elad: well, creating skeleton projects is something you can't do well from documentation 15:34:51 elad: Answer is: why to use command line with several steps which can be automized by DA. 15:34:55 elad: And DA do it. 15:35:06 otaylor: right, but this sounds like something more suited to be a part of Builder and not a separate app 15:35:23 elad, otaylor yes, i had a vision for DA and I passed the word to people that should take care of it..... 15:35:52 sorry guys, I have to take care about kids. 15:35:56 ^^ you might want to cross install many things.....in gui it would be easy to do with few clicks 15:36:04 phracek_: Thank you so much for being here to talk to us, though 15:36:13 phracek_: before you go, do you think we can take the current devassistant out of the F24 default install? 15:36:14 I will be online after a 15 minutes. 15:36:30 Thanks phracek_! 15:36:38 yeah, thanks for stopping by 15:36:47 kalev: You have to ask bkabrda or msrb. Their are responsible for DA. 15:36:49 So right now, I do want to capture anything folks expect WG members to do... like do we need kalev to file a ticket for the 1-click bit? 15:36:49 kalev, i would say yes, its currently not _actively_ maintained 15:37:09 stickster, yes please 15:37:15 stickster: phracek nods. I like the idea 15:37:45 #action kalev file ticket at https://github.com/developer-portal/content for one-click install idea (re: https://kalev.fedorapeople.org/appstream-url.html) 15:39:07 we didn't get to discussion wrapping the portal as a webapp 15:39:13 stickster, actually this should be for website IMHO https://github.com/developer-portal/website 15:39:24 mclasen: Ah yes, that was the thing gnawing at me 15:39:26 #undo 15:39:26 Removing item from minutes: ACTION by stickster at 15:37:45 : kalev file ticket at https://github.com/developer-portal/content for one-click install idea (re: https://kalev.fedorapeople.org/appstream-url.html) 15:39:34 #action kalev file ticket at https://github.com/developer-portal/website for one-click install idea (re: https://kalev.fedorapeople.org/appstream-url.html) 15:39:38 Thanks jstribny 15:39:49 mclasen, since its static it could be a webapp 15:39:51 if we have the 1 click install, we might not even need a local webserver thing and can just do a regular web app 15:40:01 it doesn't seem very appy to me 15:40:14 currently not, thats true 15:40:27 otaylor, it wasn't design as to be.... 15:40:27 and should have a ton of links out to other sites 15:40:58 so it could just be a link on the start page or a bookmark (if thats still a thing...) 15:41:13 jstribny: discussing whether a webap launcher for it makes se 15:41:17 nse 15:41:30 mclasen, otaylor perhaps not, a link somewhere should be ok 15:41:32 I think we still have a start page, yes 15:41:37 we do 15:42:03 elad: that aside was regarding bookmarks 15:42:08 * stickster notes that people *do* use it, in fact... it is one of the major click-cotnributors to Magazine traffic which is featured on the page as well 15:42:18 * mclasen hasn't opened a webpage from a bookmark in years 15:42:48 do we have other agenda items ? 15:42:55 * mclasen has to bail 10 minutes early today 15:43:01 mclasen: We do have one other 15:43:15 before we switch gears, do we take the current devassistant out of the default install? 15:43:25 kalev: +1 15:43:31 I'm +1 too 15:43:40 +1 from me too 15:43:54 it drags in some deps that we might not want to take out though ... like git? 15:43:56 kalev: the gui, yes +1 (need to be clear in communication) 15:44:01 and perl that's installed together with git :) 15:44:12 kalev: keep gitg? 15:44:19 we don't have gitg right now 15:44:20 kalev: the command line should be oresent I think 15:45:11 Well, let's worry about what to keep in another discussion. Vote on DA removal please 15:45:16 there was some suggestion to install one of the development groups by dfeault earlier ? 15:45:23 would that take care of git and the like ? 15:45:28 stickster: I'm not sure what I"m voting on 15:45:42 otaylor: Whether to remove current DA from default WS install 15:45:56 stickster: DA *GUI* or DA *command line* 15:46:02 +1 GUI, -1 command line 15:46:06 good point 15:46:18 GUI is the only thing I thought we were considering, sorry -- yes, let's clarify, just that 15:46:19 * mclasen switches his vote to align with owen 15:46:23 * stickster too 15:46:54 mcatanzaro: kalev: rdieter_work: cschalle_: ^^ 15:47:21 I am neutral 15:48:02 (remove DA-GUI: currently +1: 3, 0: 0, -1: 0) 15:48:14 Come on guys, we need to move on here 15:48:15 +1 sorry :) 15:48:17 +1 15:48:40 (remove DA-GUI: currently +1: 5, 0: 0, -1: 0) 15:49:09 #agreed remove DA-GUI: +1: 5, 0: 1, -1: 0 15:49:19 #topic OpenH264 15:49:35 kalev: So FESCo approved our plan in https://fedorahosted.org/fesco/ticket/1496 15:50:10 right, and I've now put together packaging for this, https://bugzilla.redhat.com/show_bug.cgi?id=1285338 15:50:20 So we'll be able to play MP4 video, but won't have AAC so no audio to go with the video.... 15:50:22 yay, progress 15:50:23 my question was, how do we get it on the users systems? 15:51:04 right now the plan is to include a .repo file that has enabled=0 metadata_enabled=1 that points to the cisco site that has the binaries 15:51:05 mclasen: mcatanzaro: Yeah, one step at a time is better than no steps 15:51:11 kalev: Honestly, I don't see any point in bothering... sorry to be pessimistic but I don't think we can solve the audio problem. 15:51:11 kalev, you need to a) contact the person at Cisco to get it hosted as a yum repo, and then add the link to that repo to the 3rd party repos package mclasen created 15:51:23 but how do we actually get users to install those, without having to manually search for it in gnome-software? 15:51:28 the gstreamer plugin should have metadata to make codec installation work, provided the repository is known, right ? 15:51:36 ^ that 15:51:41 kalev, well the gstreamer auto plugin install should handle it 15:51:43 mclasen: yup, it should be that easy for the gstreamer plugin 15:51:51 but what to do with the firefox integration? 15:51:57 it doesn't go through gstreamer 15:52:11 kalev, file a bug against firefox and talk to our firefox maintainers? 15:52:21 might need a firefox patch to make it install the rpm 15:52:30 so I have 3 ideas right now: 15:52:32 instead of downloading the binary or whatever they do now 15:52:34 mclasen: My concern is that installation with the codec installer would be a step backwards from what we have now. Users are going to be confused when videos play without audio. At least currently you can Google a bit and discover that you need rpmfusion, but if the video is playing users will think there is some bug. 15:53:06 I think we should not install this gstreamer plugin automatically 15:53:19 mcatanzaro, well we could maybe patch Totem to notify users that the reason they have no audio is missing audio decoder? 15:53:31 * mclasen has to go, unfortunately 15:53:36 Bye mclasen 15:53:37 thanks for sticking with us mclasen 15:53:42 1) have gnome-initial-setup offer non-free codecs, basically changing the .repo from enabled=0 to enabled=1 and installing the codec 15:53:48 and in most cases even video would not play yet as the decoder does not support the Main profile yet 15:53:49 cschalle_: Well maybe it will actually do that already, not sure.... 15:54:13 kalev: Oh please no offer in g-i-s; my understanding is we can do this legally with or without user interaction.... 15:54:13 2) put a soft reverse dep from mozilla-openh264 to firefox, so that updating the system prompts for mozilla-openh264 installation 15:54:34 3) add packagekit integration to firefox, so that it tries to auto-install the rpm when it needs 15:54:52 cschalle_: Can you elaborate on "and in most cases even video would not play yet as the decoder does not support the Main profile yet" <-- I'm not sure what that means. 15:55:03 that was in no preference order, just trying to list possibilities 15:55:08 mcatanzaro: openh264 doesn't support the H.264 Main profile 15:55:12 kalev: (3) is obviously the best solution, (2) a good workaround. I didn't realize FF didn't have PK integration! 15:55:17 only the profiles used in WebRTC 15:55:19 thanks for outline, kalev 15:55:35 mcatanzaro, it means that 90% of the H264 videos out there are using what is known as the H264 Main profile, while this decoder atm only support Simple profile (I think that is the name of the profile) 15:56:28 mcatanzaro, the gstreamer codec installation should be able to handle this difference and still ask you to supply a plugin that can handle the right H264 profile 15:56:40 I guess my question then is: why on Earth are we bothering with this. :p 15:56:55 mcatanzaro, because it eventually will support Main 15:56:56 cschalle_: OK 15:57:17 And establishing the process by which we can provide a capability to users in a licit way *is* important 15:57:28 mcatanzaro, and as we know it takes a lot of time to get this setup, so by doing it know we can stop worrying about the practical side and just focusing on helping move the technical side forward 15:57:40 the gstreamer codec integration also looks at the profile, so that if the plugin only supports one profile and the video another, it won't try to install the incompatibly plugin 15:57:55 * kalev double checked it yesterday. 15:58:00 kalev: So it sounds to me, too, like (3) is the way to go 15:58:26 yeah, agreed 3 seems the best, but talk to Martin and Jan about it and hear what their opinions are 15:58:29 ok 15:58:30 no idea how big that job is though 15:59:02 #action kalev Talk to Firefox maintainers about PackageKit integration so we can use gstreamer codec identification for package installation 15:59:09 Well, that was productive :-) 15:59:15 I don't really understand - are we just going to *plan* to do this in the future, or are we going to go ahead and offer installation of a non-working codec? 15:59:34 otaylor, it works, it just doesn't handle all usecases 15:59:39 otaylor: My understanding is it will only be offered if the user tries to use something that can actually use it (WebRTC) 15:59:39 cschalle_: Like sound? 15:59:41 otaylor: It's not non-working (completely), and from what kalev describes, it doesn't regress what users can do now 15:59:45 And if that's the case, it's fine. 15:59:48 otaylor, well that is a different codec 15:59:51 WebRTC uses Opus for sound, not AAC. 16:00:18 But, it seems almost pointless, because really, who cares about supporting H.264 in WebRTC... that will just tell WebRTC folks that WebM is optional. 16:00:37 mcatanzaro, well you can't use WebM for WebRTC anyway? 16:00:38 Actually possibly counterproductive; if I thought Fedora had any influence here, I would be opposed, but we don't so it's probably harmless.... 16:00:53 cschalle_: You can, it's a mandatory-to-implement codec, just like H.264. 16:01:00 mcatanzaro, WebM is a container format, not a codec 16:01:16 I think mcatanzaro means VP8/VP9? 16:01:19 cschalle_: If we only offer it for cases where it will actually work, and it interoperates OK with codecs that users get from some unspecified place that handle more cases, then it should be OK 16:01:23 If you don't support both codecs^W formats, you can't say you support WebRTC, you can only say you are "WebRTC-compatible" 16:01:46 otaylor++ 16:01:46 otaylor, that is how it is supposed to work, and hopefully wtay will be able to help get the Main support in there 16:01:46 mcatanzaro: ^ that (non-influence), and things don't stand still. If we have progress elsewhere we might be able to add more important codecs. To me, the value here is in establishing how, mechanically, we can offer something like this in the future in the case of a more useful codec 16:01:53 Guys, we are over time :-) 16:02:25 Let's take this to #fedora-workstation to debate further the value; I don't think there's any argument that PK integration in Firefox could be a good thing 16:02:45 sorry, s/that PK/against PK/ 16:02:54 Thanks for coming everyone :-) 16:02:55 Well I think nobody is opposed to the action items, so... :) 16:03:00 right 16:03:02 #endmeeting