Karsten =?ISO-8859-1?Q?Br=E4ckelmann?= writes: > Wow, fast response. Thanks, Mark. :) > > On Tue, 2008-10-28 at 15:49 +0000, Mark Thomas wrote: > > Justin Mason wrote: > > >> * Needinfo bugs > > >> > > >> Yeah, this concept doesn't exist in our bugzilla yet. However, the > > >> problem of identifying old, rotting and probably obsolete bugs that need > > >> additional information by the reporter has been brought up on the users > > >> list. > > >> > > >> Since a NEEDINFO Status (as featured by GNOME bugzilla) is a custom > > >> hack, we can't get that. Bummer. A "needinfo" keyword could easily do > > >> the same, though. This would help in searches and identifying stale bugs > > >> in the future. > > > > > > Here's where I'd be curious what Mark's opinion is, since he's the > > > maintainer of our BZ installation... > > > > Bugzilla 3.2 includes the ability to customise the workflow. However, in > > the mean time I can port the NEEDINFO implementation from the main Bugzilla > > instance. It actually makes my life easier since it brings the main > > instance and the SA instance closer together. I'll need to check what the > > implications are on your security flag stuff since that is a custom hack > > too and if I recall some of the changes are in similar areas. > > > > If you want to go ahead with this, create a JIRA ticket and I'll make the > > changes. > > I for one definitely prefer the Status NEEDINFO over some keyword, > though I'm biased. ;) Opinions on that kind of workflow?
+1 from me. let's see what the other devs think... > (Didn't know NEEDINFO has been pushed upstream, though. Nice.) > > > > >> Oh, and please do not use Resolution LATER and REMIND. :) They are > > >> deprecated and considered harmful upstream. Actually, they are just a > > >> mind boggling logic flaw in the first place -- neither is a resolution. > > >> > > >> Do we have direct access to the database? In that case I'd propose to > > >> get id of them in the UI, which at least prevents them from being used > > >> any further. > > > > > > Mark -- thoughts? > > > > It should be possible to remove these although I don't know how painful it > > would be. If it is simple, I am happy to do it on request. If it turns out > > to be too painful then you might have to wait until 3.2 is released (should > > be soon). Again, open a (separate) JIRA ticket for this change if you > > decide you'd like it. > > There are two possibilities here. > > Since this is Bugzilla 3.0 we already are able to customize the > available Resolutions ourself, including deleting them. To do that, we > should carefully review the existing 50 bugs in these Resolutions > *before*, though. > > With direct access to the database, the second option is to simply not > offer these any longer in the user interface. This will not edit > existing bug reports' Status, but merely get rid of the option to set > that Resolution. (Alas, IIRC it will remove them from the Search, too, > rendering later reviews slightly harder.) This would do: > > UPDATE resolution > SET isactive = 0 > WHERE value = "LATER" > OR value = "REMIND"; > > I just checked, and we seem to not use these deprecated Resolutions > anyway. No bug has been resolved by them within the last 18 months, a > mere 2 moved there within the last 36 months. > > Maybe there is no need for either of these actions anyway, in case they > aren't actually used any more. This was originally intended as a > workflow proposal. OK, plea. ;) I guess we should agree on this first... I would be +1 on hiding them. we never use them, as you note, and hiding them would reduce BZ's complexity a little. --j.
