workstation
LOGS
13:00:01 <stickster> #startmeeting Workstation WG
13:00:01 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:05 <stickster> #meetingname workstation
13:00:05 <zodbot> The meeting name has been set to 'workstation'
13:00:09 <stickster> #topic Roll call!
13:00:21 <juhp_> hi
13:00:25 <mcatanzaro> hi
13:00:55 <stickster> o/
13:01:17 <rdieter> hola
13:01:32 * mclasen_ is here, but unprepared
13:01:48 <kalev> morning!
13:01:51 <stickster> mclasen_: The perils of Monday morning meeting :-(
13:02:58 <stickster> #chair juhp_ mcatanzaro mclasen_ rdieter kalev
13:02:58 <zodbot> Current chairs: juhp_ kalev mcatanzaro mclasen_ rdieter stickster
13:03:19 * stickster doesn't see cschaller, otaylor, ryanlerch
13:04:02 <stickster> #topic PRD refresh
13:04:55 <stickster> mcatanzaro, I saw your proposed changes but hadn't the chance to respond to them earlier on list.
13:04:56 <mclasen_> cschalle is still in another meeti ng
13:05:01 <stickster> OK, thanks mclasen_
13:05:21 <stickster> 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 <stickster> 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 <stickster> That seems a little disingenuous
13:08:20 <mcatanzaro> I thought that was the one we discussed at the last meeting?
13:08:33 <mcatanzaro> I could change it to "Users are not expected to be familiar with the terminal" ?
13:08:33 <stickster> It's just the phrasing seems odd
13:08:59 <stickster> The following statement was correct IMHO: "Users should not be required to use the terminal..."
13:09:13 <mcatanzaro> 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 <mcatanzaro> I don't care if we change it to "users," either way is fine; curious what others think.
13:09:47 <juhp_> https://lists.fedoraproject.org/pipermail/desktop/2015-June/012419.html
13:10:25 <stickster> mcatanzaro: s/developers/users/ would work OK, because the end users include developers
13:10:32 <stickster> *shrug
13:10:33 <kalev> I think our aim should be to provide graphical tools for most common tasks, very much agreed with that
13:10:44 <stickster> Anyway, it's a minor quibble
13:11:44 <kalev> 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 <stickster> 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 <stickster> 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 <mclasen_> I don't think the terminal needs to be explictly called out in the prd, really
13:14:13 <mcatanzaro> 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 <mclasen_> 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 <mclasen_> on that note, we produced a list of these last week: https://fedoraproject.org/wiki/Workstation/DeveloperApps
13:15:35 <kalev> 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 <stickster> kalev: That was what I was thinking... along with devhelp + relevant docs
13:16:32 * kalev nods.
13:16:35 <juhp_> 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 <kalev> 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 <kalev> an initial setup step might be a good compromise
13:17:11 <mclasen_> putting software selection into initial-setup is awkward, imo
13:17:13 <juhp_> kalev, +1
13:17:21 <juhp_> true
13:17:54 <mclasen_> I would rather have a welcome screen / release notes that point you at the right tool for getting started
13:18:04 <mclasen_> whether that is a future devassistant or gnome-software
13:18:05 <mcatanzaro> 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 <stickster> How can we tie this discussion back to fixes for the PRD?  We're kind of talking about implementation ideas here.
13:19:16 <kalev> well, it could be an initial setup step in gnome-software too when it runs for the very first time
13:19:22 <kalev> anyway, sorry for sidetracking :)
13:19:55 <mcatanzaro> 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 <stickster> #idea Future discussion: How to make developer software/tools/docs more discoverable at first login
13:20:18 <stickster> ^ fair?
13:20:24 <kalev> sure
13:20:27 <mclasen_> many of the tools we listed on the developerapps page are not even available in fedora...
13:21:28 <stickster> mclasen_: *Those* actually bring up the question of how well we're addressing in our PRD
13:21:54 <kalev> 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 <kalev> and if possible to provide ABI compatible libraries to make sure they can be installed at least
13:22:16 <mcatanzaro> 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 <mclasen_> intellij was an f13 (?) feature, now it is gone...
13:23:45 <stickster> #idea Add to PRD: A set of important third party apps are installable -- (tested/verified before Beta)
13:23:59 <stickster> mclasen_: I don't know what happened to intellij.
13:24:20 <mclasen_> the packagers disappeared, I believe
13:24:40 <stickster> http://pkgs.fedoraproject.org/cgit/intellij-idea.git/ -- retired.
13:25:15 <juhp_> I think so
13:25:26 <kalev> 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 <kalev> and fedora guidelines require unbundlind them, creating a large workload for the packagers
13:25:42 <stickster> kalev: correct.
13:25:58 <kalev> not saying it's bad, just an explanation why it's a large task to package intellij
13:26:11 <cschalle> maybe we could use those java apps as a testbed for xdg-app?
13:26:12 <mcatanzaro> Well the fedora guidelines also conflict with our plans for xdg-app, so we'll have to address them anyway....
13:27:04 <mclasen_> whats the conflict there ?
13:27:13 <stickster> 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 <mclasen_> oh, sorry, I misread
13:27:44 <stickster> Wait, spotify is a developer app?
13:28:05 <stickster> Are we talking about the music player/sharing app?
13:28:09 <mclasen_> stickster: yes, we could do that
13:28:22 <mclasen_> stickster: there was some 'developers are humans too' sentiment, I think...
13:28:27 <mcatanzaro> stickster: It's a developer "productivity" app ;)
13:28:49 <stickster> mclasen_: Not denying it's popular, but calling it a developer app is a stretch
13:29:21 <mclasen_> yeah, agreed
13:29:44 <stickster> In any case, there are a bunch of apps there that are arguably well worth testing, like android studio
13:30:48 <stickster> I can start discussion on the list to see which of these we want to test for installability
13:31:03 <stickster> I don't foresee dumping this task on the QA team... can we handle inside the WG?
13:32:20 <mcatanzaro> *crickets*
13:32:36 <stickster> 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 <cschalle> 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 <stickster> #chair cschalle
13:33:53 <zodbot> Current chairs: cschalle juhp_ kalev mcatanzaro mclasen_ rdieter stickster
13:35:06 <stickster> 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 <cschalle> 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 <cschalle> 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 <stickster> 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 <mcatanzaro> I agree the long-term plan should be to use xdg-app.
13:37:02 <cschalle> stickster, what do you mean reconcile with packaging?
13:38:07 <mcatanzaro> 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 <stickster> 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 <rdieter> xdg-app itself isn't afoul though, is it?
13:39:06 <stickster> Not the method, the content
13:39:17 <mcatanzaro> 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 <mclasen_> stickster: we can just point at docker and say 'they do it too'
13:39:22 <cschalle> 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 <rdieter> I was assuming we'd advocate simply using 3rd-party content, not shipped in fedora
13:39:48 <stickster> cschalle: Oh no doubt, I'm not advocating pulling apart these bundles for "regular" Fedora packaging.
13:40:12 <mcatanzaro> 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 <cschalle> rdieter, depends on definition of shipped in Fedora :)
13:41:14 <rdieter> I was thinking of the android studio example
13:41:21 <stickster> rdieter: *nod
13:41:31 <cschalle> 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 <mcatanzaro> I think "app bundles are not Fedora packages so the Fedora packaging guidelines do not apply" is a pretty decent argument.
13:41:48 <mcatanzaro> cschalle: +1
13:42:00 <stickster> cschalle: Is this a good use for the disabled repo feature?
13:42:05 * stickster kinda thinks so
13:42:24 <cschalle> stickster, well it would be the xdg-app equivalent I guess
13:42:47 <stickster> 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 <stickster> 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 <cschalle> 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 <mclasen_> we haven't really worked out the repository side of xdg-app fully yet
13:44:26 <stickster> This is probably more on the lines of https://fedoraproject.org/wiki/Workstation/Technical_Specification rather than the PRD.
13:46:07 <stickster> #idea work xdg-app into technical specification or relevant roadmap document
13:46:16 <stickster> *more crickets*
13:46:58 <stickster> 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 <cschalle> 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 <stickster> 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 <stickster> #link https://fedoraproject.org/wiki/Workstation/2015_report_to_Council
13:49:38 <stickster> That's just a placeholder
13:50:53 <stickster> #info Contributions to that page will be gratefully accepted
13:51:32 <stickster> #action stickster Make changes to Workstation PRD page based on mcatanzaro contributions
13:52:47 <stickster> mclasen_: I think there was some material you were going to gather up for the Council report
13:53:16 <stickster> 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 <mclasen_> stickster: I reviewed the task list if thats what you're asking
13:53:44 <stickster> mclasen_: Yes, precisely
13:54:36 <stickster> mclasen_: Is the F23 list up2date at http://fedoraproject.org/wiki/Workstation/Tasklist ? If so, I can use that.
13:55:11 <stickster> Holy moley, that list got really long
13:55:18 <mclasen_> 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 <stickster> 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 <mclasen_> sure
13:56:25 <stickster> Is there anything further we need to discuss in the last 5 min?
13:57:11 <stickster> #action stickster Start assembling Council report at above link, and note to list for WG member contributions
13:57:48 <stickster> OK then
13:57:51 <stickster> #endmeeting