13:05:34 <stickster> #startmeeting Workstation WG
13:05:34 <zodbot> Meeting started Mon Mar 12 13:05:34 2018 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:05:34 <zodbot> The meeting name has been set to 'workstation_wg'
13:05:37 <stickster> #meetingname workstation
13:05:37 <zodbot> The meeting name has been set to 'workstation'
13:05:41 <stickster> #topic Roll call
13:05:43 <rdieter> yep
13:05:44 <stickster> .hello pfrields
13:05:45 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
13:05:55 <rdieter> .hello rdieter
13:05:56 <stickster> #chair rdieter juhp mcatanzaro otaylor mclasen
13:05:56 <zodbot> Current chairs: juhp mcatanzaro mclasen otaylor rdieter stickster
13:05:56 <zodbot> rdieter: rdieter 'Rex Dieter' <rdieter@gmail.com>
13:05:59 <otaylor> .hello otaylor
13:06:01 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
13:06:04 * stickster hands over gavel :-)
13:06:13 <juhp> .hello petersen
13:06:14 <zodbot> juhp: petersen 'Jens Petersen' <petersen@redhat.com>
13:06:15 <mcatanzaro> .hello catanzaro
13:06:17 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org>
13:06:30 <stickster> ryanlerch is on vacation still
13:10:22 <rdieter> ok, that looks like everyone
13:10:27 <rdieter> #topic agenda
13:11:12 <mclasen_> .hello mclasen
13:11:13 <zodbot> mclasen_: mclasen 'Matthias Clasen' <mclasen@redhat.com>
13:11:15 <rdieter> I see 3 items in pagure at the moment: simplescan/todo, rhythmbox, initial setup
13:11:32 <rdieter> anything else besides ^^ ?
13:12:44 <rdieter> is there a magic .ticket command iirc ?
13:12:53 <mcatanzaro> aday was planning to attend to discuss the default apps issues, but he is not present ATM. Perhaps we could defer rhythmbox/music until he is around?
13:13:36 <rdieter> sure, though can't put off decision-making too long, if intent is to make f28 (beta)
13:13:37 <otaylor> sgallagh suggested that we discuss whether we wanted to include the modularity  repo for workstation ... I was going to file a ticket about that, but forgot...
13:14:21 <sgallagh> Yeah, we need to know that for Beta
13:14:31 <sgallagh> It has implications on the packaging of the repo files too
13:14:53 <mcatanzaro> rdieter: Music can wait until f29. simplescan/todo we need to discuss now because of the weird branching issue we had around f28 branch time, the default install changes if we do nothing.
13:14:53 <rdieter> ok, let's get started then
13:15:25 <rdieter> #topic simplescan/todo, https://pagure.io/fedora-workstation/issue/34
13:15:32 <rdieter> mcatanzaro: go ahead
13:16:21 <rdieter> https://pagure.io/fedora-workstation/issue/34#comment-496136  is the background behind discussing it again
13:16:50 <mcatanzaro> So when we discussed this last week, I presented the topic as if Simple Scan and Todo were not already installed by default, and we should start doing so. But at the very end of the meeting, I discovered we had approved both these apps six months earlier, and actually gone ahead and added them to f27 comps. kalev created a PR for that immediately b
13:16:50 <mcatanzaro> efore f28 was branched, and it was merged immediately after, so the apps got dropped from F28.
13:17:07 <mcatanzaro> But the WG's opinion on the apps has also changed in that time.
13:17:15 <mcatanzaro> Last week, we voted to not add either of the apps.
13:17:48 <mcatanzaro> So we're really discussing here whether to re-add (retain) the apps from the default install, or to remove them (by doing nothing).
13:18:37 <kalev> .hello kalev
13:18:38 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
13:18:43 <mcatanzaro> After our discussion at the last meeting, and with aday, I want to try again and propose re-adding simple-scan, but not gnome-todo. Makes sense to hold this vote again IMO because when we considered it last week we thought it was not already present in the default install.
13:18:44 <kalev> sorry, thought this would be an hour later
13:19:08 <mcatanzaro> kalev: DST exists to confuse and disorient. It is always successful!
13:19:16 <kalev> indeed :)
13:19:17 <juhp> lol
13:19:19 <otaylor> mcatanzaro: "and with aday" - did you discuss this with aday?
13:20:01 <mcatanzaro> otaylor: I discussed the changes with respect to upstream with aday, and invited him to this meeting. I didn't discuss his opinions with respect to Fedora. He's not here currently -- maybe confused by DST -- and I don't claim to speak for him.
13:20:26 <kalev> can we ask him to join now?
13:20:38 <mcatanzaro> kalev: I already did; he is afk.
13:20:45 <juhp> Any thoughts on upstream?
13:21:31 <mcatanzaro> juhp: We removed gnome-todo from the core apps list, but retained simple-scan. So my proposal is to do the same in Fedora.
13:21:40 <juhp> I see
13:22:11 <mcatanzaro> The net change from F27 would be to remove one app from the default install. (Actually two: we already approved and landed the removal of setroubleshoot.)
13:22:34 <otaylor> I can definitely go along with that, though it might be just personal prejudice against todo list apps (yet another place I can lose todo items! Just what I'm lookin gfor ;-)
13:22:35 <mcatanzaro> But the change I would apply would be to add simple-scan to the F28 comps (it's currently present in F27 only).
13:22:51 * mclasen_ is very tired of default app discussions
13:23:37 <otaylor> It would be still, I think useful to invite aday at some point for a default app discussion, but why don't we just vote on the proposal to keep simplescan and remove todo
13:24:00 * rdieter agrees
13:24:08 <mcatanzaro> Agreed
13:25:03 <rdieter> proposal: keep simplescan and remove todo from workstation default install
13:25:06 <mcatanzaro> I'm going to remove the meeting keyword from the rhythmbox/music issue, I'll coordinate with aday to make sure he shows up before proposing that one again.
13:25:20 <mcatanzaro> My vote is +1 (obviously)
13:25:24 <rdieter> +1
13:25:24 <otaylor> +1
13:25:48 <juhp> +1
13:25:55 <kalev> +1
13:26:11 * mclasen_ has no opinion on this
13:26:41 * juhp could also be swayed :)
13:27:37 <rdieter> I think that's enough for it to be accepted, so vote if you want your opinion recorded for posterity
13:28:29 <rdieter> #agreed proposal passes (+5,0,-0)
13:28:43 <rdieter> mcatanzaro: you ok with implementing the change?
13:29:00 <mcatanzaro> mclasen_: FWIW: I think it's important to revisit default apps every once in a while, since this is the user's first impression after installing Workstation. IMO there's a big quality difference between us and distros that are less-selective with default apps.
13:29:06 <mcatanzaro> rdieter: I will implement. Thanks!
13:29:55 <stickster> ugh sorry, missed the vote but I'm +1 on mcatanzaro's idea (simple-scan yes, todo no)
13:29:59 <rdieter> #action mcatanzaro to implement proposal
13:30:14 <rdieter> #agreed proposal passes (+6,0,-0)
13:30:20 <stickster> lol, thanks rdieter
13:30:34 <rdieter> moving on...
13:30:48 <rdieter> #topic Reduce initial setup redundancy  https://pagure.io/fedora-workstation/issue/21
13:30:57 * mclasen_ points out in passing that those default apps end up in the os image on the atomic workstation, making them effectively unremovable there
13:31:11 <juhp> hmm
13:31:13 * rdieter reads to see what is left on that ticket
13:32:30 * rdieter is unsure
13:32:37 * mclasen_ tired of that discussion as well :-(
13:32:51 <juhp> mclasen_: right in that sense less default apps make sense
13:33:38 <mcatanzaro> Input methods are left. After my changes, there's no way to configure input methods. juhp, is there anything you want to discuss about that, did you make any progress towards a solution...?
13:34:05 <juhp> Not so much, I can mention that epico (pwu) has been working on a patch
13:34:57 <juhp> First draft was posted upstream (in bugzilla I think) - but I think it needs a little more work
13:35:12 <juhp> Probably should be in gitlab?
13:35:36 <juhp> So we didn't mention it yet in the ticket
13:37:15 <mcatanzaro> juhp: Can you post a link to the patch, please?
13:37:22 <juhp> (I meant not so much to mention)
13:37:29 <juhp> I can....
13:37:30 <mcatanzaro> gnome-initial-setup has not switched to GitLab, so Bugzilla is the right place.
13:37:37 <juhp> okay cool
13:37:50 <juhp> (Though it seems a bit confusing:)
13:38:14 <juhp> https://bugzilla.gnome.org/show_bug.cgi?id=794166
13:38:40 <juhp> I heard today that it doesn't work yet... so wasn't going to mention...
13:40:21 <juhp> The latest patch might work, I don't know
13:40:42 <juhp> I think I talked to pwu before that
13:43:02 <rdieter> so, sounds like there isn't anything actionable in the short-term?
13:43:13 <otaylor> juhp: do you think this is a workable approach and we can get it into place for F28?
13:43:17 <juhp> Well hoping to get that upstream
13:43:22 <juhp> I think so
13:44:05 <juhp> Only concern might be upstream timing - or maybe we could ship it as a fedora patch?
13:44:14 <otaylor> juhp: OK, sounds to me we can just leave the action on you to drive that forward and report back if there are issues
13:44:21 <juhp> Sure
13:44:27 * mclasen_ comments in the bug
13:44:41 * stickster wonders if we can be a little more explicit about what is to-do here
13:44:42 <juhp> mclasen_: thanks
13:44:46 <otaylor> juhp: if there is consensus upstream that the approach is OK, there shouldn't be a problem with carrying a patch
13:44:54 <juhp> otaylor: okay good
13:45:13 <juhp> Right I agree not then...
13:45:15 <mcatanzaro> Note that my changes are all still downstream
13:45:24 <juhp> * I agree if not then...
13:45:35 <juhp> aha
13:45:49 <mcatanzaro> aday wants time to come up with an alternative design.
13:45:51 <juhp> Anyway I feel these changes make sense upstream anyway
13:46:13 <juhp> mcatanzaro: for the front page?
13:47:32 <juhp> ah completely change it?
13:48:26 <rdieter> Per stickster's comment: seems consensus is to watch upstream bug #794166, and pull any accepted change(s) into f28?
13:48:27 <mclasen_> more on this, or move on ?
13:48:58 <stickster> will we need a freeze exception for that? I guess it depends on timing.
13:49:18 <juhp> stickster: okay right
13:49:31 <rdieter> if it happens fast and in time for f28 beta, then FE is required, yes
13:50:15 <juhp> It should really get into GA otherwise - otherwise it will need a respin Live image
13:50:25 <juhp> respun
13:51:07 <rdieter> I think we can move on then (holler if anyone wants to continue)
13:51:41 <juhp> +1
13:52:16 <rdieter> #topic modularity repo
13:52:51 <rdieter> otaylor and sgallagh mentioned this one ^^, can either of you elaborate?
13:52:54 * otaylor will introduce it and then sgallagh can correct anything he got wrong
13:53:33 <otaylor> The basic question is whether we should have an entry in /etc/yum.repos.d for the "modular" repo, which has the rpms and metadata for all the modules that are "official" for f28
13:54:12 <otaylor> the set is small at the moment, but is expected to rapidly evolve. The modules would be disabled by default but could be enabled at the dnf command line
13:55:17 <juhp> Any downside to including?
13:55:20 <sgallagh> otaylor: Not all modules would necessarily be disabled by default; there will be packages made available in the modular repo that are not available in the standard repo (because they have dependencies on older or newer content). Those packages' modules will be available by default
13:55:26 <otaylor> My take: Pro: people could try out modularity on the workstation install. Con: modules can break your system by upgrading/downgrading packages Con: We're trying to discourage people viewing their workstation as a development experimentation box - we want people to do that in containers (re Fedora Atomic Workstation)
13:56:00 <otaylor> sgallagh: what happens when you install one of those packages - does it upgrade/downgrade the requirements?
13:56:17 <sgallagh> otaylor: if they are already installed and incompatible, it will refuse to let you install it.
13:56:35 <sgallagh> If not, it will enable the requisite dependent modules implicitly
13:56:45 <kalev> sgallagh: does packagekit handle modular repos correctly?
13:57:11 <otaylor> sgallagh: Mmm, so you could get yoruself into a state where you couldn't install applications through gnome software because of modules that were previously enbaled?
13:57:56 <sgallagh> otaylor, kalev: I'm not actually certain about the packagekit situation. Up until this morning, I thought this was being handled in libdnf, but I was told otherwise about 30 minutes ago, so now I'm uncertain
13:58:00 <sgallagh> (And kind of angry...)
13:58:46 <sgallagh> otaylor: Enabling modules may indeed cut off certain parts of the repo "tree".
13:58:56 <sgallagh> That's a conscious decision one has to make.
13:59:16 <sgallagh> In DNF at least, they are prompted when installing a package will result in a module being enabled
13:59:27 <sgallagh> So it must be a conscious decision
13:59:38 <kalev> I think I'd like to test packagekit a bit before enabling this by default on workstation to make sure we don't regress other things
13:59:54 <otaylor> But should we expect the "average user" to understand the implications of that? Do we provide good error messages (through gnome-software) if things go wrong afterwards?
14:00:37 <mcatanzaro> otaylor: Good error messages? Nice one!
14:00:55 * mcatanzaro also very skeptical
14:01:01 <otaylor> sgallagh: How important to modularity effort is it to have users be able to try out modules directly on workstation?
14:02:02 <kalev> somewhat related, I fixed a long standing packagekit bug last week where packagekitd would crash for malformed .repo files
14:02:08 <sgallagh> otaylor: That's a very subjective question. Most of our planned modules have been fairly server/container focused
14:02:18 <otaylor> sgallagh: if it's considered very important, I think the reasonable thing might be to have the repo file there but disabled by default, (like updates-testing) - I don't think we have the pieces in place yet to just enable it by default.
14:02:19 <kalev> now it instead of crashing reports things properly to gnome-software that shows an error message
14:02:29 <juhp> Anyone can just install the repo package if they want to try it, right?
14:02:31 <sgallagh> In the sense that it's more generally that deployment case that most cares about running older or newer content
14:03:06 <juhp> otaylor: +1
14:03:09 <sgallagh> Well, the "catch" is that Server Edition must have it present and enabled by default.
14:03:32 <otaylor> And it's not really in our future plans for workstation which are Flatpaks for gui applications, containers for development and server testing
14:04:39 <otaylor> sgallagh: how is that a catch?
14:05:10 <sgallagh> It just makes the packaging side of it trickier.
14:05:30 <sgallagh> i.e. It's a lot easier to have you NOT install the repo file than to have you install it but leave it disabled.
14:05:43 <otaylor> sgallagh: is the repo file in a separate package?
14:05:57 <sgallagh> otaylor: It is going to be, but isn't today.
14:06:18 <sgallagh> (By "going to be", I mean it must be fixed before Beta)
14:06:32 <sgallagh> Because we *know* that KDE isn't equipped to handle it.
14:06:39 <sgallagh> So they have to have a way to exclude it for now
14:07:21 <kalev> how is KDE not equipped to handle it?
14:07:55 <sgallagh> They discovered this morning that dnfdragora just breaks when that repo is enabled.
14:08:02 <kalev> ah
14:08:09 <sgallagh> I assume because it doesn't know about the extra metadata and simply treats it as a standard repo
14:08:45 <kalev> I'd like to keep it completely out of the workstation default install until we've verified that it doesn't break packagekit/gnome-software
14:08:47 <sgallagh> Which may also be true of PackageKit, since as I mentioned it seems that they didn't do the implementation in libdnf as we intended
14:08:49 <kalev> (or fixed)
14:08:52 * sgallagh nods
14:08:56 <mcatanzaro> We're almost 10 minutes over
14:09:20 <rdieter> I think we can agree that this can't happen until there's testing/assurance that PK can handle it reasonably
14:09:29 <otaylor> sgallagh: I think asking users to cut and paste content into yum.repos.d is a bit error prone, but if it's just 'dnf install fedora-modular-repos' that sounds like a reaosnbale thing to have on an instructions page
14:09:46 <sgallagh> otaylor: That's what I was proposing, yes
14:10:40 <rdieter> discussion needs more time, beyond our meeting here.  Please take things to mailing list, etc... and/or continue in #fedora-workstation
14:11:02 <rdieter> sorry for letting things go too long, and thanks everyone
14:11:10 <rdieter> #endmeeting