15:02:17 #startmeeting Prioritized_bugs_and_issues 15:02:17 Meeting started Wed Nov 30 15:02:17 2016 UTC. The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:17 The meeting name has been set to 'prioritized_bugs_and_issues' 15:02:25 #meetingname Fedora Prioritized bugs and issues 15:02:25 The meeting name has been set to 'fedora_prioritized_bugs_and_issues' 15:02:30 #topic Roll Call 15:02:37 .hello jkurik 15:02:38 jkurik: jkurik 'Jan Kurik' 15:02:38 .hello sgallagh 15:02:40 sgallagh: sgallagh 'Stephen Gallagher' 15:03:01 #chair jkurik mattdm mcatanzaro dustymabe sgallagh 15:03:01 Current chairs: dustymabe jkurik mattdm mcatanzaro sgallagh 15:03:04 I heard from mattdm that he is sick today, so we shouldn't expect him. 15:03:18 Yes, I read his email 15:04:25 dustymabe will be late as he has a meeting conflict 15:06:03 hopefully mcatanzaro will join us soon 15:06:31 is there anyone else who is interesting to join us for the "Prioritized bugs" meeting ? 15:07:17 jkurik, not sure of the scope but sure 15:07:21 .fas linuxmodder 15:07:22 linuxmodder: linuxmodder 'Corey W Sheldon' 15:07:39 hi linuxmodder and thanks 15:07:47 #topic Purpose of this meeting 15:07:53 #info The purpose of this process is to help with processing backlog of bugs and issues found during the development, verification and use of Fedora distribution. 15:07:58 #info The main goal is to raise visibility of bugs and issues to help contributors focus on the most important issues. 15:08:03 #link https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process?rd=Fedora_Program_Management/Important_bugs_and_issues_process 15:08:11 jkurik, so what component or more of a meta bug prioritization? 15:08:11 #topic Setup of the Evaluation team 15:08:35 so more like an easy fix in infra ? (reading link still ) 15:09:31 not exactly "easy fix". it should be more like what anoys users the most, or what has big impact on users 15:09:34 linuxmodder: No, this is more like "These bugs are serious but don't actually hit blocker criterion" 15:10:17 ah I'd be down for helping in that 15:10:19 It's basically meant to be a list of bugs whose fixes have very high value and therefore would be really nice to prioritize. 15:10:26 not the docs part tho not enough cycles 15:11:36 At first we need to agree on the team who will perform the evaluation of proposed bugs. 15:12:05 My proposal is to have representatives from Working Groups 15:12:36 so I was thinking of these people: jkurik mattdm mcatanzaro dustymabe sgallagh 15:12:58 me and mattdm are to WG representatives, but we will be running this show :) 15:13:05 jkurik: A strong argument could be made that this is directly under FESCo's charter, if they wanted to own it. 15:13:09 s/to/not/ 15:13:34 sgallagh: good point 15:13:42 I'm hardly active enough atm from the server WG but don't mind giving testing cycles or input from that angle 15:14:15 I might open a FESCo ticket to discuss this on a FESCo meeting 15:14:23 I'd like for us to go for a "consensus of people who show up" approach unless that turns out to not work. 15:14:36 +1 ^ 15:15:40 ok, so it is basicaly the same as for Blocker Review 15:15:57 We need to be careful that this doesn't lead to everyone's pet bug getting treated as urgent, and therefore the list stops being useful. 15:16:01 jkurik, only makes sense 15:16:35 So I think I'd actually like to suggest that any -1 vote triggers a discussion followed by a rejection if that person remains unconvinced after a reasonable time. 15:16:43 I have no problem with this, as for Blocker Bugs this seems to work 15:16:46 sgallagh, bi-weekly or monthly ML announce or poll of some sort across all aspects maybe? 15:17:17 linuxmodder: I'm not sure that follows. 15:17:21 so its not just those that show or stumble on the group 15:17:29 What I'm getting at is this: the list will only be useful as long as it is *short8 15:17:57 ah yeah that makes sense 15:18:20 currently we have 4 bugs nominated 15:18:23 i.e. no component should end up with 30 high-prio bugs. 15:18:44 s/i.e./e.g./ (Wrong usage there) 15:19:16 So from my perspective, giving literally anyone who shows up the right to veto its inclusion on the list makes sense. 15:19:42 It allows anyone with a strong conviction to keep our limited resources reined in to what is truly important 15:20:43 proposed #agreed The Evaluation team is not going to be fixed as proposed in the current process description. All the people showing up during the Evaluation meeting will have their voice. 15:20:44 I guess what I'm getting at is that I don't want this to be a "wish-list", I want it to be a "to-do list" 15:21:20 does it make sense if I change the process description as above ^^^ ? 15:21:39 jkurik: I think that's compatible with what I'm proposing 15:22:33 jkurik, I'm cool with the agreed proposal as athe going charter 15:22:40 #agreed The Evaluation team is not going to be fixed as proposed in the current process description. All the people showing up during the Evaluation meeting will have their voice instead. 15:22:44 ok, thanks :) 15:23:00 #action jkurik do change the process description as agreed 15:23:50 we have the evaluation team now, so we can start with the evaluation 15:24:21 #topic Evaluation of proposed bugs 15:24:28 #link https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&list_id=6795225&namedcmd=FedoraPrioritized_Nomination&remaction=run&sharer_id=352756 15:24:45 this is the list of currently nominated bugs ^^^ 15:25:07 Our task is to go through all the nominated bugs and decide whether we will approve it for the Prioritized list or not 15:25:22 lets start with the first one 15:25:39 .bug 1341829 15:25:39 jkurik: Bug 1341829 – Systemd-coredump doesn't save any core files - https://bugzilla.redhat.com/1341829 15:25:45 #topic Bug 1341829 – Systemd-coredump doesn't save any core files 15:26:03 The general criteria should be something like: "Failure to resolve this bug will result in unpleasantness for a subjectively large subset of users" 15:27:49 Whee, starting with a tough one. 15:28:15 sgallagh: I can add the criteria to the process description, thanks 15:28:35 Core dumps are a developer feature. Also, ABRT as far as I know also handles core dumps just fine. 15:28:37 hey guys. sorry have been in a grooming meeting 15:28:49 dustymabe: Hi 15:28:52 So from a *user* perspective, I'd lean towards -1 on this. 15:29:19 dustymabe: we have already started with evaluation of bugs 15:29:57 From reading the comments, it seems likely that this will end up fixed as a dependency of other changes in Fedora Workstation, so I don't think we need to call it out as requiring attention. 15:30:04 my only concern is Michael's comment https://bugzilla.redhat.com/show_bug.cgi?id=1341829#c21 15:30:14 So I'm going to go with -1 15:30:41 jkurik: As Paul replied later: that approach isn't permissible 15:30:49 right 15:30:58 so I am -1 then as well 15:31:09 So if that's a priority Workstation feature, it'll be fixed for that reason. 15:31:18 I'm with sgallagh on that seems its getting needed attention 15:31:24 -1 15:31:58 ok, so we have -3; dustymabe would you comment on this bug as well ? 15:32:12 jkurik: playing catch up 15:32:16 i'll skip this one 15:32:24 ok 15:32:27 (jkurik, are you doing secretary work today?) 15:32:42 sgallagh: yes, I will do it after the meeting 15:33:10 Proposed: #agreed It seems likely that this will end up fixed as a dependency of other changes in Fedora Workstation, so I don't think we need to call it out as requiring special attention 15:33:24 ack 15:33:26 sgallagh: thanks, you are faster then me :) 15:33:27 ack 15:33:40 err, patch 15:33:45 Proposed: #agreed It seems likely that this will end up fixed as a dependency of other changes in Fedora Workstation, so we don't think we need to call it out as requiring special attention 15:33:47 s/I/we/ 15:34:15 ack anyway :) 15:34:25 ack on edit 15:34:33 #agreed It seems likely that this will end up fixed as a dependency of other changes in Fedora Workstation, so we don't think we need to call it out as requiring special attention 15:34:58 moving on... 15:35:04 .bug 1366897 15:35:05 jkurik: Bug 1366897 – Many apps crash in gdk_event_source_check when logging out of GNOME - https://bugzilla.redhat.com/1366897 15:35:08 #topic Bug 1366897 – Many apps crash in gdk_event_source_check when logging out of GNOME 15:35:51 This one is actually bordering on a blocker, IMHO 15:36:27 (Not quite crossing it, but you can definitely see the blockers from here) 15:36:30 +1 15:37:11 reading the bug, it seems to be complex, so it will need an attention 15:37:16 +1 15:38:14 i'm +1 15:38:37 +1 especially with the successive boot issue 15:39:13 no longer seems as simple as the d/s reversal of patch 22 gad 15:40:25 Proposed: #agreed This issue is complex and subtle and will impact the vast majority of Fedora GNOME users to at least some extent. 15:40:53 gnome@wayland imo not all gnome but otherwise ack 15:41:10 OK, patch 15:41:31 Proposed: #agreed This issue is complex and subtle and will impact the vast majority of Fedora GNOME Wayland session users to at least some extent. 15:41:46 ack 15:41:49 ack 15:42:13 as it seems on 25 gnome@x11 was absent this the other day when I tried testign other things 15:42:15 dustymabe: Phrasing look good to you? 15:43:01 #agreed This issue is complex and subtle and will impact the vast majority of Fedora GNOME Wayland session users to at least some extent. 15:43:08 ack 15:43:15 sgallagh: sorry, didn't realize I needed to do that 15:43:22 .bug 1389885 15:43:22 jkurik: Bug 1389885 – gnome-shell freeze when holding F11 key in gnome-terminal - https://bugzilla.redhat.com/1389885 15:43:23 #topic Bug 1389885 – gnome-shell freeze when holding F11 key in gnome-terminal 15:44:10 dustymabe: There's a two-phase process. First we agree whether a bug is or is not approved. Then we agree on the phrasing of the justification. 15:44:18 is anyone able to repro this bug? 15:44:49 * jkurik is not using Gnome 15:45:07 yeah I'm using i3wm, :( 15:45:12 I'm on Wayland 15:45:44 not atm but looking 15:46:06 I'm -1 on this unless investigation reveals that it has other triggers. 15:46:07 for me, this is not a typical usecase. Typically people do not hold F11 key 15:46:07 I would say, that if the bug is legit it is something that needs to be fixed.. however what are the rules for what we choose to prioritize and what we don't ? 15:46:19 dustymabe: You missed that part of the discussion :) 15:46:31 (10:26:03 AM) sgallagh: The general criteria should be something like: "Failure to resolve this bug will result in unpleasantness for a subjectively large subset of users" 15:46:35 jkurik: oh, so it's not a simple press of the f11 key? you have to hold it down? 15:46:36 sounds like some odd oom triggering to me 15:46:50 dustymabe: that is my understanding 15:47:00 i can test later and update ticket if the team is cool with that 15:47:07 dustymabe: We want to keep this list *very* small so it has value. 15:47:21 If it gets too big, it'll switch from a prioritized list to a meaningless wishlist 15:47:28 not sure why you'd 'hold' f11 tho 15:47:52 yeah. maybe we could -1 it today and ask for more clarity in the bug 15:47:53 seems very niche so I'm prelim -1 15:48:00 I am -1 as well 15:48:10 that is 3 or 4 -1s now then 15:48:50 sgallagh: what do you think ? 15:49:28 Proposed: #agreed This bug is triggered with an unusual operation and is unlikely to affect a large number of users. If new investigation shows other methods of triggering, we may reconsider it. 15:49:33 Sorry, I thought I said -1 above 15:49:46 ack 15:49:56 ack 15:49:58 ack 15:50:27 you tped it out likely got missed sgallagh 15:51:07 #agreed This bug is triggered with an unusual operation and is unlikely to affect a large number of users. If new investigation shows other methods of triggering, we may reconsider it. 15:51:27 and the last one.... 15:51:30 .bug 1394755 15:51:30 jkurik: Bug 1394755 – can't log in into wayland session after upgrade from Fedora 24, frozen gray screen - https://bugzilla.redhat.com/1394755 15:51:30 #topic Bug 1394755 – can't log in into wayland session after upgrade from Fedora 24, frozen gray screen 15:53:12 one sec on this one 15:54:24 the guest issue Southern_Gentlem is dealing with in #fedora may be related 15:54:55 I'm pretty clearly +1 on this and I suspect this may also need to be an F26 blocker down the road. 15:55:07 (since it will probably also affect F24->F26 upgrades) 15:55:21 I would be +1 here as it seems to affect the user experience quite baddly 15:55:45 yeah I agree I want it fixed but is this really affecting a large subset of users? 15:55:51 wouldn't we have heard more about it? 15:55:59 sgallagh: I hoep it is fixed before we go so far in F26 to evaluate blockers 15:56:40 +1 with a empahasis on the seemingly valid workaround in comment 7 15:56:58 and comment 16 15:57:56 dustymabe: Well, it's one of those bugs that basically breaks your system in such a way that you can't even report it with ABRT 15:58:05 So it would be difficult to *know* how many people are hitting it 15:58:16 sgallagh: I'm +1 15:58:27 but I think more people would have complained if a ton of them were hitting it 15:58:31 will be nice to know the root cause 15:58:34 :) 15:58:36 +1 15:58:58 they could ahve easily just used another de tho dustymabe 15:59:02 jkurik: I need to head to another meeting. Can you write up the #agreed? 15:59:10 and chalked it up to a buggy install 15:59:19 sgallagh: yes and thanks for your help 15:59:23 Any time 16:01:19 proposed #agreed This bug has been accepted to the list of Prioritized bugs as it badly affects user experience. 16:02:46 fyi seems mate is affected by a similiar issue to last bug we looked at definately a solid +1 now 16:03:18 in a vm as well gnome@wl and mate are affected 16:04:25 short f2f mtg soon for me too, may be semi afk 16:04:35 linuxmodder: perhaps we need to know the root cause first, as one fix might fix more bugs in case these are caused by the same bug 16:05:12 it appears from Southern_Gentlem 's tests that is may be gdm itself and or gnome@wl-session 16:05:22 linuxmodder, dustymabe: ack or patch ^^^ ? 16:05:28 but I'll look deeper tongith and update 16:05:37 ack 16:06:26 I am not sure we still have dustymabe, so considering as ack 16:06:27 #agreed This bug has been accepted to the list of Prioritized bugs as it badly affects user experience. 16:07:10 sgallagh, linuxmodder, dustymabe: thanks for the help with the first prioritization of bugs :) 16:07:19 jkurik, no probs 16:07:20 #endmeeting