15:00:01 <stickster> #startmeeting Workstation WG (Special Edition)
15:00:01 <zodbot> Meeting started Wed Mar  9 15:00:01 2016 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:01 <zodbot> The meeting name has been set to 'workstation_wg_(special_edition)'
15:00:05 <stickster> #meetingname workstation
15:00:05 <zodbot> The meeting name has been set to 'workstation'
15:00:08 <stickster> #topic Roll call
15:00:41 <rdieter> .hello rdieter
15:00:42 <zodbot> rdieter: rdieter 'Rex Dieter' <rdieter@math.unl.edu>
15:00:45 <rdieter> hola
15:00:47 <stickster> mcatanzaro: otaylor: juhp: ping :-)
15:00:48 <mcatanzaro> Present
15:00:51 <otaylor> Here
15:00:57 <stickster> Hi Rex, Michael, Owen! :-)  o/
15:01:17 <stickster> mclasen sent regrets, but cschaller planned to be here last I spoke with him
15:01:53 <stickster> kalev: and a ping for you, too
15:02:11 <stickster> #chair rdieter mcatanzaro otaylor
15:02:11 <zodbot> Current chairs: mcatanzaro otaylor rdieter stickster
15:02:30 <kalev> hello!
15:02:44 <stickster> #chair kalev
15:02:44 <zodbot> Current chairs: kalev mcatanzaro otaylor rdieter stickster
15:02:46 <stickster> Hi Kalev :-)
15:03:04 <stickster> Great, that means we have quorum, so without further ado....
15:03:20 <linuxmodder> .hello corey84
15:03:21 <zodbot> linuxmodder: corey84 'Corey Sheldon' <sheldon.corey@gmail.com>
15:03:25 <stickster> #topic Wayland (LIMIT: 15 MINUTES)
15:04:34 <kalev> I think mclasen got convinced as well that it's best to wait for one more cycle
15:04:46 <mcatanzaro> Yeah, mclasen blogged that we're going to keep X as the default, no way we can proceed with Wayland now ;)
15:04:49 <mcatanzaro> Next topic!
15:04:57 <stickster> kalev: That's how I understood him yesterday as well. I think this is a pretty easy decision.
15:04:59 <kalev> he also posted a nice blog post why and how we are doing wayland and why we are keeping the default session as the X session for this cycle
15:05:11 <mcatanzaro> #link https://blogs.gnome.org/mclasen/
15:05:26 <stickster> But... I'd also propose that, because work is continuing through F24 Beta, this might be the release of "Wayland is working well enough for one release that the next release should be default."
15:05:36 <kalev> halfline changed the default back as well, just in time for F24 freeze
15:05:41 <stickster> We don't need to decide that today, but I think it will be hard to justify NOT doing it for F25
15:05:52 * kalev agrees.
15:05:54 <stickster> mattdm: ^ FYI
15:06:31 <mcatanzaro> stickster: +1 to "Wayland is working well enough at this point that the next release should be the default"
15:06:49 <stickster> So I guess there's no need for bureaucracy of voting, I'll just #agreed that F24 is Wayland-not-default, and we can move on
15:06:56 <kalev> yup
15:07:12 <mcatanzaro> Let's vote on whether to move on without voting. +1
15:07:16 <stickster> hahaha
15:07:58 <stickster> #agreed Wayland is not default for F24; freeze exception not needed, thank you halfline for change JIT
15:08:04 <stickster> Shall we move on?
15:08:15 <mcatanzaro> Yes....
15:08:29 * kalev nods.
15:09:20 <stickster> #topic Third party software proposal
15:09:40 <stickster> #link https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal
15:10:47 <stickster> #info cschaller provided this draft with notes from other WG members, but it's not complete yet
15:10:56 <stickster> This is basically a dump of a collaborative document. There are some notes still interspersed that need handling. And more editorial love is needed, but I ran out of time to finish that.
15:11:09 <mcatanzaro> I like the proposal overall; I think we should work on messaging around it.
15:11:37 <stickster> mcatanzaro: Agreed, but we should get the proposal into better shape before we start heralding trumpets
15:11:43 <mcatanzaro> There have been many complaints recently that "distros are obsolete" (not a reasonable complaint) or "distros getting in the way" between users and upstream (reasonable complaint)
15:12:22 <stickster> mcatanzaro: agreed on latter, but I think "distros are obsolete" is not quite the message that e.g. mattdm means -- "distros are not what people care about the most" perhaps closer.
15:12:33 <mcatanzaro> So our messaging should focus on that, we're giving power to upstream to get software into Fedora the way they want, and if they use xdg-app it'll all be cross-platform.
15:12:55 <mcatanzaro> We're "getting out of the way" while other distros are still "in the way" -- that's what's special about this plan.
15:13:18 <stickster> +1 -- also there is an unspoken problem of all distros, Fedora among them, which is that packaging is kind of a placebo
15:14:12 <mcatanzaro> There is one more unrelated point: I fear allowing xdg-apps with filesystem access will totally defeat any value of xdg-app sandboxing. Nobody is ever going to write sandboxed apps if we allow that.
15:14:20 <jwb> stickster: elaborate?
15:14:32 <stickster> We know that often when someone wants to bring an interesting application/solution into Fedora, it can mean packaging a ton of other things, which basically signs contributors up for a huge amount of work they didn't bargain on
15:15:08 <mcatanzaro> But we don't have portals ready yet, so maybe it's too soon to release this proposal, and that needs to be in place or we cannot reasonably suggest upstreams to use xdg-app. (Else we have to give up on sandboxing.)
15:16:38 <stickster> mcatanzaro: I'm not sure I understand portals, but I'll read up on that
15:16:42 <jwb> mcatanzaro: portals?
15:16:47 <otaylor> mcatanzaro: No difference between difference between xdg-app with filesystem access and rpms
15:16:59 <stickster> jwb: I think it has something to do with data between apps
15:17:12 <stickster> or maybe only applies outside the app
15:17:25 <stickster> not sure, I need to go RTFM
15:17:30 <otaylor> A portal is an interface for an application to do something that would not otherwise be allowed
15:17:53 <otaylor> For example, to access a file on the user's system, to get GPS information, to take a screenshot, etc.
15:18:12 <stickster> otaylor: Basically similar to the model we see for Android or SELinux policies?
15:18:22 <stickster> (conceptually speaking)
15:18:25 <jwb> otaylor: a sort of sandbox-based IPC
15:19:04 <mcatanzaro> otaylor: There is one difference: xdg-app allows for cross-platform packaging. If we allow upstreams ship RPMs then the cross-platform carrot is all we have to convince upstreams to use sandboxed apps.
15:19:39 <mcatanzaro> (This being the point you made last time we discussed it. :)
15:19:53 <stickster> mcatanzaro: That certainly could make upstream life easier both from the delivery POV, and (hopefully?) the bug reporting POV
15:20:03 <otaylor> stickster: I don't think there is much relationship to SELinux policies, but it's a bit like android permissions - more like the Marshmallow type where they are asked for on use, then the old style "on installation"
15:21:06 <mcatanzaro> Anyway the xdg-app sandbox is intended to protect users from malicious apps. It's totally pointless if bad guys can just opt out of the sandbox. (It's also pointless if bad guys can get software into Fedora via RPMs, but maybe if xdg-app is popular we can phase out RPMs in the future. I think it will be very hard to phase out unsandboxed xdg-apps if we allow unsandboxed xdg-apps now.)
15:21:12 <stickster> otaylor: Gotcha. Then it's actually more similar to the model used for e.g. the Windows firewall protection (not sure it's currently the case anymore)?
15:21:32 <stickster> yeah, forget my tortured comparisons. I get it.
15:21:53 <otaylor> stickster: though the idea is to often make them more implicit - rather than "can the app take a screenshot", "show the user the screenshot - is this the one you want to use in the app?" (or something)
15:21:55 <mcatanzaro> And to be clear, I'm only talking about the filesystem access permission.
15:22:34 <otaylor> stickster: The dfifference from windows firewall protection is that we want to make them *user meaningful* - "take a screenshot" not "talk on port 5141"
15:23:27 <jwb> so back to the topic at hand
15:23:29 <stickster> otaylor: understood -- and yes, from your description of how to demonstrate the effect to the user up front makes way more sense.
15:23:32 <stickster> jwb: +1
15:23:40 <jwb> is the intention here to edit this up and then present it to... whom?
15:23:55 <mcatanzaro> Fedora developers, I think
15:24:05 <mcatanzaro> We'll want a shorter blurb for advertising
15:24:21 <jwb> that seems premature?
15:24:26 <stickster> Well, this is a pretty massive expansion (or shift) of policy, so it seems to me we need Council + FESCo buy-in
15:25:13 <stickster> What I believe we *don't* want (and Fedora can't really handle) is to create a plethora of new committees
15:25:30 <jwb> that would be more what i was asking.  would both groups be consulted at the same time, or is there an order you're thinking of?
15:25:41 <otaylor> From the point of view of this proposal, I think unsandboxed xdg-apps and rpms are pretty similar - in that they are potentially quite unsafe, and impose bigger requirements on our vetting process. I'm actually having trouble finding in this proposal what is actually proposed for a decision process for what repositories would be configured
15:26:12 <otaylor> I guess that's the second to last section
15:26:47 <stickster> jwb: I was thinking of Council first, because of the implications for upstream relationship of Fedora -- which is bigger than *how we make Fedora*. otaylor: Agreed, that's something we need to take a better shot at in this draft.
15:27:19 <jwb> stickster: ok
15:28:08 <stickster> Hm, I should start notating here, let me catch up -- sorry guys
15:28:28 <stickster> #info We need a better description of a decision process for configuring sources/repos
15:29:48 <stickster> #idea stickster thinks, after we have this draft in shape, we should be sharing/consulting with Council first since this doc represents change in the way Fedora deals with upstream, which goes quite outside how we build Fedora itself
15:31:18 <stickster> #info mcatanzaro notes that the portal definition (which allows xdg-apps to touch resources outside the sandbox) isn't complete, and needs to be before they're usable upstream
15:31:32 * stickster feels caught up now
15:32:22 * mclasen here now
15:32:52 <stickster> Hey mclasen! Hopefully with all your teeth intact to grind well into the future :-)
15:32:55 <stickster> #chair mclasen
15:32:55 <zodbot> Current chairs: kalev mcatanzaro mclasen otaylor rdieter stickster
15:33:07 <mclasen> brandnew crown, but I'm not supposed to grind it yet
15:33:34 <stickster> mclasen: you're hereby authorized to chill out until it's set
15:35:58 <stickster> So there are still some gaps/questions in this document. Just starting from the top, I had a question about rulesets and how they're implemented. Presumably xdg-apps are meant to be adopted outside Fedora. Since other communities have differing rules for what's acceptable, there needs to be an abstract ruleset that allows other communities to present software properly in their utilities (whether
15:36:04 <stickster> GNOME Software or other)
15:36:52 <stickster> mclasen: Also, do you happen to have a copy of a screenshot of the labeling feature? I couldn't pull it out of cschaller's draft.
15:37:49 * stickster is guessing everyone is now reading this doc :-)
15:38:10 * mclasen is browsing his screenshot collection
15:39:36 <stickster> I don't want to spend the balance of the hour pontificating to myself... would the best course of action be to pull the set of questions into separate topics on the list?
15:40:05 <mclasen> haven't found the screenshot yet, but I'll caution that there's still quite a bit of discussion around the right way to present this information
15:40:10 <mclasen> see https://bugzilla.gnome.org/show_bug.cgi?id=763371
15:40:13 <stickster> sorry, that sounded super harsh, it was meant with :-)
15:40:22 <mclasen> and https://bugzilla.gnome.org/show_bug.cgi?id=763372
15:40:42 <stickster> mclasen: certainly... it's clear this is a draft anyway; I'm just looking for something to throw in where the doc says it will be :-)
15:41:50 <stickster> mclasen: Also, I like Allan's points in 763371.
15:43:07 <stickster> OK, since things have gone pretty silent here, other than me & Matthias, I'm going to #action a few things
15:43:32 <stickster> #action mclasen try to locate screenshot of *draft* Software implementation of labeling, with understanding it's still under review/change
15:44:09 <stickster> #aciton stickster Break out topics of uncertainty in the draft to separate list threads so we can resolve in the draft
15:44:13 <stickster> argh
15:44:15 <stickster> #action stickster Break out topics of uncertainty in the draft to separate list threads so we can resolve in the draft
15:44:34 <stickster> #action stickster Go over draft again with an editorial eye to simplify and clarify language
15:44:43 <mclasen> https://plus.google.com/+RichardHughes/posts/LkctoSAA8EF maybe ?
15:45:09 <mclasen> thats how it appears in search results currently
15:46:13 <stickster> mclasen: Hmm, not the one from the draft; maybe you can reach out to Christian to have him send one
15:47:00 <stickster> also it concentrates on Steam stuff which might be confusing to readers (even though it's perfectly applicable)
15:47:13 <stickster> anyway, minor detail, we can fix that as we go
15:48:09 <stickster> mcatanzaro: rdieter: otaylor: kalev: Anything you guys want to comment on before we close up? Otherwise we can move this to #fedora-workstation and the list, and let that power the next agenda
15:48:42 <mcatanzaro> No further comments, besides to add that this change is a really big deal and we should be careful to market it as well as possible.
15:48:43 * rdieter has nothing
15:48:54 <otaylor> I don't think so ... it doens't seem like fine-grained editing in the meeting makes sense.
15:49:08 <stickster> otaylor: agreed
15:49:15 <stickster> mcatanzaro: agreed with you too
15:49:25 <stickster> EVERYONE GETS AN AGREEMENT
15:50:05 <stickster> But seriously, let's not kid ourselves; this is a big deal and needs review, careful thought, and input from all of us
15:51:10 <stickster> #info This draft will be the subject of future WG agendas, so all WG members' time is needed to review and contribute
15:51:24 <stickster> #topic Open floor
15:51:35 <stickster> I'll hold this open for a minute to make sure no one has anything else to add
15:52:23 <rdieter> may be worth mentioning explicitly here that I pulled the trigger disabling pulseaudio flat volumes last week
15:52:39 <rdieter> in retrospect, I'm not sure if there was consensus on that yet or not, so...  ??
15:53:33 <stickster> #info PulseAudio flat volumes have been disabled in F24 based on Wim's input
15:53:36 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1265267#c27
15:53:40 <rdieter> I did see mclasen mention some unhappiness about it in #fedora-workstation when it happened
15:54:34 <mclasen> I couldn't quite square what happened in the bug with what was discussed in the meeting
15:54:37 <rdieter> (I'm open to reverting, if that's what the group wants, I'm just not certain what that is)
15:55:13 <mclasen> I'm not saying we need to revert this now
15:55:15 <mcatanzaro> At the meeting we agreed to ask Wim to prioritize work on the bug and revisit next month.
15:55:55 <mcatanzaro> In the bug, Wim said he changed his mind and now supports disabling flat volumes, hence rdieter and I incorrectly assumed there would be no further objection to making the change.
15:56:11 <mclasen> but then it was revisited the next day
15:56:14 <mcatanzaro> Note that rdieter and Wim are both PA maintainers, and I only ever brought this up to the WG because the PA maintainers wanted to keep flat volumes.
15:57:15 <stickster> mclasen: Who revisited it and what was the outcome of that discussion?
15:57:18 <mclasen> my argument for not disabling them now was not based on pa maintainers opinions
15:57:28 <mclasen> rdieter and mcatanzaro revisited it in bugzilla
15:57:30 <mcatanzaro> It was only "revisited" in the bug report.
15:57:35 <mclasen> and the outcome was that flat volumes were disabled
15:57:42 <mclasen> and I was miffed
15:57:52 <otaylor> What I want is an actual plan with description of how it is going to affect a) app developer's b) system UI components c) users's
15:58:05 <stickster> mclasen: OK -- Sorry, I misunderstood, and thought you were saying someone was discussing it elsewhere,
15:58:19 <otaylor> And some discussion about cross-distro aspects of a)
15:58:33 <stickster> otaylor: That's what's missing from Wim's comment. He seems to think some design and implementation work are needed, but there's no one who clearly has the ball to do that
15:58:33 <mcatanzaro> Maybe we should continue this discussion at the next meeting... and invite some PA folks?
15:59:10 <stickster> mcatanzaro: That seems like a good idea, but it would also be good for rdieter to note in the bug that the current disablement is not irrevocable and that we want to do that
15:59:20 <mcatanzaro> stickster: Based on Wim's comment in the bug, I'd say he seems to think design and implementation work are needed to *keep* using flat volumes, not to turn them off.
15:59:23 <mclasen> its not just a question for pa folks; it also affects how we present volumes inm the ui
15:59:23 <otaylor> I think what we *can't* do is "fix" some problem tha people see in this release, the in the next release turn around and "break" it again, and then have a debate then wether we "fix" it again
15:59:31 <mclasen> both in the control center and apps
16:00:19 <stickster> mcatanzaro: that's what I meant -- he sets a bar for bringing FV back; but it's not clear to me if this is contentious to all the PA crew
16:00:20 <mcatanzaro> I'd like to have PA folks at the meeting because TBH I do not understand how our current volume model works; sometimes YouTube raises my system volume, and sometimes it limits the web process volume somehow so that it is too soft and I can't raise it except in system settings, it's *very* confusing.
16:00:30 <stickster> mclasen: and agreed
16:00:36 <stickster> Let's put this first on next week's agenda
16:00:43 <kalev> yes, I wanted to note it as well that I was suprised that this got changed after we ended up deciding to keep the current default of using flat volumes
16:01:03 <stickster> #action stickster Put PulseAudio flat volumes on next week's agenda first
16:01:07 <mcatanzaro> #action mcatanzaro to invite some PulseAudio folks to next week's meeting
16:01:10 <stickster> and... we're over time, that's what I get for open floor :-)
16:01:17 <linuxmodder> coming in late  otaylor  but to point  b) above  in what context exactly
16:01:46 <stickster> mcatanzaro: Great, feel free to enlist rdieter help too :-)
16:02:14 <stickster> I'm going to close here, further discussion --> #fedora-workstation
16:02:18 <stickster> #endmeeting