14:00:01 <stickster> #startmeeting Workstation WG
14:00:01 <zodbot> Meeting started Wed Sep 30 14:00:01 2015 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:03 <stickster> #meetingname workstation
14:00:03 <zodbot> The meeting name has been set to 'workstation'
14:00:04 <stickster> #topic Roll call
14:00:07 <stickster> .hello pfrields
14:00:09 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
14:00:35 <mcatanzaro> Hola!
14:00:50 * mclasen__ is here
14:01:17 <stickster> o/
14:01:27 <otaylor> here
14:01:33 <juhp_> hi
14:01:51 <stickster> I hope everyone enjoyed their little respite, first time meeting in a few weeks ;-)
14:02:36 <cschalle> o/
14:02:38 <stickster> #chair mcatanzaro mclasen__ otaylor juhp_ cschalle
14:02:38 <zodbot> Current chairs: cschalle juhp_ mcatanzaro mclasen__ otaylor stickster
14:02:53 <mcatanzaro> Oh I get it, the o/ is a wave! o/ o/
14:03:05 <mcatanzaro> Learning new emoticons is fun!
14:03:18 <stickster> yes! ;-) and I celebrate your learning: \o/
14:03:26 <stickster> #topic Utilities folder entries
14:03:34 * rdieter waves, hola
14:03:41 <stickster> #chair rdieter
14:03:41 <zodbot> Current chairs: cschalle juhp_ mcatanzaro mclasen__ otaylor rdieter stickster
14:03:44 <stickster> o/
14:03:59 <stickster> mcatanzaro: Did I understand right that you're creating downstream patches to get things reshuffled properly?
14:04:12 <cschalle> ~o~ -> electric bogey
14:04:19 * stickster thinks this might be a short item on the agenda... but he's been wrong before :-)
14:04:22 <mcatanzaro> stickster: Yeah but I don't have permission to touch Characters
14:04:35 <mcatanzaro> Need a provenpackager or the maintainer to add access for the gnome::sig group.
14:04:55 <mcatanzaro> Anyway it was 5 minutes of work, easier to fix than to discuss. :p
14:05:07 <mclasen__> I could throw in some agenda items if it helps
14:05:09 <juhp_> mcatanzaro, gnome-characters?
14:05:09 <stickster> mcatanzaro: I think I'm a provenpackager, so maybe I can add that access?  Or fix
14:05:14 <mcatanzaro> juhp_: Yup
14:05:16 <mclasen__> mcatanzaro: I can take care of it after the meeting
14:05:21 <mcatanzaro> mclasen__: Thanks
14:05:30 <stickster> "anything I can do, he can do better"
14:05:33 <juhp_> mcatanzaro, I can poke ueno
14:05:41 <mclasen__> even better
14:05:41 <mcatanzaro> juhp_: I emailed him last night
14:05:56 <juhp_> or talk him even - he is in my TZ
14:06:03 <juhp_> or team even :)
14:06:16 <stickster> Yeah, let's give him a shot, and if nothing in the next day or so, we can do something more energetic
14:06:17 <juhp_> okay
14:06:41 <mclasen__> some suggested topics: curation of picks in gnome-software
14:06:44 <stickster> juhp_: Yeah, just nudge him if you would
14:06:54 <juhp_> mcatanzaro, if nothing happens - feel free to forward me details
14:06:59 <juhp_> sure
14:07:17 <stickster> #action juhp_ nudge dueno to see email for fixing gnome-characters package
14:07:23 <stickster> OK, anything more on this?
14:07:31 <mclasen__> another suggested topic: developer improvements for f24 (more an open-ended question)
14:07:45 <stickster> OK, that goes to bottom of list then
14:07:48 <juhp_> .whoowns gnome-characters
14:07:48 <zodbot> juhp_: ueno
14:08:13 <stickster> #topic Fedora user agent for Chrome
14:08:20 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1266569
14:08:20 <mcatanzaro> juhp_: OK thanks!
14:09:10 <stickster> This agent apparently went into F22 but with no fanfare or notice to users. The bug was one user objecting, but I've received external pings/complaints about this as well.
14:09:26 <stickster> #idea Add this to Fedora 23 release notes, even though it's already been in, just to ensure users are informed
14:09:54 <otaylor> The complaints are what - that we are making someone's browser marginally more fingerprintable?
14:10:08 <rdieter> +1, the request was that they be informed... somehow.  this satisfies that request
14:10:20 <rdieter> otaylor: basically, yes
14:10:37 <otaylor> Or is this just a matter of surprise? "what's this extension doing here, I didn't install it"
14:10:43 <stickster> otaylor: Correct. I personally don't think this is a big deal from a privacy standpoint since there are a ton of extensions and other solutions already recommended to browse more privately. But the information is the point
14:10:44 <rdieter> otaylor: and that
14:11:20 <mclasen__> I think its a bit of a storm in a teacup - it just shows up for chrome because we have to implement it as an extension there
14:11:31 <mclasen__> for firefox it is just a configuration change
14:11:37 <mclasen__> and nobody complained
14:11:41 <mcatanzaro> The best part of this is that disabling the extension makes you MORE fingerprintable
14:12:10 <mcatanzaro> Or wait, maybe it doesn't, just kidding.... ;)
14:12:35 <mcatanzaro> If we install any other extension then that would be true (you're the only Fedora user without Fedora in the user agent)
14:12:36 * rdieter puts on chrome-extention-tinfoil-hat
14:12:38 <mcatanzaro> But I think we don't. Ignore me!
14:12:39 <stickster> Yup, I'm not advocating we do anything other than note it exists... if there are users out there who feel strongly about it, let them do what they want with the information
14:12:41 <cschalle> yeah, I have tried to respond as best as possible to the bug report, and I don't mind a short notice in the release notes if people feel that is justified
14:13:07 <mclasen__> does the extension come with a clear description ?
14:13:13 <otaylor> If adding something to the release notes gets us past this, I'm +1 - I"d prefer if it was simply informational and said "this has been added for this reason" and *did not* discuss security implications or say that you can disable it it you want
14:13:16 * mclasen__ doesn't use chrome on fedora, so no idea how it looks
14:13:23 <mcatanzaro> rdieter: The package is installed by default right? There is a user in the bug complaining it was pulled in post-install.
14:13:31 <rdieter> mcatanzaro: yes
14:14:14 <otaylor> The diescription that shows up is "Modifies your User-Agent string to contain the name of the Fedora Linux distribution", and with the Fedora logo next to it
14:14:14 <rdieter> mcatanzaro: thought the implementation is... interesting.  the extention doesn't actually install and start working until a user actually runs chrome though
14:14:27 <mcatanzaro> FWIW we've had zero complaints about the user agent change in WebKit, except it broke Google Calendar which now sends us an unusable crap page (but that is not due to adding Fedora, but due to the fact that I replaced "X11" with "Fedora).
14:14:43 <stickster> Interesting, it's not installed on my F22 system. But anyhoo
14:14:49 <cschalle> rdieter, yeah, that was due to a security change in Chrome, where Google only now allows extensions downloaded through the chrome store
14:15:13 <otaylor> stickster: Fresh install?
14:15:14 * stickster doesn't think this is worth a lot of random discussion, I volunteer to write a release note and cc the list :-)
14:15:23 <stickster> otaylor: I actually don't remember
14:15:27 <mcatanzaro> stickster: +1
14:15:52 <mclasen__> stickster: sounds good, +1 from me
14:15:56 <juhp_> I don't have it installed
14:16:10 <stickster> I *thought* I fedup'd this box, but honestly don't recall now
14:16:34 <juhp_> just wonder how it gets pulled in?
14:16:37 <cschalle> juhp_, is your chrome browser configured with a google account?
14:16:45 <mcatanzaro> https://bugzilla.redhat.com/show_bug.cgi?id=1266569#c10 <-- how are we installing this thing??
14:16:46 <juhp_> yes
14:17:10 <mcatanzaro> Oh, nevermind, comment #11....
14:17:32 <rdieter> stickster, juhp_: it's in fedora-workstation comps
14:17:49 <rdieter> fyi
14:18:05 <linuxmodder> on that note  why is  it  deemed needed
14:18:13 <juhp_> rdieter, ah thanks
14:18:18 <mcatanzaro> linuxmodder: Because we don't have any Chrome package
14:18:23 <mcatanzaro> We can't patch the user agent ourselves
14:18:27 <cschalle> mcatanzaro, I guess based on your X11 experience with webkit we do not want to update the browsers then to start saying 'Wayland' instead :)
14:18:36 <stickster> OK, let's move on, we know what needs done next
14:18:51 <linuxmodder> even as a chrome user myself that  seems  sketchy to go all auto optin  tbh
14:18:59 <stickster> #action stickster Draft release note for Docs team and cc the desktop@ list for info
14:19:15 <stickster> #topic PulseAudio flat volumes
14:19:20 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1265267
14:19:57 <stickster> The question for us to decide here is apparently, are we going to disable flat volumes in PulseAudio... the linked bug is an example where our not doing so actually could harm a user
14:20:02 <otaylor> So I think this pretty clearly has to be F24+
14:20:50 <rdieter> otaylor: probably... not sure if there's sufficient justification to rush this
14:20:50 <otaylor> THis is something with UI implications, that affects applications, that can't just be changed past beta
14:20:54 <otaylor> I
14:20:58 <cschalle> ok, well I wouldn't want to make any decisions here without some input from our pulse audio maintainer. I can ask Wim to look at the bug and comment
14:21:03 <mcatanzaro> F24+ indeed. This is a tough one because only the Pulse developers like flat volumes, for some technical reason that I've never seen explained properly. We don't want to overrule them without discussing the issue with them first, to understand why they like flat volumes....
14:21:13 <mclasen__> I wonder if we could get wtay to look into safeguarding the flat volume implementation in pa
14:21:43 <otaylor> 'm pretty sure that the particular scenario that is being described here is *not* an accurate representation of flat volumes working properly - whether it's a mistake on the part of the reporter or a KDE bug, I don't know
14:22:24 <rdieter> to be fair, this bug was only 1 justification behind the proposal to disable flat volumes
14:22:48 <otaylor> Yes - I think there are other legitimate reasons to discuss this - but it really has to be done together with upstream
14:23:12 <stickster> rdieter: Right, it's an example. It links to others. But I also think we don't want to be hasty here without discussing with upstream
14:23:25 <mcatanzaro> The arguments against are pretty convincing, tbh. Agree it needs to be discussed with upstream.
14:23:51 <mclasen__> as I said on the list, we need a volume management that is somewhat tolerant to misbehaving apps
14:24:12 <rdieter> I personally am not swayed by the arguments, but probably mostly because I've personally never experienced any of the problems mentioned with it
14:25:02 <stickster> rdieter: I've run into issues here at home, where I have a large, professional audio monitor system hooked to my workstation. *BUT* I still think the blame tends to lie with badly behaving apps
14:25:45 <rdieter> so maybe treat the "be more tolerant of misbehaving apps" issue as a blocker to *keeping* flat volumes?
14:25:56 <stickster> rdieter: possibly, yes
14:26:36 <cschalle> ok, so I just emailed both Wim Taymans and Arun Raghavan asking them to comment on the bug from a PA perspective
14:26:47 <cschalle> I suggest we leave it until next time so we can review their feedback
14:26:58 <mcatanzaro> cschalle++
14:27:24 <rdieter> +1
14:27:26 <mclasen__> the bug reporter talks about using kmix and amarok - do we have reports of the same problem with the default workstation install ?
14:28:21 <mcatanzaro> mclasen__: It is a problem for WebKit. If you make a YouTube web app, you're going to get 100% volume, because web pages have full access to your system volume.
14:28:36 <rdieter> I vaguely recall a "me too" or 2 in the ml thread, but it got so long and convoluted, I stopped reading it after awhile
14:29:05 <stickster> #action stickster review BZ 1265267 input from Wim/Arun for next meeting
14:29:18 <mcatanzaro> Web sites don't expect this; it's allowed by the DOM standard but nobody implements it except Linux with Pulse and flat volumes (i.e. non-Ubuntu Linux) so zero web sites expect that behavior
14:29:30 <mclasen__> mcatanzaro: did you ever discuss having a 'safety limit' with the pa guys ?
14:29:49 <otaylor> mcatanzaro: Well, if the DOM standard doesn't allow querying what is the case it's fairly impossible for a web site to handle it
14:29:53 <mclasen__> and why can't webkit do the limiting itself ?
14:30:34 <mcatanzaro> mclasen__: They promised to create a "browsers API" for us, so that we can get non-flat-volume behavior in only web browsers. But I don't think it's ever happened.
14:31:00 * stickster still not clear on what "limiting" means here... don't some computers have quieter speakers where a limit would inconvenience users?
14:31:05 <otaylor> mclasen__: I don't think a "safety limit" makes sense - whether 100% volume is unsafe depends on the user's equipment - what is safe on one equipment could be too quiet on another
14:31:12 <stickster> otaylor: *jinx :-)
14:31:33 <mclasen__> I would imagine a setting in the sound panel where I could say "never raise system volume above 70% when switching applications"
14:31:50 <mclasen__> of course, if it is already at 100%, then thats a user choice and should not be lowered
14:32:11 <otaylor> mclasen__: I think that's basically a system volume in the non-flat meaning
14:32:30 <mclasen__> maybe so
14:32:34 <mcatanzaro> Well IMO the sane thing to do is to never allow apps to raise the system volume... but the Pulse folks disagree.
14:32:47 <mcatanzaro> And the Pulse folks know audio way better than I do....
14:33:02 * stickster thinks we should probably not debate implementations here in the meeting, but we can always take this to #fedora-workstation afterward
14:33:09 <cschalle> ok, so we our temporary recommendation to users is to mute their speakers and just sing themselves when they want sound. And we will work with upstream PA for a long term fix :)
14:33:21 <drago01> well the fact that we have one volume slider that goes up to 150% and one that is limited to 100% also makes no sense
14:33:22 <otaylor> mcatanzaro: I don't think they can raise the system volume in the sense you mean - but one of the main problems with flat volumes is that it's really hard to understand :-)
14:33:25 <rdieter> no compromise like "never allow apps to raise volume more than amount X?"
14:33:39 <drago01> the problem is our volume contol ui is a mess
14:33:58 <mcatanzaro> otaylor: No kidding. :)
14:33:59 * mclasen__ feels its time to move on
14:34:05 <cschalle> +1
14:34:05 <stickster> mclasen__: agreed
14:34:10 <rdieter> <nod> move on+++
14:34:36 <drago01> otaylor: as I said on the list its easier to understand with a proper ui like the windows one
14:34:38 <stickster> I'll look for input from the PA devs and in the meantime we can raise a thread on list to figure out if we have any consensus we can work on with them
14:34:49 * otaylor agrees with the move-on
14:35:06 <mcatanzaro> +1
14:36:31 <mclasen__> drago01: like, having each apps' volume as a slider on the last tab ?
14:36:34 <stickster> OK, I'm not sure we have a clear question on langpack stuff yet. mclasen had suggested a topic but I didn't grab it from backscroll
14:36:45 <stickster> mclasen__: What was the other topic you brought up?
14:36:52 <mclasen__> I suggested 'editors picks curation in gnome-software
14:37:13 <mclasen__> unfortunately, kalev is out this week, he would be a good person to have in the meeting for this topic
14:37:19 <juhp_> aha
14:37:31 <drago01> mclasen__: not just showing them but in relation to each other and the system volume (hard to describe but it makes sense when you see/use it)
14:37:33 <mclasen__> and it appears, rlerch is not around either (unsurprisingly)
14:37:48 <stickster> mclasen__: You had an open-ended discussion topic, which I'm happy to have at the end of the meeting after other decision stuff
14:37:56 <mclasen__> drago01: I've seen the windows slider ballet
14:38:05 <stickster> F24 development ideas, I believe
14:38:08 <mclasen__> stickster: developer features for f24
14:38:13 <stickster> #topic F24 developer features
14:39:02 <stickster> So one thing that would be interesting is extending Builder
14:39:17 <mclasen__> so, I just wondered if we want to brainstorm about making development easier for containers, different runtimes (say software collections), etc
14:39:38 <stickster> mclasen__: Coincidentally, that was an area where I was thinking about extending Builder :-)
14:39:38 <mclasen__> builder is certainly an item here
14:39:57 <mclasen__> and I intend to discuss it with christian hergert at the gnome summit in a few weeks
14:40:17 <mclasen__> there's also things like vagrant
14:40:19 <stickster> like making it easier to make Docker or Vagrant images, repos/COPRs... as I understand this could be done largely with plugins because of the way Builder is architected
14:40:30 <stickster> Wow, is there an echo in here? :-D
14:40:51 <stickster> mclasen__: ryanlerch is interested in helping with design here
14:41:20 * otaylor wonders if putting too much onto Builder's shoulder's is a mistake - isn't it enough of a project to make it a good ide for a few use cases?
14:41:50 <mcatanzaro> otaylor: I think there's a good chance Christian wants Builder to cover these cases
14:42:00 <stickster> otaylor: Not sure I agree, if the upstream is agreeable about some plugins here -- look at gedit for instance which has evolved into a fantastic tool
14:42:04 <mcatanzaro> It's definitely designed to make deploying to physical devices easy
14:42:15 <mcatanzaro> And to VMs. Containers are different but not too different....
14:42:37 <stickster> I talked to Ryan on Monday night and he had some initial discussion with chergert about the concept
14:42:52 <mclasen__> we should probably figure out if using an ide like builder is something that 'container developers' would consider natural
14:43:02 <mclasen__> if there is such a thing as a 'container developer'
14:43:12 <otaylor> I think trying to address server use cases with Builder is something that could be done eventually, but I'd much rather we *targeted* that - let's be awesome at building your app as a docker image - rather than exposing some morass of choose-your-own-adventure
14:43:32 <stickster> I think it's more about concentrating on what they are looking to do which is just get their app tested or deployed somewhere
14:44:06 <stickster> ^ that was reply to mclasen__ -- but I think it agrees somewhat with what otaylor is saying
14:44:33 * stickster wonders if this really means we need GNOME Deployer :-)
14:44:39 <otaylor> in general, being awesome for server development means coordinating with the rest of fedora to try and keep a clear picture of what we mean by a "server application"
14:44:41 <mcatanzaro> My worry about Builder is, upstream is kind of unemployed and running out of money, Christian has indicated he won't keep developing much longer without more funding, and the IDE is really not ready yet; that all doesn't bode well for the future. Something to keep in mind....
14:46:25 <stickster> Well, let's let the upstream input determine workload/time available -- we're talking about concepts here. But agreed, mcatanzaro
14:46:35 <drago01> well "server developers" use IDEs like pycharm, eclipse, ,,, which are already cross plattform
14:46:53 <drago01> I don't belive they would switch to builder when using fedora
14:46:58 <mcatanzaro> So are we out of decision items to discuss? This has degraded into a brainstorming session again. :)
14:47:23 <stickster> mcatanzaro: That was intentional, leaving this topic until last ;-)
14:47:26 <mcatanzaro> OK
14:47:49 <stickster> let me take a note for the meeting minutes at least
14:48:08 <drago01> we really need to find out what developers miss on fedora (i.e get data) instead of this guesswork
14:48:14 <stickster> #idea extending GNOME Builder to provide additional container related tools
14:49:54 <stickster> The first person who says "survey" gets to clean up after Flock pub night
14:50:18 <drago01> I didn't use that word ;)
14:50:21 <stickster> heh
14:50:33 <stickster> Does anyone else want to submit an idea for developer features?
14:51:41 <otaylor> drago01: I dont' think server developers are generally using Windows/Mac because there are missing development features on Linux (in general), they are using them as general purpose OS's that are good enough for developing for deployment on Linux - so the question (to me) is how we make things *more awesome* than what developers are used to
14:52:05 <mclasen__> one concrete thing that came up in a discussion this morning is runtimes
14:52:19 <mclasen__> can we make it easy to develop and build e..g rhel applications on fedora ?
14:52:35 <mclasen__> say, install a 'rhel7 toolchain' ?
14:52:45 <mclasen__> and produce builds that will work on rhel7
14:53:07 <mclasen__> maybe software collections are an answer to that...but an awkward one
14:53:34 <mcatanzaro> Goal: it should be just a matter of adding a rhel7 target in Builder, and then clicking on that in the left sidebar.
14:54:09 <stickster> #idea make it dead simple to develop and build a RHEL application on Fedora, possibly through Builder
14:54:54 <mcatanzaro> And of course, s/RHEL/whatever linux/, but RHEL is a good place to start!
14:54:55 <stickster> I like the idea, though like mclasen__ I'm not sure SCL are as attractive an answer as we'd hope
14:55:47 <stickster> OK, I have a call coming up back to back with this meeting, so is there anything further on this before we call it an hour?
14:56:27 <stickster> Looks like not.  To the list!  And thanks for coming, everyone
14:56:28 <stickster> #endmeeting