13:00:10 <stickster> #startmeeting Fedora Workstation WG
13:00:10 <zodbot> Meeting started Mon May 11 13:00:10 2015 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:16 <stickster> #meetingname workstation
13:00:16 <zodbot> The meeting name has been set to 'workstation'
13:00:19 <stickster> #topic Roll call
13:01:01 * Capesteve waves
13:01:11 * mcatanzaro is here.
13:01:35 <juhp_> hi
13:01:40 <kalev> hello
13:01:46 <stickster> o/
13:01:56 <sgallagh> /me waves
13:02:17 <rdieter> here
13:02:24 <stickster> #chair juhp_ kalev mcatanzaro mclasen_ rdieter
13:02:24 <zodbot> Current chairs: juhp_ kalev mcatanzaro mclasen_ rdieter stickster
13:02:54 * mclasen_ still struggling to internalize the new time
13:03:31 <stickster> I think we have quorum, so let's get started
13:03:43 <stickster> One quick order of business:
13:03:49 <stickster> #topic Workstation report for FESCo
13:03:55 <stickster> #link https://fedoraproject.org/wiki/Workstation/Fedora_22_Workstation_FESCo_report
13:04:24 <stickster> As seen on the list... I'm making this available to sgallagh following this meeting, so if you have any changes, please edit the wiki or respond to list
13:05:49 <stickster> In the meantime, we can move on :-)
13:05:55 * mclasen_ admits not having read it until now
13:05:56 <stickster> #topic F23/F24 Workstation planning
13:07:08 <stickster> Here's the fun stuff. :-) The existing Workstation PRD is quite broad. So as I was working on that report, it occurred to me that we need to come up with more specific changes that will take developer experience to the next level.
13:09:03 <stickster> A lot of the changes were inherited from upstream GNOME -- which is great, because Fedora is supposed to collaborate upstream.  But IMHO we need additional focus on features that specifically attract relevant folks to Fedora Workstation.
13:10:35 <mclasen_> we should look at container tools, maybe
13:10:37 <stickster> For instance, we have a DevAssistant app which does environment and project setup. But AFAIK there's no seamless way to package up work into a deployable form
13:10:48 <stickster> mclasen_: *jinx, kinda :-)
13:11:10 <sgallagh> stickster: cschalle and I were discussing on Friday a number of improvements we could make to Fedora's behavior within an AD/FreeIPA domain as well.
13:11:25 <mclasen_> like, whats it called, the oh my vagrant stuff
13:12:06 <mcatanzaro> SLED has some AD patch for gnome-shell, but I'm not sure exactly what it's for.
13:13:15 <sgallagh> mcatanzaro: I'd be very interested to learn about that. Any link? (DDG is failing me at the moment)
13:13:33 * mclasen_ unsure why the shell would need to be involved
13:14:11 <stickster> mclasen_: sgallagh: Good ideas both... what's the right way to flesh those ideas out?  Should we describe what the improvement looks like to the user?
13:14:25 <juhp_> +1 for container tools
13:14:35 <mcatanzaro> My search for a link has led me to believe I am completely crazy, maybe not. :D (Continues to search....)
13:14:59 * mcatanzaro remembers looking at it yesterday, confused.
13:15:47 <sgallagh> stickster: On the AD front, I'd say that a major user-experience change would be that users who have authenticated to a machine in a domain should automatically have access to domain-enabled services (such as web applications like SharePoint).
13:16:39 <sgallagh> Right now, users have to make manual edits to their browser config to do stuff like that.
13:17:14 <mclasen_> stickster: we could reach out to purpleidea - I don't know if his stuff is already in fedora or not
13:17:22 <mcatanzaro> https://build.opensuse.org/package/show/SUSE:SLE-12:Update/gnome-shell
13:17:26 <mcatanzaro> ^gnome-shell-domain.patch
13:17:35 <stickster> sgallagh: How seamless is the current experience for things like access to file shares, printers, etc. in those domains?
13:18:08 <sgallagh> mcatanzaro: Looks like an alternative implementation of the realmd UI.
13:18:22 <mcatanzaro> FWIW access to normal home printers is too hard right now (requires admin authentication)
13:18:26 <sgallagh> stickster: The seams are so wide you can't see one side from the other :)
13:18:56 * mclasen_ asks halfline about that domain patch
13:18:58 <stickster> sgallagh: Ugh :-) but that's what I expected
13:19:18 <stickster> mcatanzaro: Does that have something to do with the default PolicyKit policies?
13:19:31 <mcatanzaro> stickster: Yes
13:19:45 <stickster> mcatanzaro: Seems like low-hanging fruit we should fix.
13:20:15 <stickster> I know this was a firestorm about... I dunno, 4 releases ago? But that was before we broke the editions out
13:20:28 <stickster> Hey, we need to get these ideas in the minutes.
13:20:36 <stickster> #idea Improvements to AD/FreeIPA domain behavior (integrate WS into mixed env)
13:20:52 <stickster> #idea Container tools for developers to use on projects / integrate with DevAssistant
13:20:57 <rdieter> my understanding is that there is at least one part of the cups setup that requires local root auth, that is not yet polkit-ized
13:21:12 <stickster> #idea Make home printers easier to access without admin authN
13:21:43 <mcatanzaro> rdieter: You can definitely do everything for most printers from gnome-control-center, no root required.
13:22:05 <rdieter> mcatanzaro: that's what I was told when I complained to dev behind kde's printer applet
13:22:21 <mcatanzaro> If you want to access the cups web server that runs locally, then you need to log in as root.
13:22:49 <sgallagh> stickster: #idea Access to Active Directory printers and file-shares should be simplified
13:22:52 <sgallagh> (I'm not chaired)
13:22:56 <stickster> #chair sgallagh
13:22:56 <zodbot> Current chairs: juhp_ kalev mcatanzaro mclasen_ rdieter sgallagh stickster
13:23:03 <sgallagh> #idea Access to Active Directory printers and file-shares should be simplified
13:24:05 * mclasen_ has little hope for making AD integration work nicely unless we use it internally
13:25:02 <stickster> mclasen_: simply because we need daily access to a working domain to effectively develop fixes?
13:25:43 <rdieter> dog food'ing stuff never hurts
13:26:12 <stickster> rdieter: In this case, might be more like s/never hurts/is crucial/ :-)
13:27:29 <stickster> On a related note, the container/deployment idea might require -- or at least benefit from -- some infrastructure behind it.  As the person who manages some folks who work full time on infrastructure, this is of interest to me :-) (Mr. Selfish)
13:28:08 <sgallagh> stickster, mclasen_: I'm looking into ways we can work with a partner for dogfooding purposes.
13:28:26 <sgallagh> I will report back when I have someone on the line
13:29:01 <stickster> sgallagh: That would be really helpful. I have no idea whether Fedora infra has the capability to provide (in an easy to provision way) a Windomain -- making it integrate in our process could be doubly as hard as the development work
13:29:38 <stickster> But for the container stuff -- that seems like a lower bar, at least to my untrained eye
13:31:24 * rdieter trying (and mostly failing) to pull actionable items from recent "Why people are not switching to Fedora" thread
13:31:30 <stickster> The question is what we want for an end user experience... end-user dev can spin up a container on a choice of (a) self-hosted Box; (b) service-hosted system (EC2, GCE, other?)
13:31:58 <stickster> rdieter: I haven't yet had time to review the whole thread but I was hoping someone else would have input from it in this discussion. :-)
13:32:49 <stickster> juhp_: What did you get out of that thread?  (/me mercilessly calls on Jens since we are finally meeting when he's available) ;-)
13:32:53 <rdieter> the only thing I can think of is giving help/assistance to make rpmfusion better somehow
13:33:20 <stickster> Ah, cschalle is here now too
13:33:22 <stickster> #chair cschalle
13:33:22 <zodbot> Current chairs: cschalle juhp_ kalev mcatanzaro mclasen_ rdieter sgallagh stickster
13:33:35 <juhp_> stickster, I am afraid I haven't read it yet... will try to look over it
13:34:04 <stickster> rdieter: I didn't see what help people were seeking. Is it a release process issue?
13:34:14 <juhp_> sorry for missing so many meetings - I think I missed the new time
13:34:27 <stickster> juhp_: We just started this new time a few instances ago :-)
13:34:28 <mcatanzaro> stickster: There is no rpmfusion for F22, and at the rate they're going there will not be.
13:34:33 <sgallagh> rdieter: Unfortunately, we can't really do that. We've been told by The Lawyers that providing people with information on how to get to RPMFusion could be construed as "contributory infringement"
13:34:34 <juhp_> okay :)
13:34:50 <rdieter> stickster: nothing specific, just many complaints were that rpmfusion was unsatsifactory, for reasons unknown
13:34:58 <juhp_> mcatanzaro, hmmm
13:35:04 <cschalle> what we can do though, is work with rpmfusion or similar to split out the parts of rpmfusion the lawyers are not worried about
13:35:13 <stickster> I *do* recall seeing cschalle posted some follow ups noting that the third party issue seems to be a real barrier for people.  I also understand the contributory infringement problem and that we need to exercise care here
13:35:17 <mclasen_> one relatively frequent complaint is that rpmfusion lags behind
13:35:17 <sgallagh> cschalle: Those parts don't exist.
13:35:19 <rdieter> sgallagh: I'm talking more about making rpmfusion itself better, not changing fedora at all
13:35:21 <mclasen_> ie no f22 branches yet
13:35:22 <stickster> Ah, hi cschalle, you can speak for yourself now :-D
13:35:36 <sgallagh> If the lawyers weren't worried about it, they'd be in Fedora proper already
13:35:56 <cschalle> sgallagh, they do, there are a lot of stuff in rpmfusion that are not problematic from a legal perspective, Steam client being one example
13:36:10 <rdieter> sgallagh: agreed, fedora itself cannot legally do anything differently (as far as patented stuff goes)
13:36:13 <sgallagh> cschalle: Oh, you're talking about the non-free repo
13:36:33 <mcatanzaro> cschalle: Steam is nice to have, but MP3 and H.264 are must-have, so splitting doesn't help much.
13:36:37 <sgallagh> cschalle: RPMFusion's "free" repo is all stuff we can't ship because of licensing/patents
13:36:38 <stickster> Yeah, there's really non-free-but-legal and non-free-but-we-think-legally-questionable
13:36:50 <sgallagh> /me nods
13:36:53 <cschalle> mcatanzaro, no, but there we might be able to do something throught Cisco and Fluendo
13:36:59 <jwb> the 'free' rpmfusion repo has some f22 builds now
13:37:04 <sgallagh> The non-free-but-legal situation is one we could do something about, with Council approval
13:37:21 <number80> sorry for intruding, but the main problem with rpmfusion lagging is that they are understaffed (1 person is maintaining the build infra and struggling with migration from *plague* to koji)
13:37:23 <stickster> sgallagh: Only as long as people understand this is not about trying to push Fedora itself toward non-freeness
13:37:30 <sgallagh> It's *technically* a violation of ancient Fedora dogma, but maybe it's an acceptable violation.
13:37:40 * mclasen_ throws https://github.com/purpleidea/oh-my-vagrant in for people who might not know what he was talking about earlier
13:38:02 <stickster> number80: Yeah, I think people understand that well -- it's a struggling volunteer effort, and the nature of rpmfusion makes it difficult for Fedora to commit resources to help
13:38:17 <cschalle> mclasen_, heh, I thought you where trying to be funny by referring to it as 'oh my vagrant' :)
13:38:18 <kalev> number80: I am not sure we can actually contribute to their efforts without getting fedora/redhat in potential trouble?
13:38:32 <mcatanzaro> cschalle: Cisco and Fluendo both have completely open source codecs that the lawyers would be OK with, but the problem is the license on their binaries is nonfree....
13:38:42 <number80> stickster: question, would it be possible to fund rpmfusion somehow ?
13:38:45 <cschalle> mcatanzaro, yes, but that is not a legal issue
13:38:47 <stickster> mclasen_: Thanks -- I don't believe that's packaged in Fedora yet, not sure how high a bar that is and whether upstream would be interested, but we should talk to purpleidea about it
13:38:59 <sgallagh> kalev: IANAL, but if non-redhat employees were to volunteer their time, I doubt it would reflect on Red Hat
13:39:06 <stickster> #idea Talk to purpleidea about packaging oh-my-vagrant as part of container tooling
13:39:44 <stickster> number80: I kind of doubt that. Prima facie sounds like it would run afoul of the "contributory" definition
13:40:05 <cschalle> there are also some parts of the rpmfusion free that it might be time to review again for their freeness, been seeing some claims that the remaining freetype stuff should be mergable for instance
13:40:20 <pingou> mcatanzaro: there is RPMFusion for F22
13:40:31 <kalev> and mp3 patents are about to expire, as I keep hearing
13:40:32 <mcatanzaro> Maybe we can get our codec installer to point to Cisco/Fluendo codecs? They would be unacceptable for corporate deployments, but perfectly fine for home users. We just have to make gnome-software show EULAs.
13:40:32 <juhp_> mclasen_, thanks
13:40:41 <number80> well, rpmfusion is hosted in France where it complies with our local laws (the only package that couldn't be shipped was libdvdcss)
13:40:47 <mcatanzaro> pingou: There wasn't a week or so ago; that's good.
13:41:19 <stickster> pingou: ISTR seeing an update to the keys recently, probably that's a sign of the update?
13:41:21 <mclasen_> cschalle: did you look back at previous discussion around freetype ?
13:41:34 <mclasen_> maybe best to wait until owen is back
13:41:35 <rdieter> cschalle: fwiw, I checked into rpmfusion/freetype recently, there's one remaining patent
13:41:41 <jwb> stickster, the 'rawhide' repo has f22 builds now
13:41:41 <cschalle> mclasen_, ok, sorry must have missed that
13:41:54 <cschalle> rdieter, is it the MS colour mask thing?
13:42:19 <mclasen_> cschalle: I meant old discussion on the mailing lists, not backscroll in this channel, fwiw
13:42:25 <rdieter> cschalle: sorry, I don't recall details, just that it is the last/only thing that rpmfusion's freetype differs compared to fedora's
13:42:27 <mcatanzaro> rpmfusion is also too difficult to install.
13:42:42 <rdieter> (and interestingly, ubuntu enables that feature)
13:42:52 <cschalle> also I asked the graphics guys to investigate the s3TC patent stuff, as it might either be invalid (seems to have been part of some HTC vs Apple lawsuits that HTC lost, or it can be replaced by the new TC API in newer OpenGL)
13:43:04 <stickster> mcatanzaro: Not only that, but I'm not sure that, once you *do* install it correctly, codec or other capability searches work consistently
13:43:10 <mcatanzaro> rdieter: subpixel rendering?
13:43:16 * rdieter checks
13:43:21 <pingou> mcatanzaro: 2 links to click on?
13:43:30 <stickster> mcatanzaro: Hard to tell when the repos themselves are having issues (as number80 correctly pointed out)
13:43:31 <pingou> stickster: they do afaik
13:43:32 <bochecha> pingou, the problem is arriving to these 2 links
13:43:33 <rdieter> mcatanzaro: yeah, I think that's it
13:43:47 <cschalle> rdieter, ok, because the claim I saw on the freetype website was that the last patent only applied to a very specific algorithm and thus one could use a different one to achieve same/similar results
13:43:57 <pingou> bochecha: it's just in every howto out there :)
13:44:16 <rdieter> cschalle: which one does freetype use?
13:44:22 <cschalle> rdieter, the MS one
13:44:27 <rdieter> sigh
13:44:29 <jwb> you guys are really good at pointing out all of the problems, but i'm not seeing any solutions being suggested
13:44:45 <rdieter> cschalle: so... it's fixable, except no one has bothered to do it yet?
13:44:48 <sgallagh> As far as the difficulty to install the repo, I'd like to see us work on a mechanism for making repo installation via a browser really easy.
13:44:51 <cschalle> rdieter, I guess so
13:44:52 <stickster> jwb: +1
13:45:08 <mcatanzaro> pingou: The homepage needs to have the download link, and it should be prominent. Not on a page linked to from the homepage as part of a list of other links. That's hidden. And there should not be any instructions for using the terminal; users get things messed up when they try to use the terminal.
13:45:23 <sgallagh> We can install RPMs via browser link, but having a "blessed" mechanism to install both a repo and a package from that repo at the same time would be significantly useful.
13:45:24 <pingou> mcatanzaro: I'm sure they will welcome this input :)
13:45:26 <cschalle> sgallagh, that shouldn't be hard, but what people seem tired of is needing to go google hunting for their software to begin with
13:45:41 <sgallagh> cschalle: People have to do that on Windows and seem to live with it.
13:45:55 <sgallagh> It would still be a significant improvement, even if not perfect.
13:45:56 <cschalle> sgallagh, less and less as also windows is moving to the appstore model
13:46:04 <sgallagh> (Perfect is the enemy of good, and all that)
13:46:14 <rdieter> windows doesn't have to worry about being freely redistributable either
13:46:52 <cschalle> rdieter, sure, but as long as we don't actually put any of this software into our install media that shouldn't be an issue
13:47:24 <sgallagh> Right, which is why reducing the barrier for people to install third-party stuff is still an improvement
13:47:31 <sgallagh> Even if we can't show it in GNOME Software itself.
13:47:44 <mcatanzaro> Anyway I think we should aim for having MP3 enabled out-of-the-box in F23. Wikipedia says the last known patents expire in September, so unless our lawyers tell us otherwise, we might as well use the upstream gstreamer MP3 codec.  But for H.264, our only option is the Cisco codec, I think. :(
13:47:58 <stickster> sgallagh: If we don't show something in Software, what is the actual barrier reduction you're proposing?
13:48:06 <rdieter> cschalle: and make sure it's clearly ... deliniated (looking for better term).  fedora advertises itself currently as being 100% freely redistributable... adding content like this changes that expectation
13:48:09 * pingou remebers the time where windows' app store was a website where I was reasonably confident I wouldn't get viruses
13:48:30 <rdieter> mcatanzaro: +1 yay
13:48:31 <sgallagh> stickster: The ability to click on a single link somewhere on the internet, have that piece of software installed and a repo automatically added that will keep it updated.
13:48:53 <sgallagh> We do not have that today. You can either install a repo and then install software from it, or install a single RPM and not have it updated.
13:49:04 <sgallagh> (Exception: Chrome which ships the repo file in the RPM)
13:49:10 <pingou> if you click on the rpmfusion-release rpm from FF, it will ask to install it and you're done, no?
13:49:19 <cschalle> rdieter, agreed, and as  Isaid I don't plan on including any such software by default. If people choose to install stuff that hinders them from copying their install to other people freely then that is not our issue (nor a very common usecase I would think)
13:49:26 <rdieter> pingou: he wants software+repo in one click
13:49:29 <sgallagh> pingou: Right, but it's still two steps to get whichever software you wanted
13:49:48 <pingou> ah, install the repo at the same time you install, say vlc
13:49:54 <sgallagh> pingou: Precisely
13:49:56 <cschalle> sgallagh, couldn't everyone just do as Google?
13:50:06 <rdieter> cschalle: we're talking 2 different things I think.  I'm talking about fedora "as a whole", not just fedora workstation
13:50:09 <cschalle> sgallagh, and bundle the .repo file
13:50:12 <randomuser> I'm curious where the contribution barrier of the RPMFUsion project lies, for the folks that feel that RPMFUsion is inadequate as-is
13:50:15 <sgallagh> cschalle: And have *every* package in the repo bundle the repo file?
13:50:24 <sgallagh> That's one approach, sure. Kind of ugly, but doable.
13:50:27 <bochecha> cschalle, if both vlc and rpmfusion's freetype provide the rpmfusion repo configuration file, you'll get file conflicts
13:50:48 <stickster> bochecha: There's no capability in rpm libs to manage that?
13:50:51 <cschalle> bochecha, I was more thinking in the scenarios with 1 app 1 repo
13:50:53 <sgallagh> What I'm talking about is figuring out the best way and advertising that so RPMFusion, Steam, etc. can all have one vetted way to accomplish it
13:51:02 <stickster> sgallagh: +1
13:51:04 <rdieter> bochecha: not of the repo content is identical, but it is problematic and dangerous (ie, if you ever have to modify the .repo playload)
13:51:15 <sgallagh> bochecha: Not necessarily, as long as they're all the exact same file with the same timestamp, but that's hard to accomplish.
13:51:23 <rdieter> typos about, s/of/if/ and s/playload/payload/
13:51:27 <pingou> cschalle: then you're back to the windows model where each app brings along its update process (here the repo file)
13:51:45 <mcatanzaro> pingou: http://rpmfusion.org/ <-- no F22 there, and none of the links in the matrix are RPMs.  That matrix should contain RPMs to install, and all the details should be buried elsewhere.
13:52:03 <cschalle> pingou, sure, but we are already heading that way with the application bundles
13:52:05 <stickster> sgallagh: Or some wrapper data that Software understands which helps mitigate the problem
13:52:08 <rdieter> it's not the end of the world yet if there's 2 steps (repo + software), I think there are bigger issues to worry about, imo
13:52:08 <bochecha> sgallagh, stickster, cschalle: I didn't mean necessarily conflicts in the sense of rpm refusing to install, but rather all the possible issues that can come out of it (as rdieter mentioned, what if the user modifies that file?)
13:52:18 <stickster> bochecha: *nod, OK
13:52:32 * rdieter wonders how opensuse one-click stuff works
13:52:33 * stickster considers maybe he just suggested a worse hack, and shuts up.
13:52:50 <kalev> how is the codec problem solved in RHEL? doesn't RHEL come with a set of non-free codecs out of the box?
13:52:56 <cschalle> kalev, no
13:53:03 <kalev> arr. :(
13:53:10 <cschalle> kalev, I think it is 'solved' by recommending users to contact Fluendo
13:53:45 <kwizart> mcatanzaro, good point about the front page, even better if you report it appropriately
13:53:48 <mcatanzaro> If you're paying for RHEL, you presumably don't mind paying a fraction of that for Fluendo's codecs.
13:54:03 <kwizart> because that can be fixed easily
13:54:09 <randomuser> perhaps there's some way to advocate unencumbered codecs?
13:54:36 <rdieter> randomuser: been there done that (still doing it)
13:54:44 <stickster> And yet, the world moves on ;-)
13:54:45 <randomuser> rdieter++
13:54:50 <mcatanzaro> randomuser: Hopeless, we can't convert all the media on the Internet... unless we convince Google to drop H.264, like they promised to do years ago, which I bet they will never do now.
13:54:57 <cschalle> randomuser, well the problem with codecs is that they are rarely the users decision. They are most likely captive to whatever website xyz are offering
13:55:22 <randomuser> the user doesn't have the same advocacy leverage that we (you, etc) do
13:55:45 * rdieter echos jwb comment earlier, can we focus on actionable stuff?  seems like we're going in circles about unfixable things
13:55:47 <stickster> So we are knee-deep here in the codec problem... understandable, because it's a clearly identified issue
13:55:56 <stickster> Yeah, what rdieter just said
13:56:24 <cschalle> well as soon as the contract with Cisco is signed and sorted I do plan on proposing a solution based on that
13:56:32 <mcatanzaro> We need to talk to the gstreamer folks about getting the MP3 codec included by default, that is easy and actionable.
13:56:36 <cschalle> so that should be actionable enough :)
13:56:53 <rdieter> stuff I recall: * continue work on including legal (but non-free) stuff in fedora (somehow)
13:57:05 <cschalle> mcatanzaro, it is not a GStreamer issue, we just need an agreement with Fluendo and a yum repository
13:57:44 <stickster> #proposed Someone knowledgeable in each of the tabled #ideas for improvement to draw up some sort of user story / deeper description of the problem and how we might fix in F23/24 timeframe
13:57:46 <mcatanzaro> cschalle: We don't need to involve Fluendo at all IMO; let's use the upstream gstreamer MP3 codec.
13:58:05 <rdieter> mcatanzaro: it's more than just mp3 at issue here
13:58:10 <cschalle> mcatanzaro, we can not do that without risking patent infringement issues
13:58:23 <rdieter> cschalle: mp3 patent expires soon
13:58:30 <jwb> mcatanzaro suggested the patents expire in time for f23
13:58:34 <stickster> OK guys, codecs is just ONE issue -- we have a number of #ideas above, can we agree on how to move forward with all of them, not just beat on codecs? :-)
13:58:51 <cschalle> ah ok, need to recheck then, last time I looked we still seemed to be a couple of years away
13:58:56 <stickster> There's an idea on container tools / deployment
13:59:15 <stickster> There's an idea on AD domain integration for easier web service use
13:59:22 <cschalle> stickster, maybe bring that one up with langdon and see how he could help?
13:59:23 <stickster> There's an idea on AD domain integration for easier file / print service use
13:59:29 <mcatanzaro> cschalle: MP3 is September, according to Wikipedia, so let's include it unless the lawyers tell us otherwise. H.264 is a problem, but for that we need Cisco not Fluendo.
13:59:31 <rdieter> may help to have an advocate/champion for these items, any volunteers for codecs (or even specific items like mp3 alone)?
13:59:44 <sgallagh> stickster: Also for easier access to internal [web-]applications
13:59:56 <stickster> There's an idea on making native printer use easier
14:00:07 <mcatanzaro> Printers should be easy; I will take that.
14:00:14 <cschalle> mcatanzaro, agreed, although we might still want to use the Fluendo implementation simply because of its licensing and non-bundledness
14:00:21 <mcatanzaro> Just changing a couple values in a .policy file.
14:00:28 <stickster> We are out of time, but I'll make sure each of these has a person assigned
14:00:55 <sgallagh> stickster: I'll take the AD stuff at least for investigation (and likely some of the implementation)
14:00:57 <stickster> #action stickster assign people to each of the #idea parts to make sure we have a better defined problem (and maybe solution ideas?) for next meeting
14:01:03 <stickster> Thank you sgallagh and mcatanzaro
14:01:17 <stickster> We need to clear the room, I think randomuser has a meeting in here that we are stomping on
14:01:26 <stickster> --> #fedora-workstation
14:01:41 <stickster> #endmeeting