15:00:08 #startmeeting Fedora Workstation WG 15:00:08 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:12 #meetingname workstation 15:00:12 The meeting name has been set to 'workstation' 15:00:23 #topic Roll call! 15:00:29 here! 15:01:39 * mclasen here 15:02:06 * kalev stops toying with ColorHugALS and looks up. 15:02:49 #chair otaylor mclasen kalev 15:02:49 Current chairs: kalev mclasen otaylor stickster 15:03:27 here 15:03:32 #chair rdieter cschalle 15:03:32 Current chairs: cschalle kalev mclasen otaylor rdieter stickster 15:03:46 yo 15:04:21 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 #topic Symbolic icons + release criteria 15:05:44 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 I know we had some release criteria that explicitly mention highcontrast icons 15:06:52 which is the basis for the blocker bugs that are currently open about this 15:07:08 Yeah, I'm trying to find the actual URL for the criteria, I recall the same. 15:07:41 what apps are we talking about? maybe we can just fix them up in a few minutes of effort? 15:07:45 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 kalev: +1 ^ 15:08:19 * mclasen hampered by lack of working copy-paste in this wayland session :-( 15:08:25 oops 15:09:02 mclasen: So am I right this is a *beta* release criterion? Or is it for Final? 15:09:17 the bugs I'm thinking of are on the final blocker list 15:09:24 again, I would paste one here... 15:09:46 mclasen: I think you can do .bz 15:09:50 it says it violates: "All applications installed by default must comply with each MUST guideline in the Apps and Launchers policy" 15:09:56 bug 1182652 15:10:05 .bug 1182652 15:10:07 kalev: Bug 1182652 Missing high contrast icon - https://bugzilla.redhat.com/1182652 15:10:19 Thanks kalev and zoddie :-) 15:11:21 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 ok, so the action that's happened on the bug is that mgrepl reassigned it from setroubleshoot → gnome-themes-standard 15:11:43 is it really gnome-themes-standard that's supposed to ship setroubleshoot icons? 15:12:01 That doesn't sound right 15:12:28 so, there's a few things: apps should ship their own icons nowadays 15:12:35 app icons, specifically 15:12:47 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 historically, we've unfortunately covered a lot of the 'builtin' apps by the icon theme 15:13:15 I think the app menu is only looking for symbolics 15:13:24 not for hc icons 15:13:52 this is the other thing: upstream icon artists are changing things around so we _only_ use symbolics, in hc as well 15:13:53 I guess jimmac dropped the icon from the theme for 3.16 and we should just copy it to setroubleshoot then? 15:14:29 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 stickster: But only in the hc theme, right? 15:15:09 Ah, yes 15:15:22 yeah I get a fullcolor firefox icon here 15:15:31 stickster: for comparison, for somethign liek gedit, you'd have the same icon in hc and normal 15:15:32 right 15:15:47 so if the icon theme is set to HighContrast, existing hc icons from that theme will be picked up 15:16:00 as fallback, while looking for a nonexisting -symbolic 15:16:05 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 I think twiddling release criteria per-release in response to upstream changes means we are doing release criteria wrong. 15:17:25 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 #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 mclasen: Can you send a list of affected pkgs to the list? 15:18:15 affected... by what ? 15:18:23 otaylor: the color profile viewer is fixed in https://git.gnome.org/browse/gnome-color-manager/commit/?id=ab9f326559da69b530570b3a9abb0d5fc799da80 15:18:29 which is in the latest upstream release 15:18:55 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 stickster: well, the highcontrast icons are not coming back, upstream... so we better adjust the release criteria to not demand them 15:19:20 I'm doing a setroubleshoot patch 15:19:29 mclasen: I'd assume that the release criteria means that everything should look right in the hicontrast theme 15:19:35 right, thats what it means 15:19:47 Right, we don't want to break the release for visually impaired users 15:20:14 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 mclasen: +1 15:20:49 slight complication here is that the directory structure of hicolor is not entirely suitable for symbolic svgs 15:21:12 since there's no scalable directory with nominal size of 16 15:21:25 the scalable directory in hicolor has a nominal size of 128 15:21:50 installing your symbolics there kinda works, but is technically broken 15:21:58 can we introduce a new subdirectory? Or /use/share/icons/symbolic? 15:22:15 s/use/usr/ 15:23:02 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 instead of misusing the scalable directory 15:23:32 This seems like something that should be hashed out aside from this meeting. 15:24:10 I wanted to ensure we weren't hitting a problem that was going to affect the imminent Beta freeze 15:24:15 I volunteer to locate that 'apps and launchers' spec, and propose a revision on the list 15:24:31 mclasen: That sounds sensible to me. I may have some further caveman questions :-) 15:24:47 and I'll see if I can set wheels in motion to add a proper symbolic subdir to hicolor 15:24:56 #action mclasen locate the apps and launchers spec, and propose revision on desktop@ list 15:25:22 #info Suggestion was to add symbolic directory, possibly as subdir' to hicolor 15:25:36 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 #topic Privacy policy 15:25:50 #link https://fedoraproject.org/wiki/User:Pfrields/PrivacyPolicyRedux 15:26:37 stickster: fyi, the noon meeting is cancelled, so... 15:26:50 mclasen: Oh yay :-) 15:27:08 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 That also involves checking a couple sections with other folks, in process as we speak 15:28:12 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 elad661: There are numerous sections in our new draft that talk specifically about more the installed things 15:29:02 Which is why I say that draft should now be considered obsolete, the new one is coming shortly 15:29:32 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 #info More policy rewrites are on the way, should have another draft published soon 15:31:08 #action stickster Update list with new draft once it's ready for review 15:31:13 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 elad661: Agreed 15:31:27 stickster: I already sent my suggestions on the list - does it make sense to discuss the outdated draft more ? 15:31:34 nah 15:31:48 mclasen: And thank you for suggestions, I have them on my list to incorporate too 15:32:04 Anything else before we move on? 15:33:16 #topic Open seat 15:34:10 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 He said he'd accept it, didn't he ? 15:35:41 I believe so, but he did say meetings might be hard to attend more than partway through. 15:36:09 we could try to find a time that works better for him... 15:36:29 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 oh, right 15:36:42 we're expanding globally 15:36:53 #action stickster Start input gathering (via whenisgood.net) for new meeting time. 15:37:45 as for michael, I think he would be a good choice to fill the open seat, +1 from me 15:37:47 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 +1 from me 15:39:10 otaylor: kalev: rdieter: cschalle: ? ^^ 15:39:19 +1 15:39:21 +1 15:39:24 otaylor: +1 15:39:50 +1 from me as well 15:40:23 #agreed Michael Catanzaro accepted for open seat (+6, -0, 2 not present) 15:40:44 #action stickster Notify list and fix Workstation wiki page 15:40:51 Anything else before we move on? 15:41:18 #topic Third party repositories 15:43:07 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 correct 15:43:53 ok, seems like a decent step forward 15:44:13 That's on a case-by-case basis, so we need to provide a justification for why to include another repo. 15:44:38 the council would like to see proposals/justifications that refer to the gains Fedora could have by including such a repo 15:44:42 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 h264 15:44:52 yes! 15:45:21 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 that was it could come from cisco servers, but still be discoverable in fedora 15:45:33 *that way 15:46:03 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 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 stickster, maybe, but the justification for Chrome is likely to be quite similar to the justification for Steam for instance 15:47:08 Agreed 15:48:12 http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_table is interesting. 15:48:53 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 I'm not sure I understand the point, can you restate? 15:49:55 i read that as "more apps == more users overall" 15:50:09 OK, I get that now 15:50:13 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 *nod 15:50:51 * jwb wonders what the compounding formula for app/users is 15:50:51 :) 15:51:16 jwb: It probably has to do with pi 15:51:55 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 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 that are floating around the internets 15:52:50 *nod 15:53:21 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 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 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 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 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 which is an implicit endorsement :) 15:55:58 More an acknowledgement of reality? 15:56:21 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 (for example) 15:56:34 Yup 15:57:28 Curating a list (which is really what the Council decision amounts to) means tacitly acknowledging the list has value 15:57:40 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 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 mclasen, yes. but one person's reality is another's lawsuit ;) 15:58:50 cschalle, yes, definitely 15:59:25 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 Thanks kalev 15:59:33 kalev, thanks 16:00:04 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 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 Or has everyone just gone to lunch? :-) 16:02:47 * mclasen still here 16:02:51 that's a good onlist topic, to solicit suggestions 16:03:05 I think we had a short-list of candidates already 16:04:07 openh264, chrome, pycharm, steam 16:04:24 pycharm is in a COPR, right? 16:04:28 of those, pycharm is covered by copr, yes 16:04:33 pycharm is a COPR, so it's OK at this poitn. 16:04:34 only copr content is eligible currently 16:04:36 point, even. 16:04:39 pick from the other three 16:05:10 I would like to see us try OpenH264 because it's demonstrably open source 16:05:15 you might go ahead and bundle the pycharm disabled repo file into something though. that will make the feature technically usable 16:05:20 or is the question about what to add next? (if so, I misinterpetted) 16:05:23 jwb++ 16:05:27 steam is a bit more complicated because of where it is currently hosted 16:05:40 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 I don't know enough about Steam yet to suggest it 16:05:53 stickster, we are still blocking on RH legal for that one 16:06:00 cschalle: Oh, oof. 16:06:01 stickster, for OpenH264 16:06:03 ahh, ok 16:06:14 (you might also try including the Chromium COPR) 16:06:15 and it's missing the Cisco side with rpms anyway, right? 16:06:23 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 now, if steam agreed to distribute it, then it should be in the same class as chrome 16:06:58 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 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 sounds fine with me 16:07:55 we'll need someone to pick up the Chromium copr maintainance in that case, though 16:08:11 kalev: Is that basically unmaintained right now? 16:08:19 Or is spot still keeping that up? 16:08:24 it didn't have F22, last time I looked at least 16:08:28 there's two i think. 16:08:47 https://repos.fedorapeople.org/repos/spot/chromium/ , F21 last updated in january 16:08:51 kalev, hardly anything has f22 in copr. they just added chroots there like last week 16:08:56 I'm sure there have been security updates in the meanwhile 16:09:09 ok, that's a good point too :) 16:09:22 anyway, is tpopela working on Chromium for RHEL? 16:09:29 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 kalev, he is, but we are trying to get him off it :) 16:09:59 ahh :) 16:10:35 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 kalev, because Chromium is basically Chome without all the things that wants you want to use Chrome 16:11:10 #proposed Work up justification for Chrome and present to Council within next 1-2 weeks 16:11:23 stickster, I be happy to work with you on the proposal 16:11:31 * stickster happy to accept all help 16:11:32 err justification 16:12:03 or proposed justification or justified proposal - your pick 16:12:05 ha 16:12:12 Anyone opposed? If not, we'll run with it 16:12:52 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 kalev: Agreed, I'll help with that too 16:13:21 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 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 awesome, thanks 16:15:39 #agreed Go for Chrome next 16:16:12 #action cschalle stickster work up justification for Council and review gnome-software text for an appropriate warning to suggest 16:16:28 OK, anything else before we adjourn? 16:16:38 #topic All Other Biznatch 16:17:36 Sounds like not. 16:17:47 OK, thanks for coming everyone, and have a great day/evening :-) 16:17:51 #endmeeting