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