15:00:00 <stickster> #startmeeting Workstation WG
15:00:00 <zodbot> Meeting started Wed Mar  2 15:00:00 2016 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:00 <zodbot> The meeting name has been set to 'workstation_wg'
15:00:02 <stickster> #meetingname workstation
15:00:02 <zodbot> The meeting name has been set to 'workstation'
15:00:03 <stickster> #topic Roll call
15:00:08 <stickster> .hello pfrields
15:00:09 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
15:00:11 <kalev-afk> .hello kalev
15:00:15 <zodbot> kalev-afk: kalev 'Kalev Lember' <klember@redhat.com>
15:00:26 <stickster> o/ kalev
15:00:33 <mcatanzaro> .hello catanzaro
15:00:33 * kalev unafks.
15:00:33 <zodbot> mcatanzaro: catanzaro 'None' <mcatanzaro@gnome.org>
15:00:37 <mcatanzaro> .hello Catanzaro
15:00:38 <zodbot> mcatanzaro: Sorry, but you don't exist
15:00:45 <kalev> hello mr None!
15:00:46 <stickster> That's darn rude.
15:00:55 <mcatanzaro> .hello mcatanzaro ?
15:00:56 <zodbot> mcatanzaro: Sorry, but you don't exist
15:01:02 <mcatanzaro> Ok then
15:01:03 <stickster> lowercase catanzaro?
15:01:08 <mcatanzaro> Yeah
15:01:56 * stickster waits for a couple more to shuffle in
15:02:11 * mclasen is here
15:02:31 <mcatanzaro> Hm, FAS knows my name... maybe it's because I have the "account info private" box checked
15:02:57 <stickster> could be
15:03:05 <stickster> I think zoddie doesn't have special access to anything
15:03:23 <stickster> Well, let's get started and hope that a few more people show up :-\
15:03:42 <stickster> #chair kalev mcatanzaro mclasen
15:03:42 <zodbot> Current chairs: kalev mcatanzaro mclasen stickster
15:03:47 <mclasen> one short
15:03:51 <mclasen> cschaller should be here
15:04:06 <stickster> *nod
15:04:12 * otaylor his here
15:04:14 <mcatanzaro> rdieter, juhp?
15:04:26 <stickster> #chair otaylor
15:04:26 <zodbot> Current chairs: kalev mcatanzaro mclasen otaylor stickster
15:04:33 <stickster> #topic PulseAudio flat volumes
15:04:53 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1265267
15:05:02 <kalev> did we get a recommendation what to do from wtayman?
15:06:03 <kalev> ahh yes, he was working on upstreaming a fix for that
15:06:21 <stickster> But last I heard, not expected to land in time for F24, correct?
15:06:51 <kalev> mclasen: do you know? ^^
15:06:57 * mcatanzaro has seen no progress, is very tired of his ears getting blasted
15:07:21 <otaylor> mcatanzaro: the ears getting blasted is because you are using Web right?
15:07:31 <stickster> mcatanzaro: I hear you (no pun intended)... This hit me a couple times too
15:07:46 <otaylor> mcatanzaro: and Web is translating web-specified volumes directly into system volumes?
15:07:47 <cschalle_> o/
15:08:08 <stickster> This is one of those rare areas where we can physically hurt a user so it deserves some serious concern
15:08:14 <stickster> #chair cschalle_
15:08:14 <zodbot> Current chairs: cschalle_ kalev mcatanzaro mclasen otaylor stickster
15:08:27 <mcatanzaro> otaylor: Yeah, every time I start or even just seek in a YouTube video, the sound gets set 8x lounder than I like it, I am fed up
15:08:51 <mcatanzaro> It's WONTFIXED on the WebKit side, waiting on a promised "browsers API" from PulseAudio that has never materialized
15:09:13 <otaylor> mcatanzaro: did you (webkitgtk+) decide against the approach firefox takes? It seems like the current webkitgtk+ is just incompatible with flat volumes and things are working "as expected"
15:09:13 <mclasen> so, webkit is putting their head in the sand
15:09:17 <kalev> I am not sure I'd want to fiddle with the defaults if they are going to change again for F25
15:09:38 <mcatanzaro> otaylor: Yes, we have one developer who understands PulseAudio and he flatly rejected that approach.
15:09:43 <kalev> I wouldn't mind changing the default and sticking with the new default, but going back and forth several times seems unoptimal for end users who have to relearn again
15:09:49 <mcatanzaro> He says he's "not willing to do mixing in WebKit"
15:10:08 <otaylor> mcatanzaro: this seems to be 'requires the OS to turn off flat volumes"
15:10:55 <otaylor> mcatanzaro: I don't think this can be the deciding point - we could patch webkit if needed (yeah, blech)
15:11:08 <kalev> I'll note that our default browser is firefox and not epiphany
15:11:19 <stickster> When the upstream fix goes in, though, does that mean WebKit among others will be an unprivileged app that can only adjust up to the system/mixer volume set by the user?
15:11:30 <kalev> does anyone know how well Chrome works with flat volumes? As I understand it, Chrome is the 2nd most used browser in Fedora
15:11:50 <stickster> kalev: I'm on Chrome and I haven't been blasted by any sound as far as I recall
15:11:54 <otaylor> kalev: do we have any design from wtayman for the new approach so we can understand what the behavior will be for the user - whether it's more like flat volumes or non-flat volumes?
15:12:03 <stickster> And I would definitely notice, I'm hooked to a big sound system at the home office
15:12:11 <kalev> otaylor: there's something in the bugzilla ticket linked above
15:12:37 <mcatanzaro> otaylor: I think wtayman's plan is something along the lines of "flat volumes with a global cap" but like I said, we have one person who understands, and I am not him....
15:12:49 <stickster> https://bugzilla.redhat.com/show_bug.cgi?id=1265267#c2
15:12:51 <kalev> stickster: okay, so sounds (no pun intended!) that the two main browsers, firefox and chrome are both working fine with the defaults
15:13:01 <mcatanzaro> It's not just WebKit though, that's the most obvious, people have complained about very many apps
15:13:09 <otaylor> mcatanzaro: hmm, but that would *still* require webkitgtk+ to do something different or the volume controls would work wrong
15:13:10 <stickster> Wim also noted that Windows apparently seems to use the same "global cap"
15:15:06 <stickster> While I don't *generally* like the idea of switching defaults back and forth... I'm concerned about a situation where we can physically hurt users
15:15:10 <mcatanzaro> otaylor: Like I said, once this "browsers API" arrives, we're willing to do something different....
15:15:12 <mclasen> you have to keep in mind that at this point there's hardened opposition to flat volumes, so people will complain no matter what because they 'know' that flat volumes are wrong
15:16:13 <mcatanzaro> We don't care whether Fedora uses flat volumes or not provided our users' ears don't get blasted, right now the only way to avoid that is to disable flat volumes, and I've seen no progress. I'd be satisfied by "we agree we'll switch to non-flat volumes if it's not fixed by X point in time" to give the developers more time.
15:16:54 <cschalle_> looking at the bug comments though I feel saying no progress i a bit hard,seems they are actively working on it
15:17:20 <cschalle_> and if there is a missing last piece needed we could ask Wim too look into that
15:19:28 * kalev agrees.
15:19:32 <stickster> cschalle_: That seems reasonable to me, but if Wim can't explicitly commit to his fixes being upstream before F25, that means at least two releases out, in which case I think there's a stronger case to disable flat volumes now
15:19:36 <otaylor> This is both a point of API design - application developers need to know what to expect - and of UI design - users need to know what to expect.
15:19:38 <mcatanzaro> "The first set of API patches for per-stream volume control have been posted to the list." is the last progress update, which sounds to me like it's stalled
15:20:22 <otaylor> So the idea that we switch back and forth is pretty horrible.' The fact it's been some confused mess across the linux ecosystem for years and years is also, of course, horrible
15:20:26 <cschalle_> mcatanzaro, that was from 18th of Jan, so not very long ago!
15:20:35 <mcatanzaro> Mailing list thread: https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-October/024581.html
15:20:52 <mcatanzaro> And: https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-October/024573.html
15:21:22 <mcatanzaro> I'm trying to find something more recent than October, no luck yet....
15:21:50 <cschalle_> ok, I will ask Wim to take another look at moving this forward
15:22:13 <mcatanzaro> Thanks, let's move on and revisit in say a month if things are still stalled.
15:22:46 <stickster> #action cschalle_ check in with Wim to move forward his flat-volume fixes upstream, and get estimate on upstreaming
15:22:49 <rdieter> here now, sorry I'm late
15:22:52 <stickster> #chair rdieter
15:22:52 <zodbot> Current chairs: cschalle_ kalev mcatanzaro mclasen otaylor rdieter stickster
15:22:55 <stickster> o/ rdieter
15:23:30 <stickster> #action mcatanzaro Remind stickster to put this on agenda four weeks out ;-) to revisit
15:23:54 <stickster> #topic Wayland - user marketing
15:24:01 <stickster> #link https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/thread/Q72GPITBCGZCYGPIESLUKNPXRRNSOLBG/
15:24:51 <stickster> So mattdm is looking for some assistance here on how to market Wayland to the masses.
15:25:09 <stickster> He named better HiDPI, multi-monitor support, shear-free playback
15:25:39 <stickster> Also better sandboxing, but honestly we need to explain that to users, too
15:25:58 <mattdm> I need stuff which will play with general tech journalists and the user base in general
15:26:08 <mclasen> this is the patch submission that the bug talks about: https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-December/025080.html
15:26:13 <mclasen> so, december, not october
15:26:27 <mattdm> Wayland-in-itself is exciting to a certain tech-enthusiast crowd, but not much beyond that
15:26:55 <mclasen> I don't think wayland has too much to be exited about for a general user
15:26:57 <stickster> mattdm: One of the general attributes AIUI is that Wayland's architecture makes it easier to support newer display cards
15:27:20 <stickster> ^ anyone who wants to correct me or clarify is more than welcome...
15:27:45 <otaylor> stickster: no, that's not really a thing as far as I can think of
15:27:57 <stickster> otaylor: ooooookay :-\  :-D
15:27:58 * jsmith is confused by that statement too...
15:28:04 <cschalle_> yeah, that list is sorta 'it', I mean there are general developer advantages to building on something which hasn't half a decade of warts included, but for a user that is a bit intangible
15:28:15 <mclasen> so, I'm not sure you want to market it to users; it is somewhat exciting for developers who want to play with new stuff
15:28:20 * stickster thinking way back to his first encounter with the idea, so easily could be wrong
15:29:02 <stickster> Any benefit for e.g. VM guests?
15:29:12 <cschalle_> I think what we need to focus the marketing on is what has been our main motivation for it, enabling us to greatly improve desktop security through sandboxed desktop applications
15:29:32 <stickster> cschalle_: That sandboxing could be better explained IMHO
15:29:41 <stickster> We shouldn't assume people know what that means to them.
15:29:49 <mcatanzaro> ...which we don't have yet, and we don't want to trick users into thinking Wayland creates some magical sandbox, but we do want to explain that it's a required first step.
15:29:55 * jsmith is also slightly worried about logging (or lack thereof) for people used to using Xorg.0.log for integration debugging
15:30:21 <cschalle_> stickster, no, but to be fair I think most peoples relationship with security is 'yes, I want more as long as it doesn't bother me', getting the actual 'more' explained is not something they truly care about
15:31:10 <cschalle_> there is of course a population of sysadmins who are on the opposite end of that scale
15:32:08 <stickster> cschalle_: True. There are probably two distinct audiences here, and we should have different info for each. (1) General users/devs -- yes, probably satisfied with "moar secure = moar better." (2) enthusiasts, et al. at places where our Ambassadors speak, for whom a more detailed talking point would be useful
15:32:08 <mattdm> So, all of this makes me lean strongly towards being _really_ conservative about making it the default
15:32:42 <mattdm> If the primary reason is sandboxing, and we don't have sandboxing ready, why enable it until then?
15:33:14 <kalev> I think a good reason to enable it by default would be to drive the technology forward
15:33:17 <jsmith> mattdm: The traditional argument for that would probably be "to make it more robust before the sandboxing is ready", but I tend to agree with you on this one
15:33:23 <kalev> so that app authors would have a reason to fix issues in their apps etc
15:33:45 <mclasen> there's no way to from A to B if you're not willing to make a first step
15:33:47 <cschalle_> mattdm, yeah, we don't want to create a chicken and egg situation here, where we hold of on a waiting for b and nobody does b because a isn't there yet
15:33:55 <stickster> #info Really the list that mattdm included is roughly all there is to say for general users
15:34:11 <mclasen> but this is not the dsicussion we're having right now, or is it (default go-no-go)
15:34:18 <mattdm> cschalle_: But we _are_ working on b, right?
15:34:37 <mattdm> mclasen: No, but I want this side (benefit to users) to be weighed as part of that decision
15:34:40 <stickster> mclasen: It's not, but we do need to make that call in a transparent way
15:34:46 <cschalle_> mattdm, 'we' are, but we need the wider universe to join us to succeed
15:34:58 <stickster> Alpha freeze = next Tue 2016-Mar-08
15:35:34 <cschalle_> but that said I am not in favour of making it the default for F24
15:35:40 <mattdm> cschalle_: does it need to be the default for that, or do we need to push hard on asking developers to enable it and work on it?
15:35:46 <mclasen> ok, so are we making the go/no-go decision today ?
15:35:58 <mattdm> that's probably a new #topic :)
15:36:50 <stickster> mclasen: It would have been smart for me to include that on the agenda... but with the freeze close, it would make sense to explicitly do it with enough of us paying attention (as we are in this meeting) rather than on list
15:36:55 <cschalle_> mattdm, I think it needs to be default as we can't just rely on natural enthusiasm, that said I want it to be rock solid when we do the switch which is why I want to delay making it default
15:37:10 <stickster> cschalle_: I agree with that.
15:37:28 <mclasen> yes, thats fine, we just need to be clear what we are discussing - the topic was "user marketing"
15:37:33 <stickster> mclasen: Agreed
15:37:48 <stickster> I don't think we have anything further on user marketing, though, so I'll #topic unless someone objects.
15:38:05 <mattdm> thanks stickster!
15:38:09 <stickster> #topic Wayland F24 default go/no-go
15:38:45 <stickster> #info stickster didn't put this on agenda but makes sense to discuss now so we're clear on what to do for Alpha freeze 2016-Mar-08
15:38:51 * mclasen will put a 'why wayland anyway ?' post on his todo list
15:39:20 <stickster> mclasen: That sounds super-useful
15:39:40 <stickster> #action mclasen blog on "why Wayland anyway?"
15:39:56 <stickster> #action stickster crib from aforementioned blog to write up talking point for Marketing/Ambassadors
15:40:08 <mcatanzaro> Well if cschalle thinks Wayland is not ready for F24, I don't think there's anything to discuss he? We just need to tell halfline to switch the default back.
15:40:23 <mclasen> well, he's not deciding by himself
15:40:29 <stickster> yeah, cschalle_'s not the boss of me
15:40:31 <stickster> Oh wait
15:40:42 <cschalle_> yeah, so in terms of the no go/go my take is that I want us to push to have a Wayland we believe is a working alternative, but hold of the default for one more release to make sure we don't do a botched rollout and stain the wayland name
15:40:46 <mclasen> so, here's my status update since last time:
15:40:51 <mattdm> mclasen thanks for that post!
15:41:11 <mclasen> - we got primary selection in (as a private protocol between gtk and mutter for now, while upstream discussion goes on)
15:41:16 <mcatanzaro> cschalle_: Is there anything wrong at this point that'd make you worry about a "botched rollout"?
15:41:17 <mclasen> - same for startup notification
15:41:19 <stickster> mattdm: ^^ note
15:41:33 <mclasen> - fixing key repeat issues today
15:41:43 <mattdm> stickster Am I noting primary selection? :)
15:41:45 <mattdm> In that case
15:41:47 <mattdm> mclasen++
15:41:47 <zodbot> mattdm: Karma for mclasen changed to 1 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:41:48 <stickster> mattdm: yup
15:41:53 <mcatanzaro> We were discussing blockers on the list a couple weeks ago, but it seems there's been good progress on most of them, and in fairness, the other issues only seem to affect a small minority of users (monitor rotation, a11y) who could just switch to X.
15:41:53 <cschalle_> mcatanzaro, well the main thing is that we have been unable to push a full wayland update in F23, so we haven't really had wide testing of what we think is a functional wayland
15:41:56 <stickster> What?!? only 1 karma? That's a crime
15:41:58 <stickster> mclasen++
15:41:58 <zodbot> stickster: Karma for mclasen changed to 2 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:42:02 <mattdm> (I knew already, but the ++ is well deserved!)
15:42:24 <mclasen> still not done with text protocol (for onscreen keyboard) and not much progress on a11y features
15:42:47 <mclasen> I've outlined what needs to happen for those in an upstream bug, but I haven't seen any action from the a11y side
15:42:49 <cschalle_> mcatanzaro, maybe I am being overly cautious, but I don't want to repeat the PulseAudio story with it taking years for PA to live down users initial negative experience with it
15:42:57 <mclasen> so, probably something I need to tag somebody with
15:43:01 <davidshea> would usability of wayland in the live install environment be a factor? because right now that doesn't work since anaconda uses consolehelper
15:43:23 <mclasen> in summary: good progress, but still some blockers remaining
15:43:30 <mcatanzaro> cschalle_, caution is definitely warranted here
15:44:20 <stickster> davidshea: presumably the live intall will be using Wayland if it's default, so yes, we need this on radar too... is that something we need Anaconda to address for F25 if we aim to go to Wayland by default then?
15:44:30 <mclasen> davidshea: wasn't anaconda supposed to be split into frontend and backend at some point ?
15:44:43 <stickster> I think that's underway for a bit now
15:44:46 <davidshea> mclasen: that is on the roadmap but unlikely to happen for 24
15:44:55 <mclasen> ok
15:45:21 <mclasen> in the short term, I don't think there should be an issue with running anaconda under X
15:45:53 <halfline> yea just put GDK_BACKEND=x11 in the environment when starting it
15:45:55 <mcatanzaro> Still if the worry is not being able to push "full Wayland" to F23, I bet mclasen's team could solve that if needed. We could risk a hopefully-uneventful mutter update in F23, gdk-wayland changes could be backported to 3.18....
15:46:25 <mclasen> we can't push full wayland to f23, no
15:46:37 <mcatanzaro> Nevermind then ;)
15:46:55 <mclasen> backporting mutter would maybe be doable
15:47:02 <mclasen> but backporting gtk would break the world
15:47:09 <stickster> yup, oof
15:47:15 <mclasen> not something we should do to happy f23 users
15:47:43 <mcatanzaro> mclasen: Nono, not all of gtk, can you backport just the changes in the gdk-wayland backend? (Or would it be too much effort?)
15:48:56 <stickster> So just to point to the most on-topic comment above: "<mclasen> in summary: good progress, but still some blockers remaining"
15:49:12 <mclasen> I don't think thats cleanly separable (e.g. the window sizing changes)
15:49:41 <mclasen> still lots of potential for extra breakage, and it won't get us any close towards addressing the remaining gaps
15:49:52 <mcatanzaro> OK
15:50:31 <stickster> #info mclasen advises some blockers remaining, specifically text proto for the onscreen keyboard, and accessibility features remain undone atm
15:50:42 <mclasen> the only thing one could do (but still not effort I really want to invest) is to do an opt-in copr
15:51:07 <mcatanzaro> Sounds like this is a no-go then
15:52:02 <cschalle_> +1 on the no-go
15:52:12 <mcatanzaro> cschalle_, you'll do some blog post about Fedora's "uncompromising quality" or something uplifting? :)
15:52:14 <stickster> mcatanzaro: yeah, pretty much... but hopefully strive for an F25 launch?
15:52:21 <stickster> nice, mcatanzaro  :-D
15:52:25 <cschalle_> mcatanzaro, yeah, plan to :)
15:52:28 <mattdm> mcatanzaro++
15:52:52 <stickster> But in seriousness, this does support mattdm's efforts (and messaging) around how well Fedora has done there of late
15:52:57 * stickster +1 on no-go
15:53:23 <cschalle_> I will also give NVidia a friendly kick in the posterior to see what progress they are making on Wayland support for their binary driver, which is a big plus to have ready when we go default
15:53:47 <mclasen> so, now we get to discuss user messaging around the no-go decision, I guess ?
15:54:09 <stickster> mclasen: did we previously promise an F24 default Wayland?
15:54:12 <mattdm> Seriously, this "we love wayland but we love our users even more" story gets good response from both press and public
15:54:25 <mcatanzaro> Pretty sure we previously promised an F23 default Wayland ;)
15:54:50 <stickster> we're good at promising
15:54:55 <mattdm> I think cschalle_'s line: "We want to have one whole release where we feel like it's ready to go before we make it the default" is good
15:54:58 <mclasen> can we at least enourage our users to try the wayland session anyway ?
15:55:03 <cschalle_> no we never, or at least I never, I always said we hoped to get there, but I always made it clear we would only switch default after having 1 release which was feature complete Wayland frist
15:55:11 <stickster> Also, at least we have offered the session for quite a while, and that is meaningful
15:55:21 <cschalle_> mclasen, +1
15:55:24 <stickster> mattdm++ on the "love users even more" bit
15:55:24 <zodbot> stickster: Karma for mattdm changed to 11 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:55:26 <mattdm> mclasen: yes, definitely. that's good messaging too.
15:55:33 <cschalle_> we should definetly make F24 the 'time to try Wayland' release
15:56:06 <stickster> mclasen: rdieter: kalev: just for sake of recording, are you guys +1 on no-go?
15:56:13 <stickster> otaylor: ^
15:56:47 <stickster> mclasen: Agreed, we should encourage users to try Wayland in our release PR
15:56:59 <rdieter> +1
15:57:17 <otaylor> +1 for no go - I don't see enough wins for users to force them to upgrade even if there are minor regressions
15:57:35 <mclasen> I'm -1; still want to push for addressing gaps for another week
15:57:54 <mclasen> I hope thats ok, seems the no camp has a secure majority anyway
15:58:06 <stickster> mclasen: I think if something radically changes by next week, we can certainly revisit
15:58:10 <mcatanzaro> I will abstain from officially voting, as WebKit isn't ready yet
15:58:25 <mcatanzaro> So +0
15:58:38 <kalev> I am +0 as well; I haven't been on rawhide for a while and don't have first hand experience to see how well it works
15:58:50 * mclasen keeps things interesting with a non-unanimous decision
15:59:04 <mclasen> lets see if phoronix makes up a story about my dissenting vote
15:59:04 <kalev> but revisiting this next week seems like a good idea
15:59:05 <cschalle_> and I am definetly +1 on trying to close the gaps, we can't say we have a fully functional Wayland session default or not if we don't
15:59:26 <kalev> I think we can push through a defaults change through the alpha freeze if needed, so even if we decide something after the freeze, it should be fine
15:59:47 <mclasen> stickster: by when do we need to revert the default session, Tuesday ?
15:59:56 <stickster> mclasen: Correct
15:59:57 <rdieter> I think it's clear, either the issues we decided to treat as blockers are fixed or they aren't.  or, we change the list of blockers
16:00:14 <stickster> rdieter: Well, technically, it means they're testable.
16:00:30 <stickster> But I don't see that happening in a week with a11y stuff, at the very least.
16:00:31 <rdieter> ok, testable, either way, it's not hard
16:00:41 * mclasen notes that the only things annotated as BLOCKER in the Wayland_features list are in the 'complete' column
16:00:47 <mcatanzaro> We didn't really have any conclusive vote on those blockers though, did we?
16:00:52 <kalev> mclasen: I think tuesday is too late, it needs to like be in bodhi a few days before the last stable push on Monday so that it's queued for stable by that time
16:00:59 <mclasen> the post-meeting discussion on more blockers wasn't transcribed into the wiki page
16:01:00 <kalev> OR get a freeze exception
16:01:04 <mcatanzaro> At least I don't remember any rush on the mailing list to vote
16:01:30 <stickster> mcatanzaro: The thing about on-list voting is, if people don't want to resolve the discussion, they don't have to vote :-)
16:02:02 <mclasen> and... we're just out of time to vote in the meeting again :-(
16:02:11 <mcatanzaro> Well we have to resolve our discussion two minutes ago, so....
16:02:15 <kalev> I think a valid approach is to leave the default unchanged for now. discuss this next wednesday in the Workstation WG meeting and then push an alpha freeze exception through with the defaults change
16:02:24 <mattdm> stickster: is there an #agreed on that vote total?
16:02:40 <stickster> mcatanzaro: Votes currently are +1: 3, -1: 1, +0: 2
16:02:40 <mcatanzaro> I think a freeze exception change is reasonable.
16:03:17 <mcatanzaro> adamw has a good quit message.
16:03:41 <stickster> #info Unresolved on Wayland 24 default (+11: 3, -1: 1, +0: 2)
16:04:03 <mattdm> stickster: the status quo should be "not default", right?
16:04:09 <mattdm> what does "unresolved" mean?
16:04:12 <stickster> mattdm: That's correct
16:04:18 <kalev> the status quo is wayland is default AFAIK
16:04:27 <mattdm> uh oh :)
16:04:33 <mcatanzaro> Let's vote on what the status quo is
16:04:38 <adamw> what's my quit message?
16:04:41 <mcatanzaro> Kidding! Let's continue next week.
16:04:42 <mattdm> ermagerd :)
16:04:50 <mcatanzaro> adamw: "Coyote finally caught me"
16:05:09 <stickster> kalev: no, that's what's in Rawhide now, but my position is we will not push out something non-ready just because it happened to be in Rawhide by default in advance
16:05:15 <cschalle_> so I think what is being said here, lets keep the default to Wayland in Rawhide for now, and then do a formal decision to stick with X as default next week
16:05:21 <kalev> I am pretty sure we'll have to go back to the X11 session next week, but I think it's reasonable to give it one more week
16:05:24 * kalev nods.
16:05:42 <stickster> #agreed We will resolve this fully next week, in addition to third-party content discussion
16:05:45 <mclasen> we're out of time, but we're only switching the default back in the f24 branch, right ?
16:05:47 <mcatanzaro> status quo is "WG does not force any change" -> Wayland remains default... for the next week, at least. ;)
16:05:53 <mclasen> wayland can stay as is
16:05:59 <stickster> mclasen: Yes -- no need to change anything in Rawhide, just F24 branch
16:06:13 <mcatanzaro> Yeah, this should only affect F24, rawhide can live on wayland forever I think....
16:06:19 <mclasen> ok
16:06:32 <stickster> #agreed, default can stay right now but we will be deciding next week on freeze exception to change back to X11, if needed
16:06:38 <mclasen> thats another piece of information for the messaging around no-go
16:06:42 <mattdm> agreed on rawhide, yes.
16:07:17 <stickster> OK, with that, I'm going to close up here in 20 sec
16:07:26 <mcatanzaro> Bye folks
16:07:27 <stickster> Sorry for going over, and thanks to all who showed up.
16:07:43 <cschalle_> ok ty
16:07:50 <stickster> #endmeeting