15:00:10 #startmeeting Workstation WG 15:00:10 Meeting started Wed Jan 6 15:00:10 2016 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:10 The meeting name has been set to 'workstation_wg' 15:00:13 #meetingname workstation 15:00:13 The meeting name has been set to 'workstation' 15:00:16 #topic Roll call 15:01:10 .hello pfrields 15:01:11 stickster: pfrields 'Paul W. Frields' 15:01:58 Hi 15:02:04 * rdieter waves, hi 15:02:07 .hello rdieter 15:02:08 rdieter: rdieter 'Rex Dieter' 15:02:32 * stickster holds door open a little longer... hi guys, Happy New Year :-) 15:02:55 .hello mcatanzaro 15:02:56 mcatanzaro: Sorry, but you don't exist 15:03:01 Hunh 15:03:03 You're mean, zodbot 15:03:18 Is zodbot the new meetbot...? 15:03:24 .hello catanzaro 15:03:25 mcatanzaro: catanzaro 'None' 15:03:59 he's been our meetbot practically forever IIRC 15:04:12 Meet the new bot, same as the old bot... 15:05:08 I guess some folks are still on holidays? 15:05:15 mclasen__ around? 15:05:45 I haven't heard from him in the past couple days, might be out -- I know cschalle is back 15:05:53 could be a very short meeting :-) 15:06:36 Well we can still discuss things even if we can't vote. I asked aday to come and discuss with us plans for default-installed GNOME apps. Hey aday, you here? 15:07:00 hey mcatanzaro, yes i am :) 15:07:03 that works for me, I can always take minutes for reference on the list 15:07:19 #chair aday rdieter mcatanzaro 15:07:19 Current chairs: aday mcatanzaro rdieter stickster 15:07:28 mclasen___: was chatting on irc earlier 15:07:51 #info stickster reverses order of agenda since aday is here 15:08:03 #topic Default installed apps 15:09:04 mcatanzaro: i'm following your lead here 15:09:06 mcatanzaro: There are two interrelated topics at play here, methinks: Default installed apps in Fedora Workstation, and upstream GNOME app defaults (now and future) 15:09:15 My original proposal on the list was to drop Empathy, replace Rhythmbox with Music, and replace Shotwell with Photos. aday thinks Music and Photos are not quite ready yet, but he's been pushing their development pretty heavily.... 15:09:25 stickster: Yes, there is the question of how closely we want to hew to upstream. 15:09:55 for posterity, what are the upstream defaults? I assume Music and Photos? 15:10:41 rdieter: Currently we basically ignore the upstream "modulesets" because they are not very good. I would hesitate to call them "defaults" since the modulesets are so bad, we don't really intend distros to adhere to them. 15:10:53 * mclasen___ walks in 15:10:59 We have done a better job in Fedora of deciding what apps should be installed by default and what should not. 15:11:12 photos should have editing and export in time for next fedora 24 15:11:14 #link https://mail.gnome.org/archives/release-team/2016-January/msg00000.html -- proposed upstream moduleset changes 15:11:34 #chair mclasen 15:11:34 Current chairs: aday mcatanzaro mclasen rdieter stickster 15:12:16 But, I am hoping we can clean up the upstream modulesets, and then we will have a nice split between "core" apps that are part of the OS and cannot be removed (but, I think perhaps we should allow "disabling" them, which we currently do not!), and plain "apps" that are not part of the OS which users should install. 15:12:20 there's a roadmap here - https://wiki.gnome.org/Apps/Photos/Roadmap 15:12:28 rdieter: To answer your question, I was under the impression those are *proposed* changes upstream, too... see link above 15:13:04 my feeling is that a few of the 3.22 items are needed to replace shotwell - which would be f25 15:13:15 Yes, those are the changes I propose; I'm pretty confident that we will make something along those lines happen upstream in the short-term future, but there might be haggling over individual apps.... 15:13:30 import from device and nicer album organisation, for example 15:13:41 aday: e.g. import from camera/card, uploading 15:13:46 *1/2 jinx :-) 15:14:18 Regarding Photos vs. Shotwell. Photos is under active development by rishi, and it's looking pretty good from my perspective, but I am not a heavy photo editor and I didn't really have in mind that we had to completely replace all the functionality. 15:14:49 But, if aday and rishi prefer to wait another release, I'm fine with that of course. 15:15:30 It sounded like there was some level of agreement on list that we hold off on making Music + Photos default until F25, FWIW. And speaking as a guy who takes a lot of photos (family, blah blah), being able to take my photos off my camera/SD card easily and work with them seems a pretty fundamental feature... 15:15:49 mcatanzaro: agree that it doesn't have to have feature parity. however, it does need to work reasonably well for core features 15:16:06 it's getting there, but i'm not sure it's quite there yet 15:16:35 the editing features will be quite new also - they might need a cycle to mature 15:17:02 The other issue with Shotwell is that it is completely unmaintained upstream. 15:17:56 I ported it to WebKit2 and added TLS certificate verification (because it was leaking facebook, google, picassa passwords) and wound up just pushing my changes because nobody is watching Bugzilla anymore. I guess Yorba ran out of money. 15:18:17 yes, yorba is no more 15:18:27 is the elementary fork actively maintained? 15:19:00 We basically have to play the risk of some hideous bug/regression/security issue, vs. the risk of consumer unhappiness with what they interpret as a new, crippled default... I'd opt for the former esp. since our goal has been improved polish, experience, and cohesion 15:19:19 aday: It probably is moreso than Shotwell, but I dunno if they have my recent changes yet. Anyway, I packaged a git snapshot for Fedora with my fixes, so I don't mind letting it sit another release, but I'd prefer we don't leave Shotwell indefinitely. 15:19:32 mcatanzaro: +1 15:19:40 mcatanzaro++ also :-) 15:19:45 Agreed, goal is polish, experience, and cohesion, and I guess we're in that tricky place where it's not totally clear which app best achieves that. 15:19:50 hey, wake up zodbot 15:19:52 mcatanzaro++ 15:20:00 Hm, no cookie for you Michael :-( 15:21:00 So my proposal is: change the default app in rawhide after branching for F24, so we get the actively-maintained, nice-looking GTK+ 3 app in the long run, but also have all year to decide to change our minds and revert to Shotwell. 15:21:02 * stickster has no opinion (for whatever that's worth anyway) on Music... don't use RB much, and haven't explored Music 15:21:06 when it comes to apps, linux is all about choice, no ? 15:21:10 I guess we can't vote on that now with four people, but that's what I'm thinking. 15:21:21 mclasen-- ! :-D 15:21:22 mclasen: Don't tell alexl. :) 15:21:53 * stickster tries to summarize for minutes and then we can loop back with the WG members on list 15:22:05 But mclasen is (intentionally or not) bringing up another question, which we asked ourselves a couple years ago: what sort of apps do we really want installed by default? 15:22:40 When we last discussed this topic explicitly on the list, I believe the consensus was that we should install basically nothing by default except core OS components, and let people find apps they want in the software center. 15:22:47 stickster: music still has a little way to go yet, too. no import yet, and it needs polish 15:22:49 #info Photos is still missing some arguably important core features. While we don't necessarily need parity to make a default app switch, consensus is that Photos is not yet meeting a minimum bar to make it a comfortable default, but probably will be in GNOME 3.22/F25 15:23:02 But when it comes to discussing particular apps, people do not like removing particular apps. :) 15:23:05 #info Music is in a similar situation 15:23:44 here's the activity of the elementary fork: http://bazaar.launchpad.net/~pantheon-photos/pantheon-photos/trunk/changes - basically, translation updates and a little bit of fixups 15:23:45 And from a Fedora perspective, we are not really clear on what a "core OS component" is. But from an upstream perspective, I think aday perhaps has some idea...? 15:23:55 mcatanzaro: Rhythmbox isn't in as dire a place as far as maintenance, correct? 15:24:18 stickster: No, Rhythmbox is maintained. It's not full of activity, but upstream is still committing things. 15:24:49 The only real problem with Rhythmbox is that it still depends on WebKit1. I am planning to do a build with --disable-webkit for F24, but I have not yet investigated what features will be lost. 15:24:50 we have a fairly clear idea of what a core app is from a design perspective 15:25:09 (That will also imply removing some Rhythmbox plugins, but I have not yet investigated which plugins will be lost.) 15:25:42 they have generic names, are tightly integrated with the OS, and have consistent designs 15:25:51 stickster: I can testify that for my use, just listening to local files, Music and Rhythmbox work about equally well, but Music looks way, way nicer. :) 15:25:57 #info Shotwell has an additional issue -- not maintained any longer (at least main fork). Meeting attendees seemed to agree it's worth taking on the risk of bugs/issues, rather than switching the default prematurely. 15:26:11 Actually Music works a bit better, because Rhythmbox sometimes hangs between songs due to some race. 15:26:34 ideally the initial install would be just those core apps, and then users would get to add 3rd party apps on top 15:27:18 mclasen: Yeah, Pantheon Photos is still on WebKit1 and still not validating TLS certificates. :( 15:27:30 aday: meaning... some or all of mcatanzaro's proposal upstream to clean up moduleset, and then have the Workstation echo the definition of core there? 15:27:37 I contacted Daniel F. about that though; I think he'll take care of it. Hopefully. 15:28:20 stickster: pretty much 15:29:31 Of course, we do have one prominent downstream that ships GNOME by default, starts with an "F", and it probably makes sense to consider the wishes of this downstream in determining which apps are core and which are not. :) 15:30:27 (Except regarding the web browser. ;) 15:30:44 but note that those upstream definitions are a kind of ideal scenario based on what we're trying to build - not necessarily a reflection of whether all apps are ready/sufficient in all cases 15:30:52 So let me make sure I capture our most immediate concerns before we get into the medium-range stuff 15:31:43 #idea After F24/F25 branching, switch default in Rawhide (pre-F25) to Music + Photos, with time to revert later if upstream (3.22) isn't judged ready; F24 defaults (Shotwell, RB) stay same as F23 for now 15:31:51 aday: Well I think we can choose whether to make them a reflection of an ideal scenario, or whether to make them a recommendation that downstreams can adopt now. For instance, we can keep Music and Photos in apps (where they are right now) until we think they're ready, and then move them to core only then, even though we both know we intend for them to be core apps. 15:32:18 mcatanzaro: true 15:32:40 Does including them in core upstream elevate their visibility, or increase the chances of people getting involved/interested in working on their feature sets? 15:32:49 mcatanzaro: i meant the designs rather than the modulesets tbh 15:32:58 stickster: +1 from me, though I think it more likely Music will be judged unready (it's not developing as quickly, although a large number of performance improvements landed this week) than Photos. 15:33:57 stickster: Currently, not really. The moduleset definitions don't mean anything. But we can work upstream to make that happen, and in fact that was what I was hoping to do... our developers are very spread out right now, and I think focusing on the most important core apps would be beneficial and perhaps also motivating for GNOME devs. 15:34:37 * linuxmodder stumbling in to listen in and learn 15:35:23 Currently we don't really have any clear direction as for where we want to go, or we do have the direction but it's only accessible to developers who are watching aday's GitHub full of mockups... we can do more to promote tasks that GNOME folks could work on, and maybe people would then take them up. 15:35:35 So I'm not sure what we're trying to recommend (or decide without deciding) :-) here at this point 15:35:58 (We do have direction, I'm trying to say it's just not widely-publicized. You kind of have to be in the cabal to know what needs done.) 15:36:06 We also have one other app change not mentioned yet which is removing empathy 15:36:25 stickster: I think that one is probably uncontroversial at this point. :( 15:37:15 mcatanzaro: Yeah, the only lingering question I had on empathy was just a clear idea of what integrations in GNOME Shell would disappear for someone used to the current default installation 15:37:48 stickster: What aday and I are recommending, concretely, is that once this upstream moduleset reorganization is done, we change Fedora rawhide comps to be in line with it, rather than debating in Workstation WG meetings which apps to install and not. Then, we can debate where to make exceptions (Shotwell, Rhythmbox) instead. 15:38:50 mcatanzaro: FWIW I looked over your upstream recommendations and didn't see anything unexpected/controversial 15:38:54 So e.g. if we say Weather is not a core app, it would be nice if I could go into comps and just remove it without waiting for a WG meeting, and we would only discuss the changes at meetings when we want to intentionally deviate from upstream (shotwell, rhythmbox, and that darn firefox thing ;) 15:39:45 The implication of this would be that when you install Fedora Workstation, you're not going to have many apps in Software that you can uninstall -- they'll be primarily under System Apps. 15:40:31 stickster: If you install Empathy or Polari, the gnome-shell integration (telepathy notifications you can chat into) will still work. It's just no apps will use it by default. 15:40:55 stickster: But, we would remove the ability to configure chat accounts in gnome-control-center, because no core app would use it anymore. 15:41:34 Currently you can configure your Empathy accounts in control-center, which kind of makes sense because it is a core app, but the accounts are only usable in Empathy (or Polari in the case of IRC). 15:42:13 So if we do this, you would need to configure your Empathy accounts in Empathy instead. 15:42:18 mcatanzaro: If I upgrade to the next release taht removes configuration, do those accounts simply disappear? Or do they stay but I can't get into them? 15:42:42 stickster: We can choose to do it either way, but I recommend making the accounts disappear, because otherwise there will be no way to turn them off.... 15:42:49 agreed 15:43:04 I already have a patch to implement this by the way, it's waiting on rishi ;) 15:43:51 Does anyone else have an opinion on what mcatanzaro suggests (re: aligning Workstation defaults with upstream core moduleset definition)? 15:44:21 * mclasen goes to reply to the upstream proposal 15:44:40 I suspect the upstream defaults will be primarily determined by mclasen aday and myself, to be realistic about it, so you can always reign us in if we go crazy. 15:45:35 in general, I think too much hand-wringing about what gets installed by default is misplaced - we've put a lot of work into gnome-software to make apps easily installable... 15:46:11 +1 mcatanzaro proposal 15:47:05 mclasen: So by switching to installing only gnome-core, we would have fewer apps installed, and you can use gnome-software to install the other ones you want, and we don't have to discuss it so much in Fedora anymore. ;) 15:47:12 mclasen: Agreed 15:47:48 mclasen: at the same time it's a good service to users to have a solid set of defaults in their Workstation install 15:48:23 esp. if in the future the whole group of core apps and the underlying libs are updated as a whole vs. piecemeal 15:50:48 #info Removing empathy seems to be the general consensus as well, nothing controversial. Note that mcatanzaro has a patch prepared that will remove configuration of accounts in g-c-c (making them disappear in that view to avoid confusion) 15:51:38 stickster: Anything else on the agenda? 15:51:56 (Thanks for attending aday!) 15:52:20 np mcatanzaro 15:52:23 #agreed (non-voting) General consensus with mcatanzaro's proposal to keep Workstation default apps aligned with core moduleset upstream, modulo specific changes (right now, Rhythmbox + Shotwell) 15:52:27 +1, thanks aday_ 15:52:37 #topic Missing dnf-langpacks 15:53:05 Is this just an errant missing change in the kickstart for the Workstation? 15:53:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=1286527 15:54:20 It looks like a mistake to me. Is there some reason we would not want the langpacks plugin installed? 15:54:35 Well, I wonder: does the langpacks plugin cause dnf to install more packages than PackageKit would? 15:54:54 (mclasen?) 15:55:04 sounds very plausible 15:55:22 but would need to check with hughsie to know for sure 15:55:40 mcatanzaro: mclasen: So I think I know *why* it's not there -- we subtract @standard in our kickstart which is where dnf-langpacks is located 15:55:51 dnf-langpacks seems to drag in Python 3 IIUC 15:56:07 I'm also not sure if we got langpack support added in g-i-s / g-c-c 15:56:28 isn't python 3 the good python these days ? 15:56:34 stickster: That's already our default python so np 15:56:40 mclasen: Yes, it is 15:58:44 I think it's a mistake and we should add dnf-langpacks to the workstation group in comps. If our GUI apps aren't smart enough to handle langpacks yet, that's no reason to hurt dnf. 15:58:44 mclasen: Perhaps your team could investigate our g-i-s, g-c-c language pack story as a separate issue? 15:58:48 So what's the next step here? I'm not suggesting just throwing it into the kickstart unless we know what that means :-) 15:58:53 *jinx 15:59:02 stickster: Let's not touch the kickstart, but the comps groups. 15:59:34 We can always defer to the next meeting, being what time it is and all. ;) 15:59:51 #info seems to be excluded due to "-@standard" declaraction in fedora-live-base.ks 15:59:55 *nod 15:59:55 kickstart is for making changes needed for live media. If we change it there then the netinstall doesn't pick up the changes. 16:00:09 #idea mcatanzaro suggests just adding to workstation comps to compensate 16:00:18 Makes sense to me. 16:00:29 We exclude standard simply because a lot of non-desktop stuff like sendmail and syslog gets put in there, and we want to not have to deal with arguments over what goes in standard. 16:00:31 We can circle back on list, I'll reply to Parag's email 16:00:38 *nod 16:00:55 silly question: why the -@standard ? 16:01:04 rdieter: "We exclude standard simply because a lot of non-desktop stuff like sendmail and syslog gets put in there, and we want to not have to deal with arguments over what goes in standard." :) 16:01:08 #action stickster reply on list to Parag to see if we can get fixed 16:01:15 OK, sorry for running over guys -- thanks for being here! 16:01:18 ok 16:01:21 and Happy New Year, everyone :-) 16:01:26 #endmeeting