16:00:39 <jwb> #startmeeting
16:00:39 <zodbot> Meeting started Wed Jan  7 16:00:39 2015 UTC.  The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:39 <jwb> #meetingname workstation
16:00:39 <zodbot> The meeting name has been set to 'workstation'
16:00:40 <jwb> #meetingtopic Workstation WG meeting
16:00:40 <jwb> #topic init
16:00:40 <jwb> #chair rdieter cwickert otaylor mclasen cschalle ryanlerch stickster kalev
16:00:40 <zodbot> Current chairs: cschalle cwickert jwb kalev mclasen otaylor rdieter ryanlerch stickster
16:00:46 <jwb> HI
16:00:53 * rdieter waves
16:01:01 <kalev> hello!
16:01:32 <jwb> we'll give people a few seconds to wander in
16:01:45 <sgallagh> .hello sgallagh
16:01:47 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:03:15 * stickster here!
16:03:24 <jwb> stickster, oh good.  then you can roll with it
16:03:30 * mclasen here too
16:03:40 * jwb hands whip to stickster
16:05:05 <stickster> OK, let's get going, I see in the logs: kalev rdieter sgallagh jwb mclasen
16:05:05 * otaylor here
16:05:14 <stickster> Hi otaylor :-)
16:05:40 <stickster> #topic Change proposals
16:05:44 <stickster> #url https://fedoraproject.org/wiki/Changes/Policy
16:06:59 <stickster> Right now we have about two weeks left until the earliest possible Change deadline for F22. I looked through what I believe are the current wrangler-ready, FESCo-ready, and accepted list and don't see our stuff there yet.
16:07:04 <kalev> I could volunteer to file one change proposal for GNOME 3.16
16:07:19 <kalev> what else do we need?
16:07:47 <stickster> kalev: The relevant changes have {{check}} markings on the http://fedoraproject.org/wiki/Workstation/Tasklist page
16:08:07 <stickster> Those are the ones that mclasen and I figure need Changes filed.
16:08:17 <sgallagh> kalev: related to an ongoing discussion in #fedora-workstation: An unattended installation for Workstation would be a useful Change to track.
16:08:51 <stickster> sgallagh: True, but let's save that for later in the meeting, since we're still hashing that out
16:09:57 <sgallagh> I didn't intend to get into the details, just suggest that it was a trackable item
16:10:04 <stickster> *nod
16:11:02 <stickster> I wouldn't mind splitting up the filing of Change pages with a few people, can we do that?  mclasen has been doing all of these every release; since we're trying to do lots of disclosure, I'd like to involve several of us to give him a hand
16:11:23 <stickster> i.e. it may be more pages than usual, so it seems unfair to just keep heaping on one person
16:12:23 <stickster> otaylor: Could you file the one on battery monitoring?
16:13:13 <otaylor> stickster: Not entirely sure what the change there is that requires a change proposal
16:14:06 <otaylor> stickster: That is, it's probably a new optional package not installed by default
16:14:15 <drago01> well aren't the changes proposals used mostly for marketing?
16:14:30 <stickster> otaylor: IIRC mclasen and I thought there might be some piece of this that either (1) reports to user, or (2) asks user to report somewhere else. So it's dependent on what the monitoring does, and whether we can feature it in talk about F22 release
16:14:48 <jwb> drago01, no
16:14:53 <drago01> unless we run it and do improvements that we can say "better battery life"
16:15:17 <cschalle> or we will just get complaints about supporting non-free batteries ;)
16:15:31 * mclasen is just back from vacation today and hasn't gotten around to figuring out the status of the features that were earmarked for change pages
16:16:04 <otaylor> I could conceivably do a "better battery life" change proposal that includes the three points on the tasklist page - I think we'll have some mileage in the f22 time frame to talk about
16:16:24 <otaylor> (Not so sure about ambient light sensors - probably not)
16:16:33 <stickster> otaylor: That sounds good.
16:16:58 <drago01> otaylor: what's with the sensors?
16:17:06 <drago01> otaylor: the one in my old laptop "just works"
16:17:11 <stickster> kalev: I think we need one for GNOME 3.16 (usually we have one), so you could file that if mclasen is OK with one less todo :-)
16:17:16 * cwickert is sorry for being so late and inactive in general
16:17:25 <stickster> cwickert: Thanks for being here, welcome
16:17:35 <otaylor> drago01: If so, it's your laptop bios doing stuff behind GNOME's back
16:17:38 <otaylor> drago01: I don't think this is typical
16:17:44 <kalev> stickster: sure, happy to!
16:18:08 <otaylor> drago01: Few ambient backlight sensors are supported in the kernel, and the ones that are, gnome-settings-daemon's module doesn't do anything with
16:18:14 <drago01> otaylor: ok, well its the only laptop with a sensor that I had so I assumed they are expected to work "magically"
16:18:25 <stickster> mclasen: Can you plan to do the ones for nautilus and GNOME SHell?
16:18:39 <mclasen> I can
16:18:56 <otaylor> drago01: any investigation I've done is still in the early stages
16:19:23 <drago01> otaylor: ok
16:19:28 <stickster> There are at least three others that look important... (1) Software installer/webapps; (2) Live image writer revamp; (3) Fedora account integration
16:20:14 <stickster> (1) is probably more like a collection of new/improved capabilities in Software.
16:21:36 <stickster> kalev: Could you take that?
16:22:03 <kalev> stickster: sure
16:23:10 <stickster> (2) and (3) aren't well defined yet, does anyone know for example if (2) has been discussed at all with lmacken who makes the liveusb-creator we reference all over the place in Fedora already?
16:24:06 <cschalle> stickster, no concrete discussion with Luke yet, but having such a discussion is on the TODO :)
16:24:18 <lmacken> nope. But I think rhughest recently stepped up to the plate with regard to liveusbs recently ;)
16:24:22 <lmacken> *rhughes
16:24:35 <stickster> OK, makes sense. It's only a mockup so far afaict... I saw hughsie's recent multi-writer thing
16:24:52 <lmacken> the liveusb-creator can do dd now as well, so it should be on-par with our other methods
16:24:57 <sgallagh> Fedora Account Integration is something I'd like to be involved with (but I probably can't *own* the Change)
16:25:13 <lmacken> stickster: a mockup, 1k lines of code ;)
16:25:24 <stickster> sgallagh: Same here
16:25:49 <mcatanzaro> liveusd-creator **works on Windows** that is why it's useful to promote it; I doubt the new multi-writer does.
16:25:56 <stickster> Or... maybe I can?  I don't know until I know more about what people are considering to do there.
16:26:00 <stickster> mcatanzaro: Correct.
16:26:10 <mclasen> I don't think fedora account integration is likely to move forward for f22
16:26:40 <sgallagh> mcatanzaro: The new multi-writer does not. It's tightly tied to udisks, as I understand it
16:26:47 <mclasen> the multi-writer is not a solution to the same problem as liveusb-creator
16:27:03 <mclasen> not sure why it is even discussed in this context...
16:27:21 * lmacken was joking about hughsie being the new liveusb guy ;)
16:27:27 <stickster> mclasen: It's related, not the same. It came up because lmacken mentioned it :-)
16:27:39 <stickster> Would people agree the Live image writer is likely not going to be user-ready for F22?
16:28:12 <ryanlerch_> sorry, i'm here now
16:28:16 <ryanlerch_> network issues
16:28:22 <cschalle> stickster, sgallagh: rishi will own the change once we are ready to move on it, but any help in defining what that integration would do beyond ABRT support would be great and help justify the effort (in a F23 timeframe?)
16:28:22 <stickster> hola ryanlerch_
16:29:01 <sgallagh> cschalle: I'd be happy to help. I've been working on a couple things in that vein (like Ask Fedora integration)
16:29:21 <cschalle> stickster, no I think that should be doable, I mean it is there and works, it is not a lot of lines of code, and we just want to polish it up a bit before making it the primary download for Workstation
16:29:27 <stickster> sgallagh: cschalle: And I need to pay attention and contribute to that discussion too, count me in.
16:30:10 <stickster> cschalle: Wait, I don't understand -- ist he primary download for making a USB of Workstation something that only works on Fedora? That seems... odd
16:30:38 <stickster> or s/Fedora/Linux or maybe just GNOME/
16:30:42 <cschalle> stickster, no, the USB creator works on Windows and Mac, which is the thing that makes its interesting
16:30:59 <jwb> stickster, take hughsie's thing and throw it out of your brains
16:31:03 <jwb> we aren't talking about that
16:31:11 <stickster> cschalle: OK, sorry, I was misunderstanding -- I thought you were talking about https://github.com/gnome-design-team/gnome-mockups/blob/master/USB-boot-creator/usb-boot-creator.png
16:31:14 <cschalle> currently our primary download is an ISO, and my thinking is that the USB creator probably is a nicer pathway
16:31:43 <stickster> jwb: Thanks. cschalle: Yeah, I get it -- thanks for clarifying, and agreed.
16:31:43 <ryanlerch_> cschalle, would the download of the USB creator inlcude the ISO? or is the idea that it is downloaded after, when the app is run?
16:31:51 <cschalle> stickster, I think those mockups where meant as ideas for how we could streamline the usb-creator UI
16:32:03 <cschalle> ryanlerch_, the USB creator contains its own downloader
16:32:17 * stickster gets it now.
16:33:39 <stickster> cschalle: Who owns the Live image bit?
16:33:54 * stickster wants to get out of this "Who owns the Change" morass so we can get to more interesting things on the agenda.
16:34:22 <cschalle> stickster, sorry, not fully understanding your question. Do you mean who owns solving the issue of live image with Boxes?
16:34:33 <lmacken> stickster:  Martin Briza/Jakub Steiner are listed as the owners on the tasklist
16:35:17 <stickster> cschalle: I was referring to the liveusb-creator polish
16:35:33 <cschalle> stickster, lmacken already provided the answer :)
16:36:14 <stickster> I don't know if mbriza is filing a Change for this, though. It sounds like this is *not* really eligible, because it's just a polish + maybe some website content realignment
16:36:22 <cschalle> the effort has partly been blocking on mbriza finishing up the Adwaita for Qt theme first
16:36:40 <stickster> #info kalev filing Change for GNOME 3.16 + Software capabilities
16:36:53 <stickster> #info mclasen filing Changes for nautilus + gnome-shell
16:37:10 <stickster> #info otaylor filing Change for improved battery life
16:37:22 <stickster> #proposed Drop liveusb-creator as Changeworthy
16:38:03 <stickster> #info sgallagh + stickster to join discussion with rishi, cschalle, et al. on Fedora account integration scope and see what is F22 vs. F23 doable
16:38:59 <stickster> #action stickster to note above to WG on list, and get input on proposed so we can move on in this meeting :-)
16:39:35 <stickster> mclasen: The next two items were on status upstream, but I'm guessing you really didn't have a chance to follow up on them yet... app bundles, and upgrade notifications UI mockup
16:39:46 <mclasen> yeah, sorry
16:39:59 <mclasen> I just pinged aday about the upgrade notification mockup
16:40:02 <mclasen> he's on it now
16:40:29 <stickster> mclasen: It's OK, understandable given timing.
16:40:39 <stickster> #topic App bundles upstream status
16:40:54 <stickster> mclasen: Do you want to get back to us on list about this later this week?
16:41:09 <mclasen> sure, will do
16:41:15 <stickster> That gives you some time to recover from vacation :-)
16:41:31 <stickster> #action mclasen to follow up on list later in the week
16:41:38 <stickster> #topic Upgrade notification UI mockup
16:42:03 <mclasen> as I said, I pinged aday this morning, he's on it now
16:42:13 <stickster> #action mclasen following up with aday, we should hear back on list shortly
16:42:26 * stickster just doing the agenda dance, moving on... :-)
16:42:48 <stickster> #topic Bug triage
16:43:42 <stickster> ryanlerch_: You raised this on the list a while ago and I don't think we got to a consensus about what we can do with BZ input that is in Workstation's wheelhouse
16:44:18 <stickster> We might be able to pull some idea of impact from https://retrace.fedoraproject.org
16:46:21 <stickster> ryanlerch_: Did you want to offer a summary/proposal here?
16:47:37 * stickster wonders whether network has killed Ryan again
16:47:38 <ryanlerch_> stickster, yeah, i was sort of approaching it from a user point of view -- where should users file bugs? in Fedora or the upstreams?
16:47:44 <mcatanzaro> I think the long-term plan should either be to automatically forward GNOME bugs upstream, or else not accept bug reports for GNOME packages at all (and have a single Workstation component against which to report packaging bugs and request backports).
16:48:28 <mcatanzaro> Right now, rbz is a black hole for GNOME bugs. It's not good for users, Fedora developers, or GNOME developers.
16:49:11 <cschalle> yeah, on the other hand people are not installing GNOME, glibc, X.org, the linux kernel etc., they are installing Fedora. And asking users to register with random upstream projects to file bugs seems inherently wrong to me
16:49:11 <mcatanzaro> Users because their bugs get ignored, Fedora developers because holy heck 900 bugs assigned to one person?, GNOME developers because they don't get to see downstream reports.  /$0.02
16:49:14 <ryanlerch_> mcatanzaro, the issue i have here is who makes the decision that it is a packaging bug or not
16:49:15 <drago01> well evertime this comes up it boils down to "can't ask users to have 1000 bz accounts"
16:49:29 <drago01> (which is fair)
16:49:32 <stickster> I think non-package specific stuff could -> Workstation Trac (easier to use and more for Workstation specific issues)
16:49:52 <drago01> so unless the bz instances can somehow talk to eachother its a lost cause
16:50:22 <mcatanzaro> drago01: I think for huge projects like GNOME and KDE, it is reasonable to expect bugs to be filed upstream. Your entire desktop is developed by them.
16:50:59 <drago01> mcatanzaro: I downloaded fedora ... what is gnome? what is kde?
16:51:08 <cschalle> to me the value of the fedora bugzilla and where we try to do fixes is due to its link to retrace.fedoraproject.org
16:51:12 <mcatanzaro> And it's one additional Bugzilla account for ~300 packages.
16:51:24 <stickster> mcatanzaro: ryanlerch_: could we use the retrace server reports to identify at least the top-impact bugs and make sure they are cross-filed in GNOME, and linked in the BZs?
16:51:24 <cschalle> to be fair even upstream bugzillas tend to be black holes to some extent
16:51:39 <ryanlerch_> yeah, the user shouldnt have to care about filing stuff upstream, TBH
16:51:40 <rdieter> most upstream bz's don't allow anonymous submissions either
16:51:46 <drago01> cschalle: well there are more people filing bugs then people fixing them so ...
16:53:03 <cschalle> drago01, yeah, not pointing any fingers, but my general take is that the problem isn't really which bugzilla people file into, its providing developers with prioritization tools so they can optimize they limited time they do have available, which is why I love the retrace server
16:53:33 <drago01> *nod*
16:53:41 <rdieter> given retrace and bz data, however, it's easy to identify hotspots worth additional attention, I think that is some low-hanging fruit worth hitting first
16:54:03 <rdieter> (unless that is already being done)
16:54:05 <ryanlerch_> i'm willing to start helping triage some of the bugs against packages for workstation, but would love some guidance from those package owners on how to best clean out the queues...
16:54:15 <mcatanzaro> I don't think this has to be a general "start filing bugs in random upstream bugzillas," I'm suggesting we treat GNOME specially.  Using the retrace server to identify top-impact bugs is a good idea and we should do it, but doesn't solve the "rbz is a black hole" problem. GNOME Bugzilla is not as bad as rbz; when the bug reaches GNOME Bugzilla, at least the developers know about the bug, if it's on rbz then the bug simply does not
16:54:17 <mcatanzaro> exist as far as upstream is concerned.
16:54:28 <stickster> From the user POV: we have a page http://fedoraproject.org/wiki/How_to_file_a_bug_report (and some associated pages) and it sounds like we should have some guidance there for users that gets them to the upstream GNOME BZ. But I still think we should have some approach that lets us help upstream prioritize by telling them "Hey, we have 100s of people reporting issue #___"
16:54:29 <ryanlerch_> there are a lot of bugs open and new there
16:55:34 <ryanlerch_> both abrt/retrace ones, and not
16:55:52 <stickster> We do have to be careful about not sending uninformed users to $DE BZ, and mucking it up with all sorts of $DE-unrelated bugs
16:56:30 <mcatanzaro> stickster: I agree on all points.  ryanlerch_: There are way too many bugs, I'm not sure it'd be worth your time.
16:56:37 <rdieter> it's also hard, but prioritizing *good* bug reports is also relatively low-hanging fruit too.  (bad reports are often low value, may not be worth anyone's time)
16:57:09 <cschalle> do we ever get patches in fdo bugzilla?
16:57:10 <stickster> ryanlerch_: Staying with the user POV for a moment... this might also be a call for figuring out how to help people *within* the Workstation interface file a bug or locate the right place to do it. This is orthogonal to the retrace stuff.
16:57:30 <mclasen> from a developer perspective, rh bz is so painful that it is not even worth triaging those bugs, sadly
16:58:48 <halfline> i don't think bugzilla is a tool for users really at all
16:58:53 <ryanlerch_> the story here for the user is pretty bleak, IMHO. they take the time to file a bug, and never get a response
16:59:03 <halfline> if you're filing a bug, that bug is a contribution to the community
16:59:21 <ryanlerch_> halfline, what is the alternative then though?
16:59:31 <halfline> alternative for what?
16:59:35 <halfline> getting support ?
16:59:36 <rdieter> ryanlerch_: most bugs filed aren't very good
16:59:43 <ryanlerch_> if BZ is not for users
16:59:45 <stickster> We're running out of time in this meeting, but it sounds like we have a couple ideas fermenting already. (1) Figure out a way to triage a limited # of BZs based on retrace; (2) Figure out whether we can help users report Workstation bugs in a more upstream-effective way
16:59:59 <stickster> ryanlerch_: I haven't reached your additional item about wallpaper, *again*
17:00:05 <halfline> ryanlerch_: right, i don't think bz is for users
17:00:06 <otaylor> I tend to think that the basic problem here is resourcing - it simply takes a lot of time to process bugs even in a default (not way backlogged) state
17:00:19 <ryanlerch_> halfline, so how do users report issues?
17:01:28 <halfline> ryanlerch_: to what end?
17:01:35 <otaylor> ryanlerch_: we only need as many issues reported as we have resources to fix - to be blunt - so the goal is to get a limited number of high quality bugs of high priority - not every bug a user might have an itch to file
17:01:43 <rdieter> unforuntately, fedora doesn't have much in the way of first-level support, to weed out the good vs the bad
17:01:56 <stickster> otaylor: That really argues for the retrace connection as cschalle was saying above
17:02:27 <stickster> rdieter: The bugzappers idea never really took off... well, it was active for a while but not really coherent, and it fell apart pretty quickly ISTR
17:02:30 <halfline> ryanlerch_: what i'm saying is, bugzilla is for fedora, not for fedora users
17:02:32 <ryanlerch_> otaylor, i understand that, but users are filing issues, and then wonder why they dont even get a reponse, and they are just left open
17:02:40 <otaylor> ryanlerch_: Yeah, that totally sucks
17:02:48 <halfline> ryanlerch_: okay right, so we need to get way better messaging
17:02:59 <jwb> ryanlerch_, we have that problem in the kernel a lot too.  it's still a resource issue
17:03:01 <rdieter> stickster: <nod>, it was too hard, triaging *everything* is not the best use of everyones time (at the moment)
17:03:14 <stickster> ryanlerch_: otaylor: halfline: Or some way of the user sending in bugs that makes it (1) less work; and (2) less implied commitment about response
17:03:25 <otaylor> ryanlerch_: what I'm most confused about is what to do with UI suggestions- which is a large fraction of RH bugzila bugs (for gnome shell/mutter at least)
17:03:28 <stickster> BZ *implies* response commitment because it's a discussion engine as well.
17:03:58 <rdieter> stickster: may be unpopular, but honestly, I think reporting bugs needs to be *harder* (in general)
17:04:01 <stickster> If we abstract that part away somehow it might look more like e.g. Android crash reporting, where I have no idea where it goes and don't expect to hear back from anywhere.
17:04:04 <mclasen> unfortunately, there is often no good way to close a bug...which is one reason why we just let them time out
17:04:04 <stickster> rdieter: ^
17:04:12 <stickster> er, anyone
17:04:27 <stickster> So we are running overtime here, and I think some of us are due in another meeting.
17:04:31 <rdieter> set the bar higher, increase quality
17:04:42 <rdieter> low quality reports kills kittens
17:04:50 <halfline> i think making it easier to file bugs is a good thing, but we need to make it clear that filing bugs is a way of participating in the community, and not a way to get end-user support for the product
17:05:02 <stickster> ryanlerch_: Can I ask you to summarize this discussion to the list so we can continue there, and/or in #fedora-workstation?
17:05:03 <ryanlerch_> also, i fear by nmot looking at these bugs, we are missing valuable feedback on what issues the users are actaully having
17:05:09 <stickster> +1
17:05:14 * mclasen drops off
17:05:20 <stickster> I have to do what mclasen just did
17:05:55 <stickster> But this is a really useful topic and I want to bring it back for next meeting along with Ryan's wallpaper idea (wp first!)
17:06:19 <stickster> #action stickster bring wallpaper topic and bug topic to next agenda
17:06:33 <mclasen> can you also put the unattended install issue on the next agenda, please ?
17:07:26 <stickster> #action stickster add unattended install issue to next agenda, re: https://bugzilla.redhat.com/show_bug.cgi?id=1178787
17:07:59 <stickster> OK, thanks for attending, everyone, and sorry for the sluggish start. Next meeting in two weeks will be more energetic. :-)
17:08:03 <stickster> #endmeeting