14:01:02 <mclasen> #startmeeting Workstation WG
14:01:02 <zodbot> Meeting started Mon Dec 17 14:01:02 2018 UTC.
14:01:02 <zodbot> This meeting is logged and archived in a public location.
14:01:02 <zodbot> The chair is mclasen. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:02 <zodbot> The meeting name has been set to 'workstation_wg'
14:01:11 <mclasen> #meetingname workstation
14:01:11 <zodbot> The meeting name has been set to 'workstation'
14:01:17 <mclasen> #topic Roll call
14:01:39 <mclasen> .hello mclasen
14:01:39 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com>
14:02:23 <cschalle> .hello cschalle
14:02:24 <zodbot> cschalle: Sorry, but you don't exist
14:02:25 <ryanlerch> .hello ryanlerch
14:02:27 <zodbot> ryanlerch: ryanlerch 'Ryan Lerch' <rlerch@redhat.com>
14:03:27 * mclasen looks for an agenda
14:03:57 <kalev> .hello kalev
14:03:58 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
14:04:15 <juhp> hi
14:04:23 <mclasen> I see 3 items tagged for meeting
14:04:27 <mcatanzaro> .hello catanzaro
14:04:28 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org>
14:06:16 <mclasen> anything else to add to the agenda ? owen is not here, otherwise I might ask him about the luks investigation
14:06:43 * mclasen waits another minute for agenda submissions
14:08:15 <mclasen> ok then
14:08:35 <mclasen> first, we have a suggestion by mcatanzaro
14:08:46 <mclasen> topic: issue 67 - drop evolution from the default install
14:09:00 <juhp> ah yes
14:09:43 <mclasen> quite a bit of discussion in the issue, from a few months ago
14:10:41 <mclasen> mcatanzaro: do you want to make the case fo r this ?
14:11:10 <aday> there's probably 3 aspects to this: 1. app quality, 2. appropriateness for the default install, 3. integration with the other default apps
14:11:22 <otaylor> here now - sorry to be late
14:12:17 <mclasen> aday: with integration, you mean eds ?
14:12:28 <aday> mclasen, more like overlap with calendar and contacts
14:12:39 <aday> how it fits with the set as a whole
14:12:45 <mclasen> ok
14:13:25 <mclasen> some other questions come to mind: 1. do we need an email client in the default install ? 2. what are the alternatives ?
14:14:41 <mclasen> any opinions on this ?
14:14:47 <aday> i would argue that an email client is a nice to have, rather than a must have. most people use web mail nowadays
14:14:55 <kalev> I would say no to question 1
14:15:17 <mclasen> I think I was one of the last people to cling to evolution for company email, and I've moved on since gmail...
14:15:19 <ryanlerch> yeah, i agree, dont really think we need an email client by default
14:15:41 <mcatanzaro> My answers are: 1. no we don't need one, but nice to have if a nice one is available. 2. only plausible alternative is geary, it's (much) better than evolution but has some quality issues that would make me hesitate. 3. evolution duplicates functionality from other default apps.
14:16:04 <mcatanzaro> My suggestion is to do what the issue says, drop evolution without replacement
14:16:05 <aday> what happens when you click on a mailto link when there's no email client installed?
14:16:09 <mcatanzaro> But I have one hesitation:
14:16:19 <kalev> if we ship anything, I think it should be Evolution since it's developed in house and we can quickly get bugfixes done if needed
14:16:26 <otaylor> aday: what *should* happen if you are using webmail?
14:16:27 <mcatanzaro> aday: Good question, I guess the link won't do anything?
14:16:29 <kalev> but otherwise I'd say that we don't really need a default mail client installed
14:16:57 <otaylor> aday: having geary/evolution/whatever open and ask to be confiugred isn't useful
14:17:15 <mclasen> for flatpaks, we should probably make the protal handle the 'no email client' case intelligently
14:17:26 <aday> otaylor, true
14:17:45 <mcatanzaro> My one hesitation to dropping evolution is that Milan has repeatedly expressed willingness to do a redesign in line with what GNOME designers want to do, but hasn't gotten design team support to do so. No plausible mockups or anything afaik. There is discussion about this in the pagure issue. So I feel like we've kind of set Evolution up for failur
14:17:45 <mcatanzaro> e here.
14:18:34 <aday> if evolution was super nice would we keep it and drop contacts and calendar?
14:18:57 <mclasen> I think evolution is just too big for one person to stem a redesign. saying it is 'developed in house' is a bit of a euphemism for 'one person keeps the lights on'
14:19:58 <juhp> Any kind of usages stats?
14:20:13 * juhp admits to never having used it for any extended time
14:20:44 <ryanlerch> just uninstalled evoloution, and it seems the mailto links in firefox just do nothing
14:20:46 <otaylor> mclasen: agreed... it needs a team/commnuity and it's implementation language isn't going to get a community these days
14:21:13 <mclasen> ryanlerch: flatpak or rpm ?
14:21:21 * mcatanzaro doesn't think every default app needs a big team behind it
14:22:21 <ryanlerch> mclasen: rpm
14:22:39 <mclasen> would be interesting to repeat that experiment with flatpak
14:22:41 <otaylor> mcatanzaro: of course not ... but evolution was created by a team, and is still a big sprawling code base that has only *mostly* had the weirdness squeezed out of it over time
14:22:43 <mclasen> I'll put that on my list
14:23:20 <mcatanzaro> aday: In https://pagure.io/fedora-workstation/issue/67#comment-527808 I suggest Evolution should provide a "lite mode" where contacts calendar etc. are hidden and only email is presented... that way it doesn't duplicate functionality from our other default apps.
14:24:05 <mclasen> should we just vote on 'drop evolution from the default install without replacement' ?
14:24:28 <kalev> yes, let's
14:24:32 <mclasen> ok
14:24:35 <mcatanzaro> Yeah, I think the only sane options are (a) keep it or (b) drop without replacement. Note upstream GNOME has chosen (b) and I've wanted to follow that for a long time. Really only disappointed Milan hasn't gotten more design help.
14:24:36 <mcatanzaro> +1 drop
14:24:44 <otaylor> mclasen: Have we explored what happens with EDS/ contacts/etc in this discussion?
14:24:53 <otaylor> mclasen: But yes, let's go ahead and vote
14:25:11 <mclasen> I think eds will be pulled in by dependencies ?
14:25:18 <mclasen> +1 from me too
14:25:21 <mcatanzaro> Those all should stay because they are part of upstream core, unlike evolution itself.
14:25:21 <kalev> yep, calendar and other stuff pulls it in
14:25:36 <otaylor> mclasen: I meant, more  in terms of experience - does EDS work OK in goa-only mode
14:25:40 <mcatanzaro> (e-d-s is still core, evolution the app is not)
14:25:41 <ryanlerch> +1 drop
14:25:50 <kalev> +1 from me too
14:25:51 <otaylor> +1 drop
14:25:55 <juhp> +1
14:26:05 <mcatanzaro> otaylor: It works to the extent you use Calendar and Contacts to configure your calendar and contacts
14:26:09 <ryanlerch> note too that typing "email" in overview search pops up evolution as the top hit
14:26:16 <cschalle> +1
14:26:23 <ryanlerch> same in gnome-software itself
14:26:27 <mclasen> thats a decision
14:26:43 <mclasen> #agreed drop evolution from the default install, without a replacement
14:27:56 <mclasen> #topic issue 56: consider turning on zram
14:31:33 <mclasen> I have no strong opinion on this. but I believe endless are using it and it makes a difference on their low-memory systems
14:32:27 <otaylor> Do we understand how this would interact with swap - is swap still enabled by default, and comes into play once the zram space is full?
14:33:46 <otaylor> And what's the upgrade path here? We're not going to get significant testing in advance of f30 if we just enable it for new installs
14:34:18 <otaylor> I think we're missing the technical expertise here
14:34:20 <juhp> Is the suggestion to enable zram only for Live?
14:34:20 <mclasen> given that it was enabled on netinstalls for a few releases, it should have had some testing ?
14:35:07 <kalev> juhp: yes, I believe so
14:35:10 <mclasen> is there a rationale for that ? wouldn't it just depend on your available memory whether its needed or not ?
14:35:20 <juhp> If it works well for netinstall.iso then probably a good idea for Live too
14:35:25 <mclasen> or for that matter, is there a downside to just turning it on always ?
14:35:40 <juhp> mclasen: yeah i was wondering that too
14:35:42 <otaylor> I'm not convinced about this netinstall thing - maybe it's just confusion about the memory threshold in anaconda?
14:36:11 <juhp> It should be easy to check?
14:36:21 <kalev> mclasen: I don't know, but it's the live media that needs it most: since we're using RAM as backing storage for anything written to disk overlay, it's easy to run out of RAM on live media
14:36:38 <otaylor> And how would we know if it's making things better or worse? It's almost *certainly* going to make things for low-memory systems with spinning disks
14:36:55 <mclasen> make things ... ?
14:37:09 <mclasen> better or worse ?
14:37:43 <juhp> kalev: yes very
14:37:51 <mclasen> I don't think deviating from the default for live situations is worth it
14:38:00 <otaylor> better sorry - I'm a little worried that we enable it, and then we find out a few releases later that we're showing up 10% slower in compilation benchmarks or something ... not saying that we shouldn't do it, just a bit concerned that it's a major system thing with very little exposure to the user
14:38:32 <mclasen> if zram is not good for default installs, then I don't think its worth enabling it on live systems to make them stumble along a little better
14:38:32 <kalev> otaylor: the suggestion in the ticket is to only enable it for the installer live media, so it shouldn't affect benchmarks for real systems
14:39:08 <juhp> right
14:39:10 <otaylor> kalev: I'm interpreting the ticket being about installatoins *from* the installer live media
14:39:14 <kalev> but that's the area where we are already deviating for real installs: real installs write changed files to disk, live media writes changed files to RAM
14:39:26 <kalev> if there's anything where we should deviate it's exactly this area
14:40:11 <kalev> otaylor: my understanding is that it's just asking for us to turn it on just for the live media session, to match the netinstall media
14:40:22 <kalev> and not change it for final installs
14:41:22 <juhp> It could have been stated clearer certainly :)
14:41:51 <mclasen> i don't think that is very convincing
14:42:26 <otaylor> kalev: OK, yeah, looking at the anaconda code referenced, it does seem to be about during installation time
14:42:42 <mclasen> either we turn it on in low-memory situations (and live media might be an example of that) or we don't
14:43:31 <otaylor> It sounds like a fine change to me... really just somtehing that needs to be a PR for the right component - I agree that the live media is significnatly different in this area than an installed system
14:44:23 * kalev nods.
14:44:40 <otaylor> mclasen: Though i do agree that it would be nice if someone is exploring this area to consider whether we want it on in some cases for installed systems
14:44:41 <mclasen> so you don't think zram for the installed system is interesting ? or the risk / reward is different ?
14:45:12 <mcatanzaro> mclasen: Now define "low-memory situations" ;)
14:45:30 <otaylor> mclasen: well, the fact that there is swap, and there is *sometimes* swap on a fast device makes it different
14:45:58 <mclasen> whenever my system hits swap, I need to reboot
14:46:09 <juhp> yeah it sucks
14:46:19 <mclasen> the kernel is so bad at it, we might just as well not have it
14:46:34 <otaylor> mclasen: I don't think that's quite true - I think it's when your system is oom'ing due to out of control processes, then the swap is useless
14:46:38 <juhp> otaylor: and storage too :-)
14:46:54 <mclasen> maybe so
14:48:08 <otaylor> Basically for me, turning zramfs on for live media seems like an obvious change, turning it on for installed systems - I'd like a bit of testing, for us to talk to someone who knows about the area, and we'd have to consider the upgrade path so we don't have a disjunction between new installs and what most experienced Fedora people are using
14:48:19 <mclasen> alright, before we descend into kernel bashing, should we vote on that ^
14:48:39 <kalev> yes, I agree, let's fix the obvious thing and not get stuck on whether it makes sense for a general use
14:48:41 <mclasen> suggestion: turn zram on for live media
14:48:50 <mcatanzaro> +1
14:48:52 <kalev> +1
14:48:52 <otaylor> +1
14:48:54 <juhp> +1
14:49:01 <ryanlerch> +1
14:49:08 <kalev> my guess is that zram has a performance/RAM use tradeoff since something has to compress and decompress the written bytes
14:49:20 <kalev> for the installer, it makes sense to do the tradeoff for RAM use
14:49:28 <kalev> but for the final system I think performance may make more sense
14:49:45 <kalev> but that's all just speculation :)
14:49:45 <mclasen> I give this a 0, given what I said earlier
14:50:03 <mclasen> but we have 5 +1's anyway, which is sufficient
14:50:18 <mclasen> #agreed: enable zram on live media
14:50:44 <mclasen> how about the practicalities of this  ? presets are defined in some release package ?
14:50:56 <mclasen> how are they overwritten for live installs ?
14:52:15 <otaylor> mclasen: Maybe simply ask if  Chris Murphy wants to come up with a PR in the issue?
14:52:18 <kalev> there's a shell script that runs on live installs that does all kinds of hacks
14:52:29 <kalev> err, that runs on live installer startup
14:52:41 <mclasen> I think it has a comment in it that says # FIXME do this properly
14:52:46 <kalev> yeah, that's the one
14:52:51 <mclasen> from way back when ray and I first wrote it :)
14:53:13 <otaylor> I'm sure there's some systemd magic that would do it cleanly
14:53:20 <mclasen> yeah
14:54:10 <mclasen> ok, we have 5 minutes left, not worth opening the last issue
14:54:17 <mclasen> anything for open floor ?
14:54:30 <mclasen> otaylor: any update on the luks research ?
14:55:06 <otaylor> mclasen: No, I'll probably not really get into that until the new year.
14:55:48 <mclasen> or on some of the other research you've been doing, like ides ? but probably not a 5 minute topic either
14:56:32 <otaylor> Well, I'm having some luck prototyping out the idea that fedora-toolbox exports a fuse filesystem which magically turns executables into shell scripts to execute the same thing in the toolbox
14:56:46 <juhp> otaylor: ohh
14:57:02 <mclasen> I had flashbacks of ia64 emulation when reading that...
14:57:22 <otaylor> That's gotten vscode to mostly work for python, C/C++, golang
14:57:47 <juhp> Cool
14:58:36 <otaylor> mclasen: It's sort of horrible, but a lot better than having IDE's in flatpak be entirely divorced the Fedora development environment
14:59:05 <mclasen> yeah, clearly
14:59:57 <otaylor> I intend to pursue this as a fedora-toolbox feature - with a generic spec on top of it to make it something we can argue for support in IDE's - since it's not actually flatpak/podman/fedora specific as an idea
15:00:54 <otaylor> But still early stages - don't yet fully whether it can be productionized into something that will be cool for users, or it's going to end up with wonky bits hanging out. Need to tests some other other ide's too
15:02:11 <mclasen> ok, thanks for the encouraging update
15:02:13 <mclasen> out of time now
15:02:18 <mclasen> #endmeeting