13:00:01 #startmeeting Workstation WG 13:00:01 Meeting started Mon Jun 8 13:00:01 2015 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:05 #meetingname workstation 13:00:05 The meeting name has been set to 'workstation' 13:00:09 #topic Roll call! 13:00:21 hi 13:00:25 hi 13:00:55 o/ 13:01:17 hola 13:01:32 * mclasen_ is here, but unprepared 13:01:48 morning! 13:01:51 mclasen_: The perils of Monday morning meeting :-( 13:02:58 #chair juhp_ mcatanzaro mclasen_ rdieter kalev 13:02:58 Current chairs: juhp_ kalev mcatanzaro mclasen_ rdieter stickster 13:03:19 * stickster doesn't see cschaller, otaylor, ryanlerch 13:04:02 #topic PRD refresh 13:04:55 mcatanzaro, I saw your proposed changes but hadn't the chance to respond to them earlier on list. 13:04:56 cschalle is still in another meeti ng 13:05:01 OK, thanks mclasen_ 13:05:21 The PRD refresh is something we want as part of our report-out to the Council due this Friday 13:05:43 * mclasen_ heads to the list to read 13:08:01 mcatanzaro: Most of the proposed changes I had no issue with. But I'm curious about the clause "Developers are not expected to be familiar with the terminal." 13:08:09 That seems a little disingenuous 13:08:20 I thought that was the one we discussed at the last meeting? 13:08:33 I could change it to "Users are not expected to be familiar with the terminal" ? 13:08:33 It's just the phrasing seems odd 13:08:59 The following statement was correct IMHO: "Users should not be required to use the terminal..." 13:09:13 But I thought the plan was to get developers up and running with devassistant and maybe GNOME Builder, since developers coming from Windows really DON'T know how to use the terminal. 13:09:43 I don't care if we change it to "users," either way is fine; curious what others think. 13:09:47 https://lists.fedoraproject.org/pipermail/desktop/2015-June/012419.html 13:10:25 mcatanzaro: s/developers/users/ would work OK, because the end users include developers 13:10:32 *shrug 13:10:33 I think our aim should be to provide graphical tools for most common tasks, very much agreed with that 13:10:44 Anyway, it's a minor quibble 13:11:44 not sure if it should mean to install gnome-builder by default though; rather than make it available as a very prominent option 13:12:15 mcatanzaro: I think the areas you brought up where we haven't done as well are pretty accurate, save the Work Model section -- Christian does actually meet with those folks inside Red Hat, so I'm wondering what you were thinking we need in order to reflect reality better 13:13:58 kalev: I would like to see the development tools available in some more bundled way... Like you could say, "Yes, I'm a developer [or interested to be one]" and get the whole set of helpful tools/docs brougth in 13:14:08 I don't think the terminal needs to be explictly called out in the prd, really 13:14:13 stickster: OK, I thought "I don't remember meeting with a representative of Red Hat to discuss Red Hat's product and development plans will affect the Fedora product development and resource allocation," but I was considering Christian as a representative of Red Hat... semantics I guess, we can leave that section unchanged. 13:14:52 saying that we want to give developers easy access to the tools they expect to use in their chosen framework might suffice 13:15:15 on that note, we produced a list of these last week: https://fedoraproject.org/wiki/Workstation/DeveloperApps 13:15:35 stickster: maybe a step in the initial setup that asks if you want development tools, and then installs devassistant / gnome-boxes / gnome-builder / etc? I know we can't install extra programs in the live cd anaconda right now, so it has to be a post install step. 13:16:26 kalev: That was what I was thinking... along with devhelp + relevant docs 13:16:32 * kalev nods. 13:16:35 mcatanzaro, I kind of agree I don't see the need to mention "representative from Red Hat" really - when I first saw that I also raised an eyebrow 13:16:54 I feel like we've added a lot of stuff to the default install that regular users don't need, but at the same time don't have enough for developers 13:17:04 an initial setup step might be a good compromise 13:17:11 putting software selection into initial-setup is awkward, imo 13:17:13 kalev, +1 13:17:21 true 13:17:54 I would rather have a welcome screen / release notes that point you at the right tool for getting started 13:18:04 whether that is a future devassistant or gnome-software 13:18:05 It's a bit awkward, but it _would_ solve the problem, and having devassistant installed by default is awkward too: it _really_ doesn't fit in, but if we remove it then how are we making Fedora easy for developers? 13:19:15 How can we tie this discussion back to fixes for the PRD? We're kind of talking about implementation ideas here. 13:19:16 well, it could be an initial setup step in gnome-software too when it runs for the very first time 13:19:22 anyway, sorry for sidetracking :) 13:19:55 Maybe our real concern is that the developer tools are not visible enough in gnome-software, and stuffing them into initial-setup would be a workaround. Anyway yeah, back to the PRD. 13:20:11 #idea Future discussion: How to make developer software/tools/docs more discoverable at first login 13:20:18 ^ fair? 13:20:24 sure 13:20:27 many of the tools we listed on the developerapps page are not even available in fedora... 13:21:28 mclasen_: *Those* actually bring up the question of how well we're addressing in our PRD 13:21:54 talking about external apps, I would like for us to set a goal to test some most important 3rd party apps before release, to make sure they are at least installable 13:22:11 and if possible to provide ABI compatible libraries to make sure they can be installed at least 13:22:16 By the way, the Work Model section in the PRD states that we only work on one major engineering task at a time... we've been doing a lot more than one. I didn't quote that section in my email. 13:22:34 intellij was an f13 (?) feature, now it is gone... 13:23:45 #idea Add to PRD: A set of important third party apps are installable -- (tested/verified before Beta) 13:23:59 mclasen_: I don't know what happened to intellij. 13:24:20 the packagers disappeared, I believe 13:24:40 http://pkgs.fedoraproject.org/cgit/intellij-idea.git/ -- retired. 13:25:15 I think so 13:25:26 from what I understand, packaging java apps is a major pain in Fedora - mostly because upstreams tend to bundle all the libraries they need for easy 3rd party distribution 13:25:39 and fedora guidelines require unbundlind them, creating a large workload for the packagers 13:25:42 kalev: correct. 13:25:58 not saying it's bad, just an explanation why it's a large task to package intellij 13:26:11 maybe we could use those java apps as a testbed for xdg-app? 13:26:12 Well the fedora guidelines also conflict with our plans for xdg-app, so we'll have to address them anyway.... 13:27:04 whats the conflict there ? 13:27:13 kalev: mclasen_: So if we were to pick a few target open source tools from the list you posted earlier, we could make those test targets for pre-Beta 13:27:16 oh, sorry, I misread 13:27:44 Wait, spotify is a developer app? 13:28:05 Are we talking about the music player/sharing app? 13:28:09 stickster: yes, we could do that 13:28:22 stickster: there was some 'developers are humans too' sentiment, I think... 13:28:27 stickster: It's a developer "productivity" app ;) 13:28:49 mclasen_: Not denying it's popular, but calling it a developer app is a stretch 13:29:21 yeah, agreed 13:29:44 In any case, there are a bunch of apps there that are arguably well worth testing, like android studio 13:30:48 I can start discussion on the list to see which of these we want to test for installability 13:31:03 I don't foresee dumping this task on the QA team... can we handle inside the WG? 13:32:20 *crickets* 13:32:36 Rationale: QA is usually taxed for time/people. Causing them to burn cycles on testing of stuff outside Fedora package universe seems illogical 13:33:46 stickster, well we can hopefully do some testing, but I guess we need to figure out a way to automate it going forward, to avoid it being a one time thing where we test and then it dies off again 13:33:53 #chair cschalle 13:33:53 Current chairs: cschalle juhp_ kalev mcatanzaro mclasen_ rdieter stickster 13:35:06 cschalle: It might be possible to make it part of our Beta release criteria, with the caveat that the WG is responsible for it. That would trigger QA to hold us to testing at the appropriate time each cycle. ;-) 13:35:18 but my suggestion again would be that we try to do this as xdg-apps, to not waste time trying to split out 3rd party libs 13:35:39 and at the same time get some testing and verification of xdg-app going 13:36:34 * mclasen_ will look at picking a candidate app or two from the list, and finding a victim for doing the xdg-app build 13:36:36 cschalle: OK, I would like to eventually see xdg-apps somehow referenced in the PRD but it's a bit premature since no one's yet addressed how we reconcile with packaging 13:36:43 I agree the long-term plan should be to use xdg-app. 13:37:02 stickster, what do you mean reconcile with packaging? 13:38:07 We either have to change the packaging guidelines if we want to package xdg-apps, or sidestep the issue by saying "app bundles are not Fedora packages so the Fedora bundling rules do not apply." 13:38:07 cschalle: as mclasen_ (?) said earlier, right now Fedora has anti-bundling guidelines that probably xdg-app would run afoul of, so we probably need to have a conversation with FESCo *if* the plan is to offer those apps from Fedora itself 13:38:53 xdg-app itself isn't afoul though, is it? 13:39:06 Not the method, the content 13:39:17 Really the only serious opposition comes from people concerned about security issues... and if we push xdg-app, the app bundles WILL have lots of unfixed security issues; that is the nature of bundling, it's a fair point. 13:39:17 stickster: we can just point at docker and say 'they do it too' 13:39:22 stickster, sure, but I prefer having that conversation rather than spread ourselves even thinner trying to do these rpms. Of course if there are people in the community prepared to step up and do the rpm work great, but if not my priority is to get synergy between our efforts 13:39:29 I was assuming we'd advocate simply using 3rd-party content, not shipped in fedora 13:39:48 cschalle: Oh no doubt, I'm not advocating pulling apart these bundles for "regular" Fedora packaging. 13:40:12 Well it has been just a week or two since that "70% of docker apps have serious security vulnerabilities" study :) 13:40:12 * stickster has done that one too many times in the past 13:40:37 rdieter, depends on definition of shipped in Fedora :) 13:41:14 I was thinking of the android studio example 13:41:21 rdieter: *nod 13:41:31 my goal would be to try to work with some upstreams to have them ship the xdg-apps themselves with us just shipping some metadata pointing to it 13:41:32 I think "app bundles are not Fedora packages so the Fedora packaging guidelines do not apply" is a pretty decent argument. 13:41:48 cschalle: +1 13:42:00 cschalle: Is this a good use for the disabled repo feature? 13:42:05 * stickster kinda thinks so 13:42:24 stickster, well it would be the xdg-app equivalent I guess 13:42:47 cschalle: That was my next question, I wasn't sure whether that repo support was really 1:1 usable for xdg-app. 13:43:24 In any case, trying to tie this back to the PRD -- do we need to address something about xdg-app or application stacks of some sort? 13:43:38 well it might not make it for F23, but I think aday and hughsie has been looking at how to do xdg-apps in Software 13:43:40 we haven't really worked out the repository side of xdg-app fully yet 13:44:26 This is probably more on the lines of https://fedoraproject.org/wiki/Workstation/Technical_Specification rather than the PRD. 13:46:07 #idea work xdg-app into technical specification or relevant roadmap document 13:46:16 *more crickets* 13:46:58 So I guess I'd propose we work these ideas into the "next steps" to present to the Council in the writeup for the 12th, which needs to be started on the wiki 13:47:02 yeah agreed, I think we been waiting for xdg-app to mature a bit, but I think it has probably reached a point now where bringing it more concretely into our plans would be good 13:47:43 The Council write-up AIUI really has two parts -- what we've done/succeeded at so far, and what we have planned for the next year-plus 13:49:28 #link https://fedoraproject.org/wiki/Workstation/2015_report_to_Council 13:49:38 That's just a placeholder 13:50:53 #info Contributions to that page will be gratefully accepted 13:51:32 #action stickster Make changes to Workstation PRD page based on mcatanzaro contributions 13:52:47 mclasen_: I think there was some material you were going to gather up for the Council report 13:53:16 I can hit you up for that after this meeting, re: http://meetbot.fedoraproject.org/fedora-meeting/2015-05-27/workstation.2015-05-27-15.00.html 13:53:26 stickster: I reviewed the task list if thats what you're asking 13:53:44 mclasen_: Yes, precisely 13:54:36 mclasen_: Is the F23 list up2date at http://fedoraproject.org/wiki/Workstation/Tasklist ? If so, I can use that. 13:55:11 Holy moley, that list got really long 13:55:18 I didn't really get all the way through... I think I'll strip the yellow from those that aren't realistic for f23 13:55:57 mclasen_: I'm going to start working on the Council report page after this meeting. I'll talk to you about it in #fedora-workstation after this (and bio break) 13:56:08 sure 13:56:25 Is there anything further we need to discuss in the last 5 min? 13:57:11 #action stickster Start assembling Council report at above link, and note to list for WG member contributions 13:57:48 OK then 13:57:51 #endmeeting