Re: Bugzilla

[Justin Mason <jm...@jmason.org>]

(cc'ing Mark Thomas, the ASF bugzilla guru)

> Hey guys,
> 
> I actually should be doing something else, but due to lack of caffeine,
> some recent-ish comments and the fact I now got more permission bits, I
> just poked a little bit at bugzilla. Couple things...
> 
> 
> * Target Milestones
> 
> It appears upcoming Target Milestone releases are sorted at the top in
> the drop-down. Someone (sorry, don't recall, honestly :)  mentioned in a
> bug comment he couldn't find TM 3.2.6. It's still at the top. ;)
> 
> I just moved 3.1.1[01] from the top-most positions way down where they
> belong, since they likely will never be released and there's no much
> point in assigning a bug to that TM. If this was bad, please feel free
> to hit me hard.

+1 fine by me.

> Do we even need / want these two TMs? There are a few bugs, mostly
> fixed. Does it make sense to keep these, or should I even plain delete
> them after moving to a Target Milestone that is likely to become a
> release?
>   https://issues.apache.org/SpamAssassin/buglist.cgi?target_milestone=3.1.10&target_milestone=3.1.11

I think we'd have to agree that there'll never be another 3.1.x; it's
not _entirely_ beyond the realms of possibility that there might be
another one.  (I don't think we need _two_ of them though.)

> * 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...

> Applying this to existing bugs would require quite some triaging effort.
> And most of those probably can be closed due to missing information
> anyway.
> 
> How have these been handled so far? Is there any agreed upon procedure
> as to when closing bugs without response?  Thoughts?

Well, I generally have closed with a one-line comment along the lines of

    "No response from reporter; feel free to reopen with further info,
    if desired."

that seems to work, often enough.


> 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?


> Just venting some ideas, trying not to create yet another todo list I'll
> forget about anyway. No, I'm not asking to become the SA bugmaster. ;-)

hmmmm ;)

--j.

Re: Bugzilla

[Karsten Bräckelmann <gu...@rudersport.de>]

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="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
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; }}}

Re: Bugzilla

[Mark Thomas <ma...@apache.org>]

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.

>> 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.

Mark

Re: Bugzilla

[Karsten Bräckelmann <gu...@rudersport.de>]

On Tue, 2008-10-28 at 15:12 +0000, Justin Mason wrote:
> (cc'ing Mark Thomas, the ASF bugzilla guru)


> > Do we even need / want these two TMs? There are a few bugs, mostly
> > fixed. Does it make sense to keep these, or should I even plain delete
> > them after moving to a Target Milestone that is likely to become a
> > release?
> >   https://issues.apache.org/SpamAssassin/buglist.cgi?target_milestone=3.1.10&target_milestone=3.1.11
> 
> I think we'd have to agree that there'll never be another 3.1.x; it's
> not _entirely_ beyond the realms of possibility that there might be
> another one.  (I don't think we need _two_ of them though.)

Was too lazy to check this before, just did -- turns out these are
neatly separated. All bugs with Target Milestone 3.1.10 are RESO FIXED,
the only NEW one is targeted for 3.1.11. Trivial to get rid of the
latter, given 3.1.10 has not been released yet, and there are no
imminent plans to do so.


> > * 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...
> 
> > Applying this to existing bugs would require quite some triaging effort.
> > And most of those probably can be closed due to missing information
> > anyway.
> > 
> > How have these been handled so far? Is there any agreed upon procedure
> > as to when closing bugs without response?  Thoughts?
> 
> Well, I generally have closed with a one-line comment along the lines of
> 
>     "No response from reporter; feel free to reopen with further info,
>     if desired."
> 
> that seems to work, often enough.

*nod*  Closing bugs tends to trigger more attention from the reporter
than asking. Quite often the reporter just forgets to add a "can't
reproduce any more" comment. Closing the bug, which sends out another
mail poking the reporter, frequently even results in exactly that note
being added late, agreeing. In other bugzillas, anyway. ;)


> > 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?

IMHO it makes even sense to go further, and to either REOPEN valid bugs
(hey, an open bug is a reminder, isn't it?) or properly close bugs that
won't be fixed / worked on.


> > Just venting some ideas, trying not to create yet another todo list I'll
> > forget about anyway. No, I'm not asking to become the SA bugmaster. ;-)
> 
> hmmmm ;)

Hey!

  guenther


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
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; }}}