15:00:18 #startmeeting 15:00:18 Meeting started Wed Aug 27 15:00:18 2014 UTC. The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:19 #meetingname workstation 15:00:19 The meeting name has been set to 'workstation' 15:00:19 #meetingtopic Fedora Workstation Meeting 15:00:19 #topic init 15:00:19 #chair jwb cschalle mclasen cwickert otaylor ryanlerch kalev 15:00:19 Current chairs: cschalle cwickert jwb kalev mclasen otaylor ryanlerch 15:00:25 hi everyone 15:00:47 * nirik is lurking around in the back. 15:00:52 * elad661 is here too 15:00:52 hello hello 15:00:56 #chair juhp juhp_ 15:00:56 Current chairs: cschalle cwickert juhp juhp_ jwb kalev mclasen otaylor ryanlerch 15:01:03 hi 15:01:40 did anyone hear from ltinkl ? 15:01:41 * stickster here 15:02:15 * mclasen didn't 15:02:24 not sure he's interested in Workstation any more 15:02:33 i'll have to follow up on that 15:02:43 you may be right kalev 15:03:28 ok, let's get going 15:03:49 #topic Apps and Launchers Guidelines 15:04:08 so elad661 was kind enough to write up some guidelines around Apps and Launchers 15:04:13 https://fedoraproject.org/wiki/User:Elad/Draft_app_guidelines 15:04:19 did everyone have a chance to review them? 15:04:20 * cwickert is here 15:04:24 hi cwickert 15:05:07 the guidelines seemed sensible to me 15:06:12 i believe at the moment this is a Workstation specific policy. my only major concern was it might deviate us from the rest of the products unnecessarily, but i can probably be easily convinced that isn't a huge issue 15:06:20 I looked through them. I think they generally look good ... I'm a bit concerned about the MUST/MUST NOT language ... what does that actually mean in the end? 15:06:51 it feels like borderline packaging guidelines material ? 15:06:55 otaylor: "An app or launcher that fails to complies with these guidelines MUST NOT be included in the default install." (OK, a bit circular but...) 15:07:17 Also, that's a blocker for WS as I understand it. 15:07:25 mclasen, yes, that is what i was thinking but i'm not sure the FPC would agree 15:07:44 we should probably use words MUST, SHOULD and so on according to https://www.ietf.org/rfc/rfc2119.txt 15:07:52 yeah, the FPC will never agree to these guidelines 15:08:03 Not across the entirety of the distro, I think.' 15:08:07 as I wrote they are not aimed at ALL software in the distro 15:08:15 stickster: Yeah, but presumably if we found that some app that we were including in the default install didn't have a hi-color icon, we wouldn't just remove it and move on ... we'd evaluate the situation, try to move on 15:08:16 cwickert, i believe that was the intention 15:08:40 otaylor: exactly my intention. 15:08:46 jwb: this being said, we should look if everything is all right, but overall the guidelines seems to make sense 15:08:46 stickster: for the sentence about the default install, that should just say 'will not be included' or 'may not be included', imo - it is after all us who define the default install, not the app developers/packagers 15:08:46 cwickert: With the RFC, it's pretty clear that if you violate the RFC you don't comply with it. Here I think MUST and SHOULD are just being used as proxies for "high priority" "less high priority" 15:09:16 ack 15:09:20 otaylor: correct. 15:09:36 mclasen: Sure -- could be revised to say "...An app or launcher that fails to complies with these guidelines must be considered by the WS group before it can be included in the default install." Or s/th similar. 15:09:41 considering we are keeping the 'installed by default' list very short, I think a MUST is fine, I mean for the 1 or 2 apps that might include we should have enough graphics artists at hand to get artwork made 15:10:04 cschalle++ 15:10:10 cschalle++, it's hard to imagine we couldn't fix such a problem in a package quickly if needed. 15:10:35 however if a packager refuses to fix an issue, we will remove the app from default 15:10:42 * stickster realizes he is kind of... jumping in here as a lurker. Will be more lurky. :-) 15:10:50 we can't ship something without high quality icons 15:10:59 it would look *bad* 15:11:11 we did that before and the reactions were not positive at all iirc 15:11:44 elad661, is that a real possibility? I have a hard time believing a packager would refuse an offer to spruce up the artwork for her/his package 15:12:06 cschalle, oh it happens a lot 15:12:26 poor jimmac has had lots of icons refused in the past 15:12:29 In the packages we would want in the default? 15:12:34 aday, ah like the Darkroom icon jimmac made? 15:13:20 stickster: no, I don't think so 15:13:50 cschalle: sometimes maintainer refuse to accept icons, or desktop file category fixes, or refuse to separate stuff to subpackages 15:13:55 well it sounds reasonable overall to me - are there any numbers for how many packages would need changing to comply? 15:14:03 cschalle, possibly. there's plenty of examples 15:14:29 elad661: I can only speak for myself, but I'd be fine if you came to FESCo asking for a ruling that packagers MUST accept contributed icons that are a higher-resolution version of any icon they already have. 15:14:54 (And that by extension, provenpackagers therefore have blanket approval to commit said icons) 15:15:10 juhp_ ++, yeah, I think the requirement to re-package stuff to avoid multiple apps from one package is probably more resistance, but once again I doubt it will be a problem for anything we want to ship by default 15:15:13 sgallagh, part of the issue is that many existing icons are extremely poor. simply rendering at a higher resolution isn't sufficient - there needs to be some artistic reinvention 15:15:23 did any *packer* ever reject an icon? 15:15:27 and at that point things get tricky 15:15:35 this only happened with upstreams afaik 15:15:45 * stickster suggests that if the numerous cases being cited are likely outside the defaults this could be a separate conversation from whether the guidelines are good (which they look to be) 15:16:01 drago01, ah true. don' know about packagers 15:16:16 stickster: Java maintainers disagreed to separate their launchers to subpackages, for example 15:16:21 or to change the naming to be sensible 15:16:52 and we do have Java by default 15:17:22 yeah, I think for the 'release blocking' stuff I think everything in the guidelines is non-controversial. There might be install able stuff where we need to spend energy convincing the packagers, but since the MUST don't (yet) apply to them I don't see that as a blocker for approving these guidelines 15:17:24 if we're talking about guidelines, we have a bunch of material in the hig now - https://people.gnome.org/~tobiasmue/hig3/application-basics.html 15:17:54 https://people.gnome.org/~tobiasmue/hig3/icons-and-artwork.html#application-icons 15:18:04 elad661: what is the rationale behind the 'packaged separately' requirement? 15:18:05 aday: is that link stable? I wanted to link to the HIG from the guidelines but I couldn't because I didn't know if the links will stay 15:18:15 But anyways, not a blocker for me :-) 15:18:15 so i think, mostly, these guidelines are there so we have something to fall back to that documents what we'd like to see 15:18:15 they originated from some other issue (icetea-web maybe?) and sgallagh asked elad661 to write them up 15:18:15 with that in mind, i think they're pretty good. we can put them under a policies page off the workstation wiki and use it as a reference going forward if we all agree 15:18:16 I am not sure we really need Workstation-specific guideline like that 15:18:16 It seems like we want the applicable parts of these guidelines to be included evenutally in the packaging guidelines, otherwise the nice clean behavior of one app/one desktop file, etc, will be lost as soon as the user starts installing stuff. Most of this isn't just applicable to installed-by-default. 15:18:16 might make sense to push for some of those items to go to actual Fedora-wide packaging guidelines 15:18:16 and just say in Workstation documents that "Workstation WG chooses what apps to include in the default install. Default apps will be chosen to fit in with the rest of the product and are required to be high quality." 15:18:16 kalev, well that was my concern as well, but if we're going to do that we need to remove the GNOME specific language 15:18:16 ... or something 15:18:23 elad661, launchers supposed to be subpackaged from the apps? 15:18:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1131248 -- bug concerning some issues on java packages 15:18:30 otaylor: while I agree to (most of) these guidelines for the workstation product, I don't think they should become part of the packaging guidelines as different desktops have different menus. take the huge icons, there is no need for them in say Xfce or KDE. 15:18:31 I don't know how we ended up with 256x256 anyway, that seems a bit excessive ? 15:18:31 +1 15:18:31 and does it really matter if we have SVGs? 15:18:32 s/if we/given that we have/ 15:18:34 elad661, no. we'll have a stable link once 3.14 is out 15:18:44 juhp_: only if there's more than one launcher 15:18:44 mclasen: hidpi 15:19:06 elad661, okay 15:19:14 * cwickert thinks his irc backlog is messed up, please bear with me if I confuse something 15:19:15 cwickert: the rationale is I want to be able to install Libreoffice without getting 3 new "apps" appearing in my installed list or app view 15:19:50 cwickert, well but we want XFCE and KDE applications to be available in the workstation, so just because the host desktop environments doesn't need something doesn't mean we should not aim for supporting it in Fedora for the Fedora Workstation 15:20:25 cwickert: SVGs don't look good scaled down, and doesn't scale up well either sometimes 15:20:37 jimmac explained that many times 15:20:40 cwickert, I think the graphics artists have cooled on SVGs as a solution 15:21:33 sigh 15:21:38 ... 15:21:43 seems we lost half the working group there 15:21:53 oh, netsplit in the middle of a meeting is no good :( 15:21:59 :-( 15:22:07 now they are gone 15:22:08 elad661: well, in case of LibreOffice, I think it makes sense to have different launchers. I know many people who want to launch a certain component directly, in fact most of the users are used to that concept from MS office 15:22:26 cwickert: each app in libreoffice is not the same app 15:22:31 "libreoffice" is not one app 15:22:35 there's Writer, and Calc 15:22:39 they are not the same app 15:22:39 right 15:22:46 an svg certainly scales better than a small png, so I think an svg thats designed for larger size is an acceptable answer 15:23:02 wb 15:23:29 isn't libreoffice already separated? 15:23:40 elad661: so it is "one launcher per app", right? Did we ever have a case where the same app, as in the same binary, has different launchers? 15:23:46 they come from the same suite, but they are not the same thing 15:23:58 seems that everyone are back 15:24:01 cwickert: yes 15:24:05 cwickert: but it was in the past, and we fixed it 15:24:08 elad661: such as? 15:24:15 ok, I see 15:24:21 ok, so where are you guys at. because we're clearly not at the same place :) 15:24:25 yay netsplits 15:24:40 jwb: cwickert was asking about the "one launcher per app" think 15:24:42 jwb: we were here all the time :P 15:24:43 *thing 15:24:58 summary of that discussion? 15:25:03 now they are gone 15:25:03 elad661: well, in case of LibreOffice, I think it makes sense to have different launchers. I know many people who want to launch a certain component directly, in fact most of the users are used to that concept from MS office 15:25:03 cwickert: each app in libreoffice is not the same app 15:25:03 "libreoffice" is not one app 15:25:03 there's Writer, and Calc 15:25:07 they are not the same app 15:25:09 ok, that is now clear 15:25:09 next question: SVGs 15:25:09 cwickert: if you look at libreoffice, it is just one binary with different shell script wrappers 15:25:10 mclasen: right 15:25:55 mclasen, elad661: just to be sure: are you suggesting we should no longer have different launchers for writer, calc and so on? 15:25:56 well wheter it is one binary or not doesn't matter 15:26:11 elad661, I mean doesn't libreoffice already follow your guideline? :) 15:26:20 juhp: it does 15:26:23 cool 15:26:25 no, the intention is to make sure 1 package == 1 launcher 15:26:26 ok 15:26:31 cwickert: no, the suggestion is that the launchers for each app should be independently installable 15:26:42 libreoffice is not one app 15:26:49 Calc is an app, writer is a different app 15:26:49 so in the case of libreoffice, the intention is to make sure writer is split out to a separate package, calc into another etc 15:26:54 kalev, mclasen: wow, how would you achieve that? 15:27:11 I think that's already the case, no? 15:27:18 afaik, yes 15:27:18 libreoffice complies with my guidelines quite well, the only problem is that they pull java which comes with two launchers, but we are working to fix that 15:27:19 it is 15:27:19 cwickert, well the 'split' can be as small as having the .desktop files in different packages, all depending on the same root package 15:27:26 I think we all agree on libreoffice already :) 15:27:43 cwickert: you make small packages that depend on a big, faceless package containing the actual binary 15:28:29 cschalle, mclasen: sure, but how do you make sure the packages are actually getting installed? 15:28:38 cwickert, rpm dependencies 15:28:39 I guess it was just an example of a source package with multiple separate launchers/apps 15:29:20 changing the packaging for everybody just for the requirements of the workstation seems counterproductive if you want to reach bigger acceptance of the workstation and it's criteria 15:29:26 1 package == 1 launcher is the part that I think would make sense to put in the fedora-wide guidelines 15:29:40 cwickert, well I doubt cloud or server cares about how desktop applications gets packages 15:29:46 s/packages/packaged/ 15:30:35 Hm, am I adrift or is everyone else? 15:30:44 stickster: you are. there were netsplits. 15:30:47 cschalle: believe it or not, there are other desktops than GNOME ;) 15:30:49 stickster, netsplits do that 15:30:55 cwickert, yes, but not among the Fedora products 15:31:06 OK, I seem to be back :-) 15:31:16 cschalle: sure, but once you want to do something on a packaging level, it affects not only the products 15:31:23 cwickert, and it helps with any installer front-end 15:31:46 cwickert, no, but that is the point of the products right? to set standards so we can create a good user experience, and not just be a big collection of random packages 15:31:47 cschalle: do you think this is a very controversial idea ? 15:31:48 hadess: that was my previous question: how can we install the launchers? 15:31:53 mclasen, not really 15:32:01 so off in our own corner of IRC land, otaylor had proposed that we adopt these guidelines as a Workstation policy for now, and we start conversations with the rest of the products/WGs on what we can find in common 15:32:02 cwickert: subpackage per launcher if package has more than one launcher 15:32:21 jwb, ++ 15:32:34 cwickert: I think non-gnome desktops will like it too, because you install one app in the installer and get one app 15:32:38 you don't get more than you asked for 15:32:44 and you get no surprises when you remove apps 15:32:56 jwb++ 15:33:08 elad661: I see your point, howerver there are other examples 15:33:36 keeping in mind this is mostly to have a fallback for why something is or is not included by default 15:34:37 cwickert: such as? 15:34:55 is otaylor's proposal something we can agree to for now, and then work on going forward? netsplit has eaten a bunch of time and we have 3 more topics to get through in 30min 15:35:10 jwb: I think so, yes. 15:35:47 elad661, i mean no offense but i was asking the WG members :) 15:35:48 elad661, might be good to add some instructions on how to deal with tools specific to other desktops. So if someone installs for instance XFCE, that doesn't mean they want all GNOME tools showing up under XFCE or for that matter all XFCE tools showing up under GNOME 15:36:03 jwb, agreed 15:36:09 or we could postpone and digest for another week and look at more pressing matters now? 15:36:21 kalev, sure. we could also postpone for further discussion 15:36:26 cschalle: I don't see how this is related. 15:37:00 elad661, well the guidelines are mandatory for our default installs, but I also see them as 'best practices' for anything packaged for the Fedora desktop 15:37:16 kalev, why postpone? I mean otaylor suggestion is not very controversial 15:37:19 cschalle: then they should go to the Fedora-wide guidelines, not sit in our small corner 15:37:27 cschalle: let's discuss this after the meeting 15:37:31 kalev, we have to start somewhere :) 15:37:40 i don't care which we do, but we should pick one or the other and move on 15:37:57 sure, we could start somewhere by picking the most important item there and try and push it Fedora-wide 15:38:45 right now we are in a situation where we reserve the right to pick apps we think make sense for the default installation 15:38:46 after the guidelines, the situation is exactly the same 15:38:46 ok, so lets do a vote on the proposal. I vote ++ to the suggestion jwb posted from otaylor 15:38:50 To restate for now: Proposal: approve this for now, as set of policies for the default installed apps, recognizing that there are quite a few parts of it which really belong as recommendations for apps included in Fedora 15:38:53 but what I'd like to get is to improve apps and launchers and packaging project wide to get more high quality stuff 15:39:10 kalev: That's not mutually exclusive. 15:39:29 ok, cschalle has called for a vote. So please VOTE 15:39:31 +1 15:39:38 +1 15:39:41 kalev, don't let the perfect be the enemy of the good 15:40:11 +1 15:40:25 0 15:40:45 cwickert, ? 15:40:50 though I am curious to hear of other examples 15:41:16 mclasen, ? 15:41:58 let me give you an example: midori can be started in normal mode and in private mode, thus it comes with two launchers 15:41:59 would we make a "midori-private-mode" subackage then? 15:42:00 cschalle: I think the point of the products is to set standards for the good user experience of the products, but not for everybody. if you force standards that others cannot understand on them, then then this will not help the acceptance of your product 15:42:00 * cwickert seems to be netspiltted again 15:42:09 aargh 15:42:54 cwickert: or hide the private mode launcher in gnome 15:43:01 cwickert: fwiw private mode shouldn't be a separate launcher 15:43:14 cwickert: no other browser does it that way 15:43:21 anyway, that's why this policy is for the defaults 15:43:35 now please all WG members vote and move on 15:43:37 cwickert: For the purpoes of this vote - that would prevent us from including midori by default, yes 15:43:55 i think cwickert was netsplitted for the proposal/vote call 15:44:11 11:38 < otaylor> To restate for now: Proposal: approve this for now, as set of policies for the default installed apps, recognizing that there are quite a few parts of it which really belong as recommendations for apps included in Fedora 15:44:43 cwickert, but the user experience of the products is a sum of its parts, including the Fedora package sets. Anyway, I think we are digressing from the discussion at hand :) 15:44:59 cwickert, right now we're at: +1 jwb, cschalle, otaylor, jhup 0: kalev 15:45:15 jwb, mclasen is re-joining, he got split, he tried to vote +1, but it was obviously in a network of his own :) 15:45:16 the intention is to open discussion with the other products/wgs about commonality later 15:45:19 Freenode network is extremely laggy today... this is going to make the next 15 minutes really hard for us 15:45:27 cschalle, ok, i figured as much 15:45:31 I think we should adopt these guidelines first and foremost as criteria for how we decide about inclusion in the workstation, and look separately at expanding the reach 15:45:45 seems that mclasen is back. 15:45:48 elad661, yeah. i'm going to close the meeting after this. maybe we can try again next week 15:46:05 * mclasen wonders if anybody is still out there 15:46:05 * cwickert is still here 15:46:05 mclasen: I agree. As long as this is just for the workstation, that means the default install, I am fine with it 15:46:05 jwb: yes 15:46:05 elad661: sorry, I'm having problems to follow due to the netsplits. What does your question "such as?" refer to? 15:46:06 cschalle: that is also another important topic, I guess OnlyShowIn and NotShowIn will need to be used a lot 15:46:06 proposal: do not ratify this now, discuss it on the mailing list. I think a lot of us are really confused because of all the netsplits 15:46:06 jwb: in case you missed it, I'm +1 on otaylors proposal 15:46:07 cwickert: OnlyShowIn and NotShowIn are really problematic; I'd like them not to be used at all 15:46:07 mclasen_: I agree it is problematic, but I see no other options 15:46:21 yay! we agreed! 15:46:33 #agree adopt guidelines for Workstation 15:46:42 cwickert, that was to your "other examples" comment 15:46:48 #info jwb to start discussion with other products/WGs 15:46:59 * jwb still has no idea if zodbot is alive or nto 15:47:08 zodbot: ping 15:47:09 pong 15:47:12 he is 15:47:15 OK, given IRC is failing us and TWC is apparently under DDoS 15:47:26 should we adjourn and try and out-of-cycle meeting next week for the other issues? 15:47:26 I wonder in which network zodbot was 15:47:38 TWC? 15:47:44 Time Warner Cable 15:47:49 ah 15:48:00 i have a hard stop in 10min unfortunately 15:48:03 jwb, agreed, continuing like this is just going to cause confusion 15:48:18 same time next week? 15:48:23 ok. let's end. i'll send some cleaned up mintues and we can try again same time next week 15:48:23 sounds fine 15:48:42 normally we would meet every other week, but we have things to discuss so it seems warranted 15:48:46 I am for instance not sure what discussion cwickert and I had or not due to the netsplits :) 15:48:54 until then, please continue discussions on the list! 15:49:02 thanks for everyone's patience 15:49:07 #endmeeting