16:00:39 #startmeeting 16:00:39 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:39 #meetingname workstation 16:00:39 The meeting name has been set to 'workstation' 16:00:40 #meetingtopic Workstation WG meeting 16:00:40 #topic init 16:00:40 #chair rdieter cwickert otaylor mclasen cschalle ryanlerch stickster kalev 16:00:40 Current chairs: cschalle cwickert jwb kalev mclasen otaylor rdieter ryanlerch stickster 16:00:46 HI 16:00:53 * rdieter waves 16:01:01 hello! 16:01:32 we'll give people a few seconds to wander in 16:01:45 .hello sgallagh 16:01:47 sgallagh: sgallagh 'Stephen Gallagher' 16:03:15 * stickster here! 16:03:24 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 OK, let's get going, I see in the logs: kalev rdieter sgallagh jwb mclasen 16:05:05 * otaylor here 16:05:14 Hi otaylor :-) 16:05:40 #topic Change proposals 16:05:44 #url https://fedoraproject.org/wiki/Changes/Policy 16:06:59 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 I could volunteer to file one change proposal for GNOME 3.16 16:07:19 what else do we need? 16:07:47 kalev: The relevant changes have {{check}} markings on the http://fedoraproject.org/wiki/Workstation/Tasklist page 16:08:07 Those are the ones that mclasen and I figure need Changes filed. 16:08:17 kalev: related to an ongoing discussion in #fedora-workstation: An unattended installation for Workstation would be a useful Change to track. 16:08:51 sgallagh: True, but let's save that for later in the meeting, since we're still hashing that out 16:09:57 I didn't intend to get into the details, just suggest that it was a trackable item 16:10:04 *nod 16:11:02 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 i.e. it may be more pages than usual, so it seems unfair to just keep heaping on one person 16:12:23 otaylor: Could you file the one on battery monitoring? 16:13:13 stickster: Not entirely sure what the change there is that requires a change proposal 16:14:06 stickster: That is, it's probably a new optional package not installed by default 16:14:15 well aren't the changes proposals used mostly for marketing? 16:14:30 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 drago01, no 16:14:53 unless we run it and do improvements that we can say "better battery life" 16:15:17 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 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 (Not so sure about ambient light sensors - probably not) 16:16:33 otaylor: That sounds good. 16:16:58 otaylor: what's with the sensors? 16:17:06 otaylor: the one in my old laptop "just works" 16:17:11 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 cwickert: Thanks for being here, welcome 16:17:35 drago01: If so, it's your laptop bios doing stuff behind GNOME's back 16:17:38 drago01: I don't think this is typical 16:17:44 stickster: sure, happy to! 16:18:08 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 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 mclasen: Can you plan to do the ones for nautilus and GNOME SHell? 16:18:39 I can 16:18:56 drago01: any investigation I've done is still in the early stages 16:19:23 otaylor: ok 16:19:28 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 (1) is probably more like a collection of new/improved capabilities in Software. 16:21:36 kalev: Could you take that? 16:22:03 stickster: sure 16:23:10 (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 stickster, no concrete discussion with Luke yet, but having such a discussion is on the TODO :) 16:24:18 nope. But I think rhughest recently stepped up to the plate with regard to liveusbs recently ;) 16:24:22 *rhughes 16:24:35 OK, makes sense. It's only a mockup so far afaict... I saw hughsie's recent multi-writer thing 16:24:52 the liveusb-creator can do dd now as well, so it should be on-par with our other methods 16:24:57 Fedora Account Integration is something I'd like to be involved with (but I probably can't *own* the Change) 16:25:13 stickster: a mockup, 1k lines of code ;) 16:25:24 sgallagh: Same here 16:25:49 liveusd-creator **works on Windows** that is why it's useful to promote it; I doubt the new multi-writer does. 16:25:56 Or... maybe I can? I don't know until I know more about what people are considering to do there. 16:26:00 mcatanzaro: Correct. 16:26:10 I don't think fedora account integration is likely to move forward for f22 16:26:40 mcatanzaro: The new multi-writer does not. It's tightly tied to udisks, as I understand it 16:26:47 the multi-writer is not a solution to the same problem as liveusb-creator 16:27:03 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 mclasen: It's related, not the same. It came up because lmacken mentioned it :-) 16:27:39 Would people agree the Live image writer is likely not going to be user-ready for F22? 16:28:12 sorry, i'm here now 16:28:16 network issues 16:28:22 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 hola ryanlerch_ 16:29:01 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 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 sgallagh: cschalle: And I need to pay attention and contribute to that discussion too, count me in. 16:30:10 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 or s/Fedora/Linux or maybe just GNOME/ 16:30:42 stickster, no, the USB creator works on Windows and Mac, which is the thing that makes its interesting 16:30:59 stickster, take hughsie's thing and throw it out of your brains 16:31:03 we aren't talking about that 16:31:11 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 currently our primary download is an ISO, and my thinking is that the USB creator probably is a nicer pathway 16:31:43 jwb: Thanks. cschalle: Yeah, I get it -- thanks for clarifying, and agreed. 16:31:43 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 stickster, I think those mockups where meant as ideas for how we could streamline the usb-creator UI 16:32:03 ryanlerch_, the USB creator contains its own downloader 16:32:17 * stickster gets it now. 16:33:39 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 stickster, sorry, not fully understanding your question. Do you mean who owns solving the issue of live image with Boxes? 16:34:33 stickster: Martin Briza/Jakub Steiner are listed as the owners on the tasklist 16:35:17 cschalle: I was referring to the liveusb-creator polish 16:35:33 stickster, lmacken already provided the answer :) 16:36:14 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 the effort has partly been blocking on mbriza finishing up the Adwaita for Qt theme first 16:36:40 #info kalev filing Change for GNOME 3.16 + Software capabilities 16:36:53 #info mclasen filing Changes for nautilus + gnome-shell 16:37:10 #info otaylor filing Change for improved battery life 16:37:22 #proposed Drop liveusb-creator as Changeworthy 16:38:03 #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 #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 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 yeah, sorry 16:39:59 I just pinged aday about the upgrade notification mockup 16:40:02 he's on it now 16:40:29 mclasen: It's OK, understandable given timing. 16:40:39 #topic App bundles upstream status 16:40:54 mclasen: Do you want to get back to us on list about this later this week? 16:41:09 sure, will do 16:41:15 That gives you some time to recover from vacation :-) 16:41:31 #action mclasen to follow up on list later in the week 16:41:38 #topic Upgrade notification UI mockup 16:42:03 as I said, I pinged aday this morning, he's on it now 16:42:13 #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 #topic Bug triage 16:43:42 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 We might be able to pull some idea of impact from https://retrace.fedoraproject.org 16:46:21 ryanlerch_: Did you want to offer a summary/proposal here? 16:47:37 * stickster wonders whether network has killed Ryan again 16:47:38 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 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 Right now, rbz is a black hole for GNOME bugs. It's not good for users, Fedora developers, or GNOME developers. 16:49:11 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 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 mcatanzaro, the issue i have here is who makes the decision that it is a packaging bug or not 16:49:15 well evertime this comes up it boils down to "can't ask users to have 1000 bz accounts" 16:49:29 (which is fair) 16:49:32 I think non-package specific stuff could -> Workstation Trac (easier to use and more for Workstation specific issues) 16:49:52 so unless the bz instances can somehow talk to eachother its a lost cause 16:50:22 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 mcatanzaro: I downloaded fedora ... what is gnome? what is kde? 16:51:08 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 And it's one additional Bugzilla account for ~300 packages. 16:51:24 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 to be fair even upstream bugzillas tend to be black holes to some extent 16:51:39 yeah, the user shouldnt have to care about filing stuff upstream, TBH 16:51:40 most upstream bz's don't allow anonymous submissions either 16:51:46 cschalle: well there are more people filing bugs then people fixing them so ... 16:53:03 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 *nod* 16:53:41 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 (unless that is already being done) 16:54:05 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 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 exist as far as upstream is concerned. 16:54:28 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 there are a lot of bugs open and new there 16:55:34 both abrt/retrace ones, and not 16:55:52 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 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 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 do we ever get patches in fdo bugzilla? 16:57:10 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 from a developer perspective, rh bz is so painful that it is not even worth triaging those bugs, sadly 16:58:48 i don't think bugzilla is a tool for users really at all 16:58:53 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 if you're filing a bug, that bug is a contribution to the community 16:59:21 halfline, what is the alternative then though? 16:59:31 alternative for what? 16:59:35 getting support ? 16:59:36 ryanlerch_: most bugs filed aren't very good 16:59:43 if BZ is not for users 16:59:45 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 ryanlerch_: I haven't reached your additional item about wallpaper, *again* 17:00:05 ryanlerch_: right, i don't think bz is for users 17:00:06 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 halfline, so how do users report issues? 17:01:28 ryanlerch_: to what end? 17:01:35 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 unforuntately, fedora doesn't have much in the way of first-level support, to weed out the good vs the bad 17:01:56 otaylor: That really argues for the retrace connection as cschalle was saying above 17:02:27 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 ryanlerch_: what i'm saying is, bugzilla is for fedora, not for fedora users 17:02:32 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 ryanlerch_: Yeah, that totally sucks 17:02:48 ryanlerch_: okay right, so we need to get way better messaging 17:02:59 ryanlerch_, we have that problem in the kernel a lot too. it's still a resource issue 17:03:01 stickster: , it was too hard, triaging *everything* is not the best use of everyones time (at the moment) 17:03:14 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 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 BZ *implies* response commitment because it's a discussion engine as well. 17:03:58 stickster: may be unpopular, but honestly, I think reporting bugs needs to be *harder* (in general) 17:04:01 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 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 rdieter: ^ 17:04:12 er, anyone 17:04:27 So we are running overtime here, and I think some of us are due in another meeting. 17:04:31 set the bar higher, increase quality 17:04:42 low quality reports kills kittens 17:04:50 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 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 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 +1 17:05:14 * mclasen drops off 17:05:20 I have to do what mclasen just did 17:05:55 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 #action stickster bring wallpaper topic and bug topic to next agenda 17:06:33 can you also put the unattended install issue on the next agenda, please ? 17:07:26 #action stickster add unattended install issue to next agenda, re: https://bugzilla.redhat.com/show_bug.cgi?id=1178787 17:07:59 OK, thanks for attending, everyone, and sorry for the sluggish start. Next meeting in two weeks will be more energetic. :-) 17:08:03 #endmeeting