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?
(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...
guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
