13:01:58 #startmeeting Workstation WG 13:01:58 Meeting started Mon May 8 13:01:58 2017 UTC. The chair is mclasen. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:58 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:01:58 The meeting name has been set to 'workstation_wg' 13:02:06 .hello catanzaro 13:02:06 mcatanzaro: catanzaro 'Michael Catanzaro' 13:02:23 * mclasen bangs the drum 13:03:15 hello! 13:03:37 while we wait for people to appear, any agenda items we should add beyond https://pagure.io/fedora-workstation/issues ? 13:04:21 .hello ryanlerch 13:04:22 ryanlerch: ryanlerch 'Ryan Lerch' 13:05:05 hi kalev! 13:05:19 * mclasen counts to 4, I guess we need one more 13:05:22 hi mcatanzaro, mclasen 13:05:46 hi ryan 13:05:57 warming up over there? 13:06:14 still cold 13:06:42 yeah, its getting cold here at the moment 13:06:50 got down to 16C last night 13:06:53 brrrrr 13:06:58 .hello rdieter 13:06:59 rdieter: rdieter 'Rex Dieter' 13:08:03 * sgallagh lurks 13:08:24 ok, I guess we have a quorum 13:08:29 (or I can pretend to not be here if folks would prefer to avoid a meeting :) ) 13:08:30 but let me see if I can scare up cschaller 13:09:19 ok, he should be here in a minute 13:09:20 ryanlerch, 16C would be great its 8c here now 13:09:47 lets get started with an easy topic 13:10:04 * cschalle wave 13:10:09 #topic https://pagure.io/fedora-workstation/issue/10 Include gnome-terminal-nautilus by default 13:10:37 not sure this needs any discussion... 13:11:22 anybody opposed to this ? 13:11:26 I am in favor 13:11:43 yeah, a +1 form me too 13:11:46 +1 to this for years 13:11:48 +1 13:12:01 when gnome-terminal-nautilus first appeared upstream and I added to subpackage to fedora, I was planning to ask nautilus upstream if they think this is something we should add to default install or not 13:12:05 but forgot to do it of course :) 13:12:12 +1 from me too 13:12:24 so this is a gnome-terminal subpackage ? 13:12:27 yes 13:12:42 I think aday did not want this installed by default. 13:13:07 I like it, though. I think users can probably just not use it if they don't understand it. 13:13:33 cschalle: abstaining ? 13:13:42 sorry I am late 13:13:48 +1 13:14:00 it is realtively low imapct, andit is useful for our target audence in Workstation IMHO 13:14:06 juhp: hey! 13:14:09 mcatanzaro, we have users coming from other distros that say that it is strange that Fedora does not include that by default 13:14:14 hi 13:14:49 #agreed add gnome-terminal-nautilus to by default 13:15:30 +1 13:15:37 any volunteer to do this - kalev, can you ? 13:16:07 yep, happy to 13:16:12 cool 13:16:19 * mclasen updates the issue 13:17:02 #topic https://pagure.io/fedora-workstation/issue/13 Packaging guidelines for application independence 13:17:09 this one may require some discussion... 13:17:28 Yupp 13:17:30 mcatanzaro: do you want to introduce this ? 13:17:57 So the basic issue is that GNOME Software does not handle very well the case where one application depends on another -- at least last I checked 13:18:13 We can either modify GNOME Software or modify the packaging guidelines to prohibit this. Or both. 13:18:34 E.g. GNOME Software could start displaying a message to inform the user when it's about to install or remove another application. 13:18:40 I think it better/easier to adjust gnome-software to expectations. the case of one app depending on another is not uncommon 13:19:29 rdieter, right 13:19:30 prohibiting that is... going a bit far, in my opinion 13:19:34 I wrote https://fedoraproject.org/wiki/PackagingDrafts/IndependentApplications on the assumption that the GNOME Software developers (hi kalev ;) still consider this a distro packaging bug. It is definitely intentional that it does not currently handle this well. 13:19:49 while I agree that the ideal case is applications that are standalone, the issue with guidelines like this is that there is little one can do in the concrete case, short of rearchitecting the application(s) 13:19:50 mcatanzaro: is this the case of installing a package (with a desktop file, as it is shown in software) OR a package that has two desktop files (not sure this is a thing or not) 13:20:19 But if we modify GNOME Software, we could still keep those guidelines and try to push them through... but if so, I would change the MUSTs to SHOULDs. If we do not modify GNOME Software, I think we should keep them as MUSTs because it's frankly just broken right now. 13:20:33 ryanlerch: Both. 13:21:03 can you describe in what way it is broken ? 13:21:08 does it crash ? 13:21:17 ryanlerch: In the end, applications (desktop files) have to be independently installable and removable for them to work properly in GNOME Software right now, without mysteriously appearing or disappearing when installing/removing an unrelated application. 13:21:19 is the user experience hard to understand ? 13:21:26 is it showing bad ui ? 13:21:31 oh, applications get installed silently? 13:21:42 Hard to understand. Applications appear from nowhere, and disappear with no explanation, if they depend on each other. 13:21:42 I think this is a mostly of silent behaviour being confusing 13:22:02 kalev, what do you suggest we do? 13:22:08 mcatanzaro: but aren't users used to dependencies silently appearing as needed ? 13:22:27 thats been the status quo in package world for a few decades, after all... 13:22:44 mclasen: I don't think so, no. I am not used to seeing strange applications that I don't want installed on my system without my permission. 13:22:51 AIUI, we want to keep a 1:1 relationship between a application shown in Software, and in the menus when installed. 13:22:54 I think the dependencies silently appering on install is usually fine, it's a bit confusing but this could be something we can live with 13:23:08 but then the user finds a new app that silently got installed and tries to remove it 13:23:10 oh, this is why I have QT Designer installed now? aha! 13:23:21 ... which can silently uninstall other apps 13:23:22 ok, in that case I'm definitely against changing guidelines to accomodate this 13:23:23 I don't think it's fine. 13:23:50 kalev: uninstalling quietly is more of an issue, I agree 13:24:37 maybe warning when uninstalling removes other apps could be a good idea 13:24:39 A lot of times these are really... not great applications too. Think icedtea-control-panel, log4j, openjdk-policy-tool... most Java users don't want to see these. And yes, Qt Designer/Creator as well. 13:24:57 we already do this during system upgrade if upgrading removes anything 13:25:33 So this is why I propose the packaging guidelines change, even if it's only with SHOULDs rather than MUSTs, because a lot of our existing examples of such problems are gratuitous packaging issues, not cases where one app really depends on another, but cases where the packager is just wrong/lazy. 13:26:16 kalev: I would like to show a warning both when uninstalling and when installing. 13:26:21 mcatanzaro: is there an easy way to identify the offending packages? 13:27:06 I don't think making more policy/guidelines will help (much) here. If it's already obvious dependencies are too much, more policy isn't going to magically fix that 13:28:06 moving to other packaging that is more isolating will help more (...flatpak) 13:28:07 and, there are cases where these dependencies are definitely (still) needed 13:29:00 rdieter: are there still examples of this in KDE apps? 13:29:21 IIRC, kate was in a kde-sdk package many moons ago 13:29:43 this is a good example of what the new policy would not allow 13:29:45 ryanlerch: most apps are split up now. there are probably some exceptions left 13:30:01 rdieter: That's why I'm suggesting SHOULD rather than MUST. Sometimes the dependency really is needed. mclasen's example is a video game level editor, which obviously must depend on the video game. 13:30:08 kalev: do you think it will be a lot of work to make g-s warn about uninstalling other applications ? 13:30:48 rdieter: But I really think a majority of the current cases are just bad packaging, hence it's worth adding recommendations to the guidelines to avoid this. (Replace all the MUSTs with SHOULDs if we modify gnome-software.) 13:30:51 mcatanzaro: again, I don't think making more policy here will help. If it's obvious a dependency is not really needed now, that's already a bug that should be fixed 13:31:07 13:31:12 mcatanzaro: do we have a recommended packaging-level workaround for the problem ? have a shared -common subpackage, and move just the desktop files to separate app packages ? 13:31:13 mclasen: I think it should be rather easy, IIRC I added some plumbing to make this possible when I did the same warning for system upgrades 13:31:54 rdieter: maybe not policy then, but just a free-worded note in the guidelines to remind this when packaging up apps? 13:31:58 mcatanzaro: that said, I'm not against your taking it to FPC anyway, I supposed it can't hurt 13:32:22 as in, just to get the idea across without having the SHOULDs and MUSTS and all the legal speak in there :) 13:32:33 kalev: true, I don't think it's codified that apps should be packaged separately 13:32:34 rdieter: In my experience, we've had mixed success trying to explain to package maintainers the need to put applications into subpackages. E.g. this was one of the (multiple) reasons we decided to remove the Java browser plugin, because the package maintainer wouldn't split the accompanying applications into subpackages. Having a clear guideline would be beneficial here IMO. 13:32:56 mcatanzaro: true, that part I agree with 13:32:56 mclasen: Yes, that's the workaround I would suggest. 13:33:21 my primary objection is about prohibiting dependencies 13:33:48 prohibiting desktop files? 13:33:55 packaging apps separately is definitely a best practice that should be encouraged strongly 13:34:13 If kalev can make gnome-software display a warning, then I don't think we need to prohibit app dependencies. Just suggest that packagers use subpackages to avoid them when possible. 13:34:29 I think that would be a good way forward here 13:34:49 ok, whats the action here - do we take this to the fpc to discuss the best way of expressing this best practice in the guidelines without SHOULDs or MUSTs ? 13:35:04 nooooo, FPC is just about rubberstamping guidelines that other people write up 13:35:10 we need to do the writing up here 13:35:17 ok 13:35:40 #action kalev will look at making gome-software warn if other applications are uninstalled as a side-effect 13:36:23 mcatanzaro: do you want to take a stab at rewording the proposal ? and we vote on it next time ? 13:36:59 So far the only thing I would reword is MUST -> SHOULD. Does anyone else have a suggestion for something that should be changed? 13:37:29 I guess the first sentence could be more qualified: "Applications SHOULD be installable independently whenever technically feasible." 13:37:55 I think it's a bit hard to read with lots of MUSTs and SHOULDs 13:38:36 * mclasen not a fan of those rfcisms either 13:38:49 kalev: Also, can you clarify that gnome-software does or does not follow Recommends and Supplements when installing packages? 13:39:29 oh right, that was an open question 13:39:32 maybe something like "When packaging applications that also ship libraries that other apps may depend oe, make sure to split out the libraries and the app in separate subpackages. This makes it possible to install one app that depends on the libraries without pulling in the other app." 13:39:34 I think it could be simplified a bit to 2 simple SHOULDs 13:40:18 * mcatanzaro editing, almost done 13:40:41 mcatanzaro: I believe gnome-software follows REcommends and SUpplements the same way as DNF does 13:42:47 mcatanzaro: should we wait for you to finish editing, or move on to the next topic ? 13:43:23 #topic https://pagure.io/fedora-workstation/issue/12 provide a clean set of default wallpapers 13:43:32 ryanlerch: did you make progress on that ? 13:44:24 mclasen: discussions on the Design team list were good.Just waiting on a concensus on which 15 wallpapers to use. 13:44:46 sounds like this is underway then, and we just nod happily 13:44:52 mclasen: Let's wait a sec 13:44:53 I also created the basework of the package to add them 13:45:08 Oh you've moved on, OK 13:45:11 the other piece of the puzzle is the current GNOME backgrounds 13:45:18 (I'm done, we can return to it after wallpaper discussion though.) 13:45:28 cool, lets do that 13:45:45 currently, they are all shipped in a single pacakge (the default adwaita ones, and the other default ones) 13:46:08 ryanlerch: do we need to split it up in order to just include the adwaita ones by default ? 13:46:34 * ryanlerch is not an expert packager, but that was my thought exactly 13:47:17 i.e. adwaita in gnome-backgrounds, and the others in a gnome-backgrounds-extras subpackage 13:47:35 do you want to give that a try ? 13:47:53 mclasen: it is on my list for tomorrow :) 13:47:59 cool 13:48:19 #action ryanlerch will split gnome-backgrounds package 13:48:40 anything else on wallpapers ? 13:48:47 kalev: i'll try to get my suggested changes to you tomorrow :) 13:49:25 ryanlerch: sure, send them my way! 13:49:25 lets move back to independent applications, then 13:50:00 #topic https://fedoraproject.org/wiki/PackagingDrafts/IndependentApplications 13:51:47 lets vote on whether to send this text to the fpc 13:51:53 +1 from me 13:51:56 +1 13:52:01 +1 from me 13:52:13 I think this probably ought to be taken in baby-steps, I personally would omit the suggestion about splitting out desktop files 13:53:07 I'd be fine with either this or with baby steps too 13:53:31 I can't in good conscience vote for this with that text included, would you mind removing it? 13:53:46 (and consider submitting that separately for consideration) 13:54:00 so you would prefer a proposal that has the SHOULDs but omits all implementation guidance ? 13:54:38 simply say applications and their .desktop files should be packaged into separate subpacakges, and leave it at that 13:55:17 or simply leave out "the .desktop files should generally be packaged separately from the application itself in order to feign this effect for users." 13:55:54 replace with "In cases where this is not feasible for technical reasons, if a single source package provides multiple applications with .desktop files, those .desktop files should be packaged in separate binary packages..." or something to that effect 13:56:19 https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FIndependentApplications&diff=492415&oldid=492137 13:57:00 where the primary purpose of that explanation text is about packaging apps into separate subpackages 13:57:00 gah, seems we have several rewordings proposed now, and a simple vote won't do... 13:57:32 (and nothing more) 13:58:44 I'd be happy to +1 anything to get a bit of improvement here :) 13:58:54 doesn't have to be a long and complicated text, just one line that mentions that apps should be packaged separately should be already a big improvements over the status quo 13:59:00 +1 13:59:04 It looks okay to me basically 13:59:28 so, what is the outcome here. I have seen 5 +1's but also suggestions for text changes 13:59:29 (+1 to kalev's comment, in case there's ambiguity) 13:59:31 We should return to this at the next meeting. Or on the ticket. 13:59:32 kalev, +1 13:59:44 We have suggestions for text changes that I can't process in the next one minute. ;) 13:59:53 should we revisit this next time ? 14:00:00 ok 14:00:01 sounds reasonable 14:00:04 * kalev nods. 14:00:09 * rdieter happy to vote in the ticket too 14:00:18 I'm +1 with the .desktop splitting text omitted 14:00:22 #action Independent Applications proposal will be revisited next meeting, with a reworded proposal 14:00:24 * ryanlerch happy to vote in the ticket too 14:00:37 with that, we are done with the hour 14:00:46 just one minute for open floor topic 14:00:50 #topic open floor 14:01:21 just one informational item: I've started to write up some notes on the langpack issue that was raised on the mailing list in jiris's laundy list 14:01:34 https://fedoraproject.org/wiki/Workstation/LangPacks 14:01:44 happy for contributions there 14:01:49 mclasen, thanks 14:02:00 in particular from your side, juhp 14:02:17 ok with that... 14:02:24 Also, if anyone has any ideas for Magazine posts, ping me! 14:02:44 the MP3 one went pretty well over the weekend 14:02:56 yay to that 14:03:24 #endmeeting