15:00:08 <stickster> #startmeeting Fedora Workstation WG
15:00:08 <zodbot> Meeting started Wed Mar 18 15:00:08 2015 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:12 <stickster> #meetingname workstation
15:00:12 <zodbot> The meeting name has been set to 'workstation'
15:00:23 <stickster> #topic Roll call!
15:00:29 <otaylor> here!
15:01:39 * mclasen here
15:02:06 * kalev stops toying with ColorHugALS and looks up.
15:02:49 <stickster> #chair otaylor mclasen kalev
15:02:49 <zodbot> Current chairs: kalev mclasen otaylor stickster
15:03:27 <rdieter> here
15:03:32 <stickster> #chair rdieter cschalle
15:03:32 <zodbot> Current chairs: cschalle kalev mclasen otaylor rdieter stickster
15:03:46 <cschalle> yo
15:04:21 <stickster> We have a nice juicy agenda today! I will put the icon/release criteria agenda item in early because we need to see whether or how it affects Beta, and don't want to run out of time.
15:04:39 <stickster> #topic Symbolic icons + release criteria
15:05:44 <stickster> mclasen: I have https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria as a URL reference, is there something more specific for this?
15:06:38 <mclasen> I know we had some release criteria that explicitly mention highcontrast icons
15:06:52 <mclasen> which is the basis for the blocker bugs that are currently open about this
15:07:08 <stickster> Yeah, I'm trying to find the actual URL for the criteria, I recall the same.
15:07:41 <kalev> what apps are we talking about? maybe we can just fix them up in a few minutes of effort?
15:07:45 <stickster> Well, we can find that in the near future. The more important topic is to see what the coverage gap is in the icons affected
15:07:52 <stickster> kalev: +1 ^
15:08:19 * mclasen hampered by lack of working copy-paste in this wayland session :-(
15:08:25 <stickster> oops
15:09:02 <stickster> mclasen: So am I right this is a *beta* release criterion? Or is it for Final?
15:09:17 <mclasen> the bugs I'm thinking of are on the final blocker list
15:09:24 <mclasen> again, I would paste one here...
15:09:46 <stickster> mclasen: I think you can do .bz <number>
15:09:50 <mclasen> it says it violates: "All applications installed by default must comply with each MUST guideline in the Apps and Launchers policy"
15:09:56 <mclasen> bug 1182652
15:10:05 <kalev> .bug 1182652
15:10:07 <zodbot> kalev: Bug 1182652 Missing high contrast icon - https://bugzilla.redhat.com/1182652
15:10:19 <stickster> Thanks kalev and zoddie :-)
15:11:21 <stickster> OK, so this isn't imminent.  I think the task at hand is to find out the coverage in the default set, send that to list, and then we can go about getting help on the icons needed... am I missing something?
15:11:28 <kalev> ok, so the action that's happened on the bug is that mgrepl reassigned it from setroubleshoot → gnome-themes-standard
15:11:43 <kalev> is it really gnome-themes-standard that's supposed to ship setroubleshoot icons?
15:12:01 <stickster> That doesn't sound right
15:12:28 <mclasen> so, there's a few things: apps should ship their own icons nowadays
15:12:35 <mclasen> app icons, specifically
15:12:47 <otaylor> It seems like there is an issue where apps *have* hicontrast icons, but they aren't used consistently in the app menu
15:12:55 <mclasen> historically, we've unfortunately covered a lot of the 'builtin' apps by the icon theme
15:13:15 <mclasen> I think the app menu is only looking for symbolics
15:13:24 <mclasen> not for hc icons
15:13:52 <mclasen> this is the other thing: upstream icon artists are changing things around so we _only_ use symbolics, in hc as well
15:13:53 <kalev> I guess jimmac dropped the icon from the theme for 3.16 and we should just copy it to setroubleshoot then?
15:14:29 <stickster> mclasen: How does that affect something like firefox?
15:14:44 * stickster still sees the hc icon in app menu when he foregrounds Firefox
15:15:03 <otaylor> stickster:  But only in the hc theme, right?
15:15:09 <stickster> Ah, yes
15:15:22 <elad661> yeah I get a fullcolor firefox icon here
15:15:31 <otaylor> stickster:  for comparison, for somethign liek gedit, you'd have the same icon in hc and normal
15:15:32 <mclasen> right
15:15:47 <mclasen> so if the icon theme is set to HighContrast, existing hc icons from that theme will be picked up
15:16:00 <mclasen> as fallback, while looking for a nonexisting -symbolic
15:16:05 <elad661> I'm not 100% sure we should be blocking the release on this - I would like it to get fixed but idk if it can be fixed on time.
15:16:40 <stickster> I think twiddling release criteria per-release in response to upstream changes means we are doing release criteria wrong.
15:17:25 <otaylor> we can definitely fix up setroubleshoot and the color profile tool (or maybe I installed that?) and that would satisfy the release criteria - but we have to realize that it doesn't do much for the app menu situation
15:17:30 <stickster> #proposed Let's see the list of affected apps (default only is what's affected by criteria) before we decide what to do about criteria
15:18:04 <stickster> mclasen: Can you send a list of affected pkgs to the list?
15:18:15 <mclasen> affected... by what ?
15:18:23 <elad661> otaylor: the color profile viewer is fixed in https://git.gnome.org/browse/gnome-color-manager/commit/?id=ab9f326559da69b530570b3a9abb0d5fc799da80
15:18:29 <elad661> which is in the latest upstream release
15:18:55 <stickster> The ones that are (1) missing symbolic icons, or (2) might need to have icons moved to the package  (If I understand the issue correctly)
15:19:01 <mclasen> stickster: well, the highcontrast icons are not coming back, upstream... so we better adjust the release criteria to not demand them
15:19:20 <kalev> I'm doing a setroubleshoot patch
15:19:29 <otaylor> mclasen:  I'd assume that the release criteria means that everything should look right in the hicontrast theme
15:19:35 <mclasen> right, thats what it means
15:19:47 <stickster> Right, we don't want to break the release for visually impaired users
15:20:14 <mclasen> I think it should say so, too - ideally recommending the best practice: ship both an app icon and a symbolic version of it, with the app and install both in hicolor
15:20:35 <elad661> mclasen: +1
15:20:49 <mclasen> slight complication here is that the directory structure of hicolor is not entirely suitable for symbolic svgs
15:21:12 <mclasen> since there's no scalable directory with nominal size of 16
15:21:25 <mclasen> the scalable directory in hicolor has a nominal size of 128
15:21:50 <mclasen> installing your symbolics there kinda works, but is technically broken
15:21:58 <elad661> can we introduce a new subdirectory? Or /use/share/icons/symbolic?
15:22:15 <elad661> s/use/usr/
15:23:02 <mclasen> we can, but it'll take a while... in retrospect, that is what we should have done when symbolics were first introduced
15:23:13 <mclasen> instead of misusing the scalable directory
15:23:32 <stickster> This seems like something that should be hashed out aside from this meeting.
15:24:10 <stickster> I wanted to ensure we weren't hitting a problem that was going to affect the imminent Beta freeze
15:24:15 <mclasen> I volunteer to locate that 'apps and launchers' spec, and propose a revision on the list
15:24:31 <stickster> mclasen: That sounds sensible to me. I may have some further caveman questions :-)
15:24:47 <mclasen> and I'll see if I can set wheels in motion to add a proper symbolic subdir to hicolor
15:24:56 <stickster> #action mclasen locate the apps and launchers spec, and propose revision on desktop@ list
15:25:22 <stickster> #info Suggestion was to add symbolic directory, possibly as subdir' to hicolor
15:25:36 <stickster> I'm going to move on because we have a lot to get to, and many of us have a hard stop at the hour
15:25:45 <stickster> #topic Privacy policy
15:25:50 <stickster> #link https://fedoraproject.org/wiki/User:Pfrields/PrivacyPolicyRedux
15:26:37 <mclasen> stickster: fyi, the noon meeting is cancelled, so...
15:26:50 <stickster> mclasen: Oh yay :-)
15:27:08 <stickster> Anyway, re policy, thanks for the review and comment on the list. I was in touch with Spot yesterday who also contributed some new draft material -- we are working on getting that all congealed together
15:27:41 <stickster> That also involves checking a couple sections with other folks, in process as we speak
15:28:12 <elad661> I'm reading this policy and most of it look like it's relevant for fedora the project and not fedora the thing you install... if someone reads it too quickly and doesn't notice the "at conferences" for example, seeing "your home, billing, or other physical address" might scare users
15:28:41 <stickster> elad661: There are numerous sections in our new draft that talk specifically about more the installed things
15:29:02 <stickster> Which is why I say that draft should now be considered obsolete, the new one is coming shortly
15:29:32 <stickster> We do need to keep the sections on "at conferences" because people still sign up for accounts at shows where ambassadors are present
15:30:43 <stickster> #info More policy rewrites are on the way, should have another draft published soon
15:31:08 <stickster> #action stickster Update list with new draft once it's ready for review
15:31:13 <elad661> right, but you can probably order it differently or make the words "at conferences" bolder (or even a sub-heading) so people will not miss it
15:31:23 <stickster> elad661: Agreed
15:31:27 <mclasen> stickster: I already sent my suggestions on the list - does it make sense to discuss the outdated draft more ?
15:31:34 <stickster> nah
15:31:48 <stickster> mclasen: And thank you for suggestions, I have them on my list to incorporate too
15:32:04 <stickster> Anything else before we move on?
15:33:16 <stickster> #topic Open seat
15:34:10 <stickster> Someone nominated Michael Catanzaro for a seat. However, it strikes me just now that he can't be present at this very time today if we discuss that nomination. Does that cause any problem?
15:34:43 <mclasen> He said he'd accept it, didn't he ?
15:35:41 <stickster> I believe so, but he did say meetings might be hard to attend more than partway through.
15:36:09 <mclasen> we could try to find a time that works better for him...
15:36:29 <stickster> Yeah, I was going to also note that ryanlerch is relocating to Australia soon and it might be time to do exactly that.
15:36:37 <mclasen> oh, right
15:36:42 <mclasen> we're expanding globally
15:36:53 <stickster> #action stickster Start input gathering (via whenisgood.net) for new meeting time.
15:37:45 <mclasen> as for michael, I think he would be a good choice to fill the open seat, +1 from me
15:37:47 <stickster> I personally feel MC is a fine choice. Notably he's not another @rh community member, for what it's worth. He's always constructive in my experience and knows what we're trying to do with the Workstation.
15:37:51 <stickster> +1 from me
15:39:10 <stickster> otaylor: kalev: rdieter: cschalle: ? ^^
15:39:19 <cschalle> +1
15:39:21 <rdieter> +1
15:39:24 <otaylor> otaylor:  +1
15:39:50 <kalev> +1 from me as well
15:40:23 <stickster> #agreed Michael Catanzaro accepted for open seat (+6, -0, 2 not present)
15:40:44 <stickster> #action stickster Notify list and fix Workstation wiki page
15:40:51 <stickster> Anything else before we move on?
15:41:18 <stickster> #topic Third party repositories
15:43:07 <stickster> So FESCo approved a policy that allows shipping disabled COPR repo definitions. This helps in the case of something like PyCharm for developers we are targeting. And IIUC the Council is taking on the task of approving any disabled repo shipping beyond that
15:43:26 <jwb> correct
15:43:53 <cschalle> ok, seems like a decent step forward
15:44:13 <stickster> That's on a case-by-case basis, so we need to provide a justification for why to include another repo.
15:44:38 <jwb> the council would like to see proposals/justifications that refer to the gains Fedora could have by including such a repo
15:44:42 <kalev> one specific use case where this could be useful is shipping the err, what's-the-name of the codec that cisco has a patent grant for?
15:44:49 <jwb> h264
15:44:52 <kalev> yes!
15:45:21 <cschalle> yeah, I saw that, but my guess would be that in practice we would come up with one general justification and then re-use it. The arguments for shipping most of these things ends up being the same
15:45:28 <kalev> that was it could come from cisco servers, but still be discoverable in fedora
15:45:33 <kalev> *that way
15:46:03 <stickster> cschalle: The argument for something like Chrome, I think, would be a strong one based on market share data; I think the justification would be significantly different for something like OpenH264
15:46:55 <stickster> I'm guessing we have to do a little better than "ease of migration" -- with Chrome we can add to that the potential size of the audience who can migrate
15:47:01 <cschalle> stickster, maybe, but the justification for Chrome is likely to be quite similar to the justification for Steam for instance
15:47:08 <stickster> Agreed
15:48:12 <stickster> http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_table is interesting.
15:48:53 <cschalle> I think the only challenge with the current policy is that it doesn't really cater well for the fact that the amount of apps we offer have a value beyond the indidiual apps, ie. the total is more than the sum of its individual parts
15:49:23 <stickster> I'm not sure I understand the point, can you restate?
15:49:55 <jwb> i read that as "more apps == more users overall"
15:50:09 <stickster> OK, I get that now
15:50:13 <cschalle> my point being that having ie. 100 applications available for our platform has a value in itself; as opposed to justifying number 87 on that list on an individual basis
15:50:22 <stickster> *nod
15:50:51 * jwb wonders what the compounding formula for app/users is
15:50:51 <jwb> :)
15:51:16 <stickster> jwb: It probably has to do with pi
15:51:55 <stickster> I don't think anyone would question the more apps, the more people can use the platform. But the balancing act is always with how we are helping Fedora attain its mission of advancing free software
15:52:09 <stickster> So for our case (Workstation) it has to do with the apps that *developers* use
15:52:31 * mclasen thinks of it in terms of shortening those lists of  'here's what to do after install to make fedora usable'
15:52:47 <mclasen> that are floating around the internets
15:52:50 <stickster> *nod
15:53:21 <cschalle> also I guess having the council approve each app on an individual level is a bit ungainly in terms of matthews wish to not have the list of applications end up being an endorsement
15:53:25 <stickster> Chrome is interesting in that it's arguably the most-used browser on desktop these days that we could possibly care about (which skips IE of course) -- and it seems logical that more developers also use it.
15:54:27 <stickster> cschalle: Right, but the decision process allows the Council to do something like help us craft a reference page for the software installer warning
15:54:56 <stickster> Because I do agree we should use that capability to write a page that explains Fedora's stance on non-Fedora and non-FOSS software
15:55:11 <cschalle> stickster, understood, but instead of 'offering whatever happens to be out there' we are now instead offering 'the apps that are so good that people can not live without them' :)
15:55:42 <cschalle> which is an implicit endorsement :)
15:55:58 <stickster> More an acknowledgement of reality?
15:56:21 <jwb> we can't offer whatever happens to be out there because of various reasons, including legal.  if we could offer that, then there'd be no reason not to offer rpmfusion as a disabled_repo
15:56:30 <jwb> (for example)
15:56:34 <stickster> Yup
15:57:28 <stickster> Curating a list (which is really what the Council decision amounts to) means tacitly acknowledging the list has value
15:57:40 <mclasen> again, there's only so much denial of reality that you can do... even anaconda (arguably fedoras flagship app) is hosted on github now...
15:58:26 <cschalle> jwb, agreed, there are some things we can't offer, but what I am saying is that there is a long range between 'everything' to 'our procured list of exclusive goodies', so I am just warning that the current policy might put as closer to the second than the first
15:58:35 <jwb> mclasen, yes.  but one person's reality is another's lawsuit ;)
15:58:50 <jwb> cschalle, yes, definitely
15:59:25 <kalev> coming back to setroubleshoot's HC icon, I've reassigned https://bugzilla.redhat.com/show_bug.cgi?id=1182652 to setroubleshoot and posted patches to move the HC icons there
15:59:33 <stickster> Thanks kalev
15:59:33 <cschalle> kalev, thanks
16:00:04 <stickster> OK, so next action here -- are we going to select any additional repo and use it to pilot this process with the Council?
16:00:51 <stickster> Everyone's basically waiting for the other shoe to drop; I don't believe there's anything to gain from drawing that out
16:01:58 <stickster> Or has everyone just gone to lunch? :-)
16:02:47 * mclasen still here
16:02:51 <rdieter> that's a good onlist topic, to solicit suggestions
16:03:05 <mclasen> I think we had a short-list of candidates already
16:04:07 <mclasen> openh264, chrome, pycharm, steam
16:04:24 <jwb> pycharm is in a COPR, right?
16:04:28 <mclasen> of those, pycharm is covered by copr, yes
16:04:33 <stickster> pycharm is a COPR, so it's OK at this poitn.
16:04:34 <rdieter> only copr content is eligible currently
16:04:36 <stickster> point, even.
16:04:39 <mclasen> pick from the other three
16:05:10 <stickster> I would like to see us try OpenH264 because it's demonstrably open source
16:05:15 <jwb> you might go ahead and bundle the pycharm disabled repo file into something though.  that will make the feature technically usable
16:05:20 <rdieter> or is the question about what to add next? (if so, I misinterpetted)
16:05:23 <stickster> jwb++
16:05:27 <mclasen> steam is a bit more complicated because of where it is currently hosted
16:05:40 <kalev> I would pick openh264 as a first one to try to push through the Council, because it's open source and its license is suitable for fedora
16:05:42 <stickster> I don't know enough about Steam yet to suggest it
16:05:53 <cschalle> stickster, we are still blocking on RH legal for that one
16:06:00 <stickster> cschalle: Oh, oof.
16:06:01 <cschalle> stickster, for OpenH264
16:06:03 <kalev> ahh, ok
16:06:14 <jwb> (you might also try including the Chromium COPR)
16:06:15 <kalev> and it's missing the Cisco side with rpms anyway, right?
16:06:23 <cschalle> stickster, not blocking in the sense they are worried about legal issues, but blocking in terms of them having time to review the contract
16:06:29 <rdieter> now, if steam agreed to distribute it, then it should be in the same class as chrome
16:06:58 <jwb> kalev, on a tangent, i'm strongly advocating in the Council to not equate this process/policy with RPM repos only.  because containerized Apps can be third party "repos" as well
16:07:33 <stickster> So in the interest of time it sounds like Chrome, and I believe we should also propose the Chromium COPR as jwb suggested, alongside it so users arguably have additional choice.
16:07:52 <cschalle> sounds fine with me
16:07:55 <kalev> we'll need someone to pick up the Chromium copr maintainance in that case, though
16:08:11 <stickster> kalev: Is that basically unmaintained right now?
16:08:19 <stickster> Or is spot still keeping that up?
16:08:24 <kalev> it didn't have F22, last time I looked at least
16:08:28 <jwb> there's two i think.
16:08:47 <kalev> https://repos.fedorapeople.org/repos/spot/chromium/ , F21 last updated in january
16:08:51 <jwb> kalev, hardly anything has f22 in copr.  they just added chroots there like last week
16:08:56 <kalev> I'm sure there have been security updates in the meanwhile
16:09:09 <kalev> ok, that's a good point too :)
16:09:22 <kalev> anyway, is tpopela working on Chromium for RHEL?
16:09:29 <jwb> https://copr.fedoraproject.org/coprs/churchyard/chromium-russianfedora/ is the other i was thinking of
16:09:53 * stickster retracts idea to propose the Chromium repo alongside, but we should reconsider it (or an alternative) depending on maintenance status
16:09:53 <cschalle> kalev, he is, but we are trying to get him off it :)
16:09:59 <kalev> ahh :)
16:10:35 <stickster> The more I think about it, the more I think that's just dithering anyway. Let's concentrate on the task at hand and if someone wants to bring Chromium to the table, the more the merrier.
16:10:36 <cschalle> kalev, because Chromium is basically Chome without all the things that wants you want to use Chrome
16:11:10 <stickster> #proposed Work up justification for Chrome and present to Council within next 1-2 weeks
16:11:23 <cschalle> stickster, I be happy to work with you on the proposal
16:11:31 * stickster happy to accept all help
16:11:32 <cschalle> err justification
16:12:03 <cschalle> or proposed justification or justified proposal - your pick
16:12:05 <stickster> ha
16:12:12 <stickster> Anyone opposed? If not, we'll run with it
16:12:52 <kalev> cschalle: while you are at it, can you review the gnome-software warning dialog as well please, to make sure the message is suitable before enabling the Chrome repo?
16:13:09 <stickster> kalev: Agreed, I'll help with that too
16:13:21 <rdieter> run++ (I'd personally like to see chromium too, but I probably don't have the time to push harder for it)
16:13:36 <cschalle> kalev, yeah sure, I think what we discussed in the past is to have a distro override option available, so I will follow up with mclasen and hughsie about that
16:13:46 <kalev> awesome, thanks
16:15:39 <stickster> #agreed Go for Chrome next
16:16:12 <stickster> #action cschalle stickster work up justification for Council and review gnome-software text for an appropriate warning to suggest
16:16:28 <stickster> OK, anything else before we adjourn?
16:16:38 <stickster> #topic All Other Biznatch
16:17:36 <stickster> Sounds like not.
16:17:47 <stickster> OK, thanks for coming everyone, and have a great day/evening :-)
16:17:51 <stickster> #endmeeting