15:02:10 #startmeeting 15:02:29 raise hands for the bugzappers meeting please 15:02:34 here 15:02:35 hello tk009 adamw 15:02:43 here 15:02:44 * thomasj here 15:02:49 did either of you get the agenda? 15:03:00 did anyone get the agenda 15:03:01 only three points 15:03:11 * arxs search the link :) 15:03:28 niels had an agenda 15:03:41 https://www.redhat.com/archives/fedora-test-list/2009-July/msg00399.html 15:04:19 ok I sent one out yesterday but it failed to make the list 15:04:27 here 15:04:34 I sent another one but that failed is seems as well 15:04:40 tk009: is yours substantially different from arxs'? 15:04:42 I sent it about 15 minutes ago 15:05:07 not overly no 15:05:19 hi mcepl 15:05:27 tk009: any extra topics? 15:05:35 #topic * Triage Metrics and FAS - Update on the status 15:05:45 I will go through both 15:05:58 this was the first on my list 15:06:04 and arxs 15:06:10 is comphappy arround? 15:06:34 doesn't look like it 15:06:43 does anyone know whats going on with the stats and FAS stuff? 15:06:44 i haven't talked to him since i got back from the UK either... 15:06:58 its been down for a while now 15:07:03 i can take an action item to poke him by email if you like 15:07:08 well not updating anyway 15:07:11 it looks like that nothing had changed... 15:07:41 this may be to hard but I am thinking at this point we needs soeone to take the project over 15:07:42 tk009: down? i can still access it on http://publictest14.fedoraproject.org/triageweb/ 15:07:47 he sometimes works on stuff offline, though. depending on his connectivity. 15:07:49 or is this the wrong link? 15:08:03 tk009: yeah, i've been wondering that too, or at least just someone else to work on it (no need to think about 'taking over' or not) 15:08:18 who else can code? :) 15:08:31 points at adamw 15:08:32 =) 15:09:01 i can't 15:09:21 couldn't write a 'hello world!' app at gunpoint, me 15:09:32 lies =) 15:09:44 well I guess we just poke cophappy for now 15:10:01 but look to have soeone that can take this over take it 15:10:05 yeah, i'll take that 15:10:18 and i might ask politely if he'd mind having a co-author :) 15:10:26 maybe we can ask the list if someone is able to code 15:10:40 lets talk to comhappy first 15:10:55 k 15:10:56 yeah 15:10:58 anymore for that topic? 15:11:27 next one please 15:11:28 #topic * Status on Critical path packages triage list 15:11:39 this is yours arxs 15:11:55 adamw and I talked very breifly about it 15:12:04 yes, well, https://fedoraproject.org/wiki/User:Arxs/CPCL 15:12:24 it shows up a big bunch of packages, wich should be at least split into groups for better triaging 15:13:14 hi max 15:13:18 hello 15:13:33 sorry for being late, wasn't aware of the meeting :/ 15:13:42 arxs: so, all stuff in the bottom list are dependencies of stuff in the top list? 15:13:45 hello maxamillion 15:13:55 arxs: hi :) 15:13:56 maxamillion: we're looking at https://fedoraproject.org/wiki/User:Arxs/CPCL - the new proposed list of critical triage components 15:14:03 adamw: awesome, thanks for the link 15:14:18 #link https://fedoraproject.org/wiki/User:Arxs/CPCL 15:14:32 well, the above was the first draft from skvidal 15:14:53 yeah, I see it .... what's CPCL stand for? 15:15:10 critical packages component list? 15:15:15 guessing 15:15:15 the list below is create by a script from wwods, wo expand the three groups @core, @critical-path-base and @critical-path-gnome with here dependencies 15:15:21 tk009: that would make sense :) 15:15:25 tk009: right :) 15:15:26 ok 15:15:31 i'm not sure about the dependency approach 15:15:43 not sure how? 15:15:58 the problem is that, practically speaking, dependencies don't always describe a 'without this bit, this other bit is screwed' relationship... 15:16:24 that is what makes taing that list hard 15:16:26 the bottom list is very long and includes some stuff that probably isn't really that critical, i think 15:16:29 taing* 15:16:33 taming* 15:17:29 yeah, I guess fedora-gnome-theme is not critical ;) (mizmo won't listen for a second) 15:17:31 :) 15:17:45 actually there's fewer non-critical bits than i thought at first glance 15:17:51 adamw: sound right, but the hard question is, what is the "critical" packag and what is the only dependencie one 15:18:15 it's still just horribly long, though... 15:18:24 adamw: I'd say at least 90% of that list is critical 15:18:28 mcepl: whaaa 15:18:32 lol 15:18:45 the other problem i see with the list is it's binary packages 15:18:47 not source 15:18:53 bugzilla uses source 15:18:59 mizmo: sorry, that part of Boston accent I haven't got :) 15:19:33 you can't manually prune the critical path list 15:19:35 adamw: oops, need to improve the script who create that list, but this is not very problematic 15:19:48 wwoods: from a triage perspective, we can. 15:19:49 you have to fix the package deps in the packages in @core, @critical-path-base, and @critical-path-gnome 15:19:55 arxs: well, I think there is no other way than couple of guys (I know, me included) goes through the list and removes anything they deemed not critical. 15:20:08 because, seriously, if any of those packages has bad deps, we can't install systems 15:20:14 so even if you think "oh that's not that important really" 15:20:22 it can actually break everyone's installs 15:20:35 so the "critical" status here isn't a matter of opinion 15:20:39 wwoods: well, whatever ... we need to get list first and then we can fix groups anywhere. 15:20:42 wwoods: only by being somehow entirely absent, or so broken that it won't install 15:20:59 wwoods: which i'd hope would be noticed without triage :) 15:21:00 which is entirely possible. one wrong character in a Requires: line is all it takes. 15:21:16 I mean, yeah, with respect to triage there's a bit more wiggle room 15:21:31 I'm just saying that the expanded critical path list isn't arbitrary 15:21:32 #action fix the CPCL to use the source pkg names, not the binary pkg name 15:21:32 yeah, we're only working on the perspective of where triage is most useful; that's the point of the list in this context 15:21:33 wwoods: but if you really believe that bug in fedora-gnome-theme is as critical as kernel one, I won't believe you 15:21:54 the critical path list is what we're working from, it's a handy base; that's all 15:22:18 i think for this week we should get the list re-done based on .src.rpm and split into groups 15:22:28 anyone want to help arxs with that? mcepl has kindly volunteered ;) 15:22:28 right, I think we understand each other here. just makin' sure! 15:22:53 adamw: I think you, jlaska, and wwoods should go over it as well. 15:22:53 arxs: are we sure its using the binary names now? I don't see a binary package named 'atlas' but there is a source package 15:23:16 maxamillion: it has some -devel packages, and pulseaudio-libs which comes from pulseaudio source package 15:23:21 ah 15:23:25 maxamillion: i belive adamw without double check it :) 15:23:31 arxs: that's never a good idea :) 15:23:34 and quite a lot of lib packages 15:23:35 lol 15:23:41 * maxamillion didn't scroll down that far :/ 15:23:44 just because rpm is stupid and doesn't have Suggests/Recommends we shouldn't trust it too much (and Carthago has to be destroyed!) 15:24:16 libcurl, libgcc 15:24:30 info? 15:24:41 koji? 15:24:57 without koji, we can't build new packages. 15:25:04 i'm not listing non-critical bits 15:25:08 i'm listing binary packages 15:25:17 wwoods: well, but it is not about building new packages, but running the system, isn't it? 15:25:22 if you wanted to split out a critical-path-build group 15:25:23 I wouldn't argue 15:25:42 but package build is one of the critical path use cases 15:26:08 OK, then we need to step back ... what does "critical" mean? 15:26:31 https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal 15:27:25 oh, I see, I was looking at https://fedoraproject.org/wiki/User:Arxs/CPCL only 15:27:34 so, we might also want to look at the contents of @critical-path-base and make sure they're all relevant for triage 15:28:10 like I said, it'd be reasonable to pull some things out of that group and into a separate @critical-path-build group 15:28:24 and triage could skip the packages in the -build group 15:29:10 wwoods: sounds good, this will help us to slim down the list 15:30:06 ok, so i think we have an action plan there.... 15:30:09 are we good for that topic? 15:30:22 we have to ... things like python-bugzilla radeontool (which should be nuked IMHO already), system-config-users, ... OMG it will be a lot of work 15:31:06 arxs lives for it 15:31:10 he told me 15:31:14 =) 15:31:17 :) 15:31:23 #topic * Status on Kernel bug triage 15:31:24 python-bugzilla is required by anaconda 15:31:34 oh, OK 15:31:44 (that's how it auto-files bugs) 15:32:12 yeah, obviously ... it get fast from funny tool for bug triagers to the critical distro tool :) 15:32:44 mcepl: yeah that's kinda scary, actually 15:33:07 because it means that it might show up in RHEL6.. which would make me a maintainer of a package in RHEL 15:33:11 * wwoods gets The Fear 15:33:16 hehe 15:33:27 if i remember correctly, rjune_wrk would help with triageing of kernel bugs? 15:33:46 yes and tk009 15:33:46 we haven't got a long way on kernel bugs yet 15:33:55 i've been kinda sidetracked working on anaconda 15:34:04 I've had no time in the last two weeks to get going on anything 15:34:05 now that's done maybe we can get back to focusing on kernel... 15:34:10 wwoods: OTOH, think about job security :) 15:34:39 I think its been the sae for rjune 15:34:49 i think the next step for kernel triage is to set up a kinda trial: pick a component from the kernel, say wireless drivers, and have someone start trying to triage it 15:34:51 see if we can make that work 15:35:11 sounds good to me 15:35:18 bah to wireless =P 15:35:56 tk009: can you #agreed the idea from adam? 15:36:18 I am not sure I know how 15:36:28 #chair arxs adamw 15:36:44 if you know how please do 15:36:50 #agreed ext step for kernel triage is to set up a kinda trial: pick a component from the kernel, say wireless drivers, and have someone start trying to triage it 15:36:57 =) 15:37:08 with that we'll move on then? 15:37:16 ok by me 15:37:18 thats all :) (i hope) 15:37:37 +1 15:37:40 #topic * Bugzilla Semantics - Discuss the proposals and feedback. 15:37:58 this is one from my agenda list 15:38:20 I think we got most of the feedback we are going to fro the list 15:38:44 I can't say i agree with the proposals 15:39:06 it's getting somewhat...amorphous 15:39:07 I feel like using a poelcat line... What problem are we trying to solve 15:39:21 #link https://www.redhat.com/archives/fedora-test-list/2009-July/msg00309.html 15:39:30 we are over complicating triage for little to no gain from what I see 15:39:37 tk009: there's really nothing massively present, it's just something i said i'd bring up after the discussion with alindebe 15:39:55 some good stuff came out of the thread tho 15:40:12 tk009: well the point of my original discussion was to make things simpler: we just couldn't see that NEW / ASSIGNED was a particularly useful or accurate distinction, and thought it made more sense in pure logic terms to have one OPEN state, and a Triaged keyword 15:40:33 but i'm sympathetic to poelcat's position that it's too radical a change for too little result 15:41:10 for no result, if you ask me 15:41:16 did anyone notice what f13 (jesse) said in that thread 15:41:22 adamw: you could always do a trial with the keyword... just like you're doing with severity 15:41:25 he touched on something important 15:41:49 moreover, the issue is not about the name of the label; let's call it FOO for a month; the issue is that we are not in total agreement with developers on what ASSIGNED means. 15:41:52 poelcat: i'm not sure that'd be helpful, as the invasive change is trying to change all _existing_ bugs to use the keyword format, and a trial wouldn't tell us anything about that 15:42:03 tk009: what? 15:42:31 he tried to point out to all of us that the devs are getting tired of spam ail 15:42:36 mail* 15:42:47 adamw: if think poelcat mean that we add the keyword, and also to the old way of ASSIGN bugs, or i'm wrong here? 15:42:56 we may think its ok to have a conversation with a reporter but devs are not liking it 15:43:08 arxs: then that wouldn't be a trial =) 15:43:13 he has tried to bring this to our attention more than once 15:43:57 I have a suggestion 15:43:57 tk009: i'm not sure there's anything that can be done about that, though. 15:43:58 * poelcat thinks it would be good to quanitify how many devs? 15:44:08 step back and ask yourselves what it is you're trying to accomplish when bugzappers are marking a bug 15:44:16 tk009: yes, well that could be ONE advantage of keyword ... it could be easily filtered out in mail preferences. 15:44:18 I have not hada chance to talk to f13 about it 15:44:19 is it to prevent re-looking at the bug by another zapper? 15:44:24 be did bring it up 15:44:27 f13: we already have that perfectly well defined. it means that the bug is valid and all necessary information is provided. 15:44:39 is it to indicate to the maintainer somehow that the bug has been looked at? 15:44:44 f13: and what we are trying to achieve is to make sure all bugs are in the above state, for the benefit of developers. 15:44:54 f13: no, it means that bug is in the shape, developers can use it and not waste their time on NEEDINFOs etc. 15:45:05 f13: yes 15:45:06 adamw: but do the developers care that bugzappers are "done" with the bug or not? 15:45:15 some do 15:45:18 most the developers I've talked to don't. 15:45:19 so dont 15:45:20 f13: for the reason mcepl states, yes 15:45:26 some dont* 15:45:43 mostly it seems that the bugzapper modifications serve the purpose of avoiding duplicated effort 15:46:03 f13: the theory is that developers can ignore bugs in NEW and only worry about bugs in ASSIGNED 15:46:07 especially when no other changes are made to the bug other than "this has been looked at" 15:46:18 adamw: hrm. I don't know that I agree with that theory 15:46:28 f13: if a bug is already valid and has all necessary information included, what else could a triager do? :) 15:46:41 f13: OK, but that's the assumption we are all working on 15:46:46 adamw: right, to the maintainer, the traiger is doing nothing of value in that case 15:47:06 f13: yes he is. imagine someone inspecting toys for safety 15:47:21 f13: 99% of toys won't have razor blades in them, but the inspector has still done something of value by checking that they don't 15:47:28 anyway, with the current situation, to get more buy in on triaging, I would suggest that the touching on by bugzappers is as light as possible, without making noise in the comments 15:47:35 f13: even if 'all' he did was look at it, say 'yup, no razor blades' and stamp his 'safe' mark on it 15:47:49 adamw: right, that can be done by setting a keyword and nothing else 15:47:55 f13 I understand and agree 15:47:57 (again bonus points for avoiding the bug mail) 15:48:03 adamw: well, that's actually valuable point ... do we need that bugzappers' signature that much? 15:48:12 its not that 15:48:21 mcepl: it's useful to avoid multiple zappers from looking at the same bug 15:48:21 its mail that says triaged 15:48:29 and nothing else as an exaple 15:48:30 f13: how many devels are complaining about bug mail? 15:48:34 f13: the problem is that switching to a keyword is problematic (see poelcat's objection) 15:48:46 poelcat: kernel, anaconda, yum, me 15:48:49 f13: and IIRC, bugzilla sends out a mail if you just change state, even without a comment 15:48:49 f13: well, if it is ASSIGNED, nobody should look at it 15:48:50 * poelcat does not object to a keywword 15:49:04 poelcat: the process of switching, though 15:49:10 poelcat: mine do (caillon, ajax, et al.) 15:49:11 f13: so < 1% of devs? :) 15:49:15 mcepl: but the problem is that ASSIGNED means different things to differen tpeople. 15:49:28 poelcat: 1% of devs, but what % of bugs dealt with? 15:49:47 one would argue that installer, yum*, kernel, X, firefox* get the lions share of bugs 15:49:53 f13: no, we have some definition agreed upon, that some devs don't agree is a different matter ... for bugzappers it certainly means "Don't touch it anymore, nothing to see here". 15:49:57 f13: they should have complained when i brought up the bug lifecycle for discussion on -devel-list, then, because that's perfectly clear on what ASSIGNED means :) 15:50:09 adamw: they did complain 15:50:17 adamw: and the solution then was "OK, we'll just ignore all your bugs" 15:50:23 i don't recall anyone complaining about the definition of ASSIGNED 15:50:42 the only known exception case we have there is anaconda, and that one's covered 15:50:47 and I don't really think the "Well you didn't complain so screw you" is helpful. 15:50:59 well, I wouldn't say that, but I don't recall anybody who would came with working alternative solution without making a lot of changes in bugzilla and already processed bugs. 15:51:04 that's not what i mean, what i mean is we can't deal with an issue if no-one tells us about it 15:51:12 right 15:51:15 I'm here to tell you about it 15:51:25 so who thinks ASSIGNED means something other than 'triaged'? 15:51:25 these groups by and large have just plain opted out of triage efforts 15:51:30 me 15:51:37 yes they have 15:51:37 because they felt that it was adding more noise and confusion than it was worth. 15:51:37 jwb: what does it mean to you? 15:51:49 f13, jwb: OK, propose something better, working all over Fedoralang. 15:51:54 I also think ASSIGNED means something else. 15:51:58 adamw, that i'm actually working on it 15:52:10 ASSIGNED to me means "I've taken this bug and I'm going to work on it, soon" 15:52:13 i.e. "accepted"? 15:52:18 f13, right 15:52:28 f13: did you hear all our tirade about ON_DEV? 15:52:36 particularly of use in group efforts, like the desktop teams and installer, and yum, and... 15:52:48 mcepl: I don't believe more states is the answer 15:52:53 in fact, less states would be better 15:52:59 we are going to run out of time --- 8 minute warning 15:53:13 mcepl: i don't _complain_ about bug mail, i just get far more than i can read 15:53:16 because at the base level I don't believe that triage is a state of a bug, it's more of an attribute, a keyword if you will. 15:53:38 ajax: well, you don't *complain*, but you don't read it, because you are overloaded. IIRC 15:53:40 so we at least have a good answer to the question 'what problem are we trying to solve', now. 15:53:47 pretty much. 15:53:57 that is why i brought this one up 15:53:59 f13, or even a flag, like fedora-cvs 15:54:05 flag is the wrong model for triaged 15:54:11 why 15:54:12 flags are a bit weird 15:54:17 who sets it to ? 15:54:23 ajax: you are too nice guy to complain ;-) 15:54:27 it's less of a checkbox and more of a tri-state 15:54:38 if the answer is 'all bugs get auto-set to ? and the triager sets it to + when it's done', that's the wrong answer :) 15:54:44 adamw: now that you have what you're trying to solve, can it be solved without twiddling the bug state? 15:54:45 why 15:54:52 and thus avoiding the entire argument of what ASSIGNED means to people? 15:54:56 * poelcat still thinks if we are looking to add metadata to bug the keyword is the simplest way to do it 15:54:58 jwb: because then you may as well just have a keyword 15:55:06 then use a keyword 15:55:09 adamw, f13: no I think the only real alternative is Triaged keyword, IMHO. 15:55:16 as long as it's binary - 'done or not done' and applies to every bug, keyword is the correct method 15:55:28 so, remember where we came in, with me proposing the use of a Triaged keyword =) 15:56:00 poelcat: did the above discussion convince you there's significant value to the change? 15:56:04 no, the second point which nobody resolved to my satisfaction is conversion ... I just don't believe it will be so painless as somebody (adamw) suggested. 15:56:18 adamw: i never said i was opposed to using the keyword 15:56:34 hmm, it may be mcepl i was remembering 15:56:35 hold on 15:56:42 it was mcepl 15:56:44 f13: and BTW wouldn't it be possible to add a rule to Bugzillla "when changing state to ASSIGNED don't spam"? 15:56:44 oh, yeah, it was mcepl. 15:56:46 poelcat agreed 15:57:02 mcepl: the problem is that bugzilla generates an email on any state change, iirc 15:57:06 mcepl: and we'd be back to square one, arguing about what ASSIGNED means 15:57:15 mcepl: i think even if you change frm NEW to ASSIGNED with no comment, a mail goes out 15:57:24 that's another issue the keyword would solve 15:57:28 I'm suggesting that we just avoid that argument all together, and use a new keyword that we can't possibly have conflicting use for. 15:57:32 I DON'T CARE WHAT THE WORD MEANS, IT MEANS NOTHING!!! CALL IT "FOO" IF YOU WANT!!! 15:58:06 mcepl: we're talking about the state, now, not the word 15:58:07 mcepl 15:58:08 adamw: well, can we ask dkl to change it? 15:58:15 dont yell at peole please 15:58:25 mcepl: it's obvious from above that some significant development groups use ASSIGNED to mean something different from what it means to triage 15:58:32 tk009: I was repeating it twenty times at least now, I think. 15:58:46 mcepl: we could ask, of course, but i'd rather we address your problems before going full steam ahead with this... 15:58:47 calm my brother 15:59:18 for anyone playing along who's not on test-list, mcepl's email is: https://www.redhat.com/archives/fedora-test-list/2009-July/msg00380.html 15:59:20 OK, I give up, do you whatever you agree to do, I will accept it. I don't understand a word why we need to do this change. 15:59:34 okay this will need to continue on the list, we would agree? 15:59:42 we are not changing anything yet 15:59:50 mcepl: simple. You're seeing people opt out of triage all together, because an agreement can't be reached on how to treat ASSIGNED 15:59:55 #idea for anyone playing along who's not on test-list, mcepl's email is: 15:59:57 mcepl: jwb and f13 have said that they're in the same position as anaconda; they use ASSIGNED to mean something other than 'this bug has been triaged' 15:59:58 https://www.redhat.com/archives/fedora-test-list/2009-July/msg00380.html 16:00:01 so you either have people opt-out, or you have a growing pile of exceptions to deal with 16:00:10 f13 is correct 16:00:21 solution: avoid touching bug state at all, and simply use a keyword to indicate that triage has been done. 16:00:24 we are not making friends with our current ethods 16:00:35 i'll try and send a follow-up email to the list summarizing the current state... 16:00:41 i would be slightly in favor of not overloading ASSIGNED to mean triaged. 16:00:52 f13: and all these people who actually came to us and complained left persuaded IIRC to use ON_DEV and were at least agreeing if not happy. 16:01:03 but, practically speaking, i'd be in favor of dropping ASSIGNED as a bug state entirely 16:01:06 #action adamw will and send a follow-up email to the list summarizing the current state 16:01:27 f13: jwb: i don't believe you commented on the ON_DEV suggestion 16:01:41 adamw: my comment there is that twiddling bug state just isn't the answer. 16:01:50 we need to go in a direction of less bug states to choose from, not more 16:01:58 what he said 16:02:02 in fairness it's not really 'twiddling', that's the defined process - for RHEL as well as Fedora 16:02:20 except that RHEL has entirely different modes of operation than Fedora 16:02:38 where people are assigned to work on bugs, rather than maintainers accepting a bug and choosing to work on it 16:02:57 i would prefer to keep RHEL out of this discussion entirely, but i have little vested here 16:03:01 and 3 levels of red tape to go through before a bug can even be allowed to be touched 16:03:41 sorry, I have to go anyway. BBL 16:03:43 and in RHEL when a bug gets to ASSIGNED, that means somebody had better be looking at it, for their job's sake 16:03:50 the same certainly isn't true in Fedoray 16:03:52 Fedora. 16:03:53 ok, we'll put this on the list. jwb, are you subscribed to test-list? 16:04:00 yes 16:04:02 ok 16:04:10 we're over time... 16:04:36 thank you all for coming 16:04:46 #endmeeting