closing older unconfirmed bugs of unsupport older branches ?
Carsten Book - Tomcat
i was taking a look at the list of unconfirmed bugs (in this case for
the Firefox component)
https://bugzilla.mozilla.org/reports.cgi?product=Firefox&datasets=UNCONFIRMED
and i wonder if it would make sense (also for a better triaging) to
close unconfirmed bugs who where not filed against (now) supported
branches like 1.9.0/1.9.1/1.9.2 etc
I do not think that having open unconfirmed bugs for Firefox 2.something
makes sense.
What do you think ?
Cheers,
- Tomcat
Justin Dolske
> I do not think that having open unconfirmed bugs for Firefox 2.something
> makes sense.
Agreed, though we'd probably want a few extra conditions (last comment
date, number of comments/votes, or whatever) to make some effort at
retaining bugs that are/were active but slipped through the triage cracks.
Although, TBH, I'm not too concerned if we accidentally close a few bugs
that way once every few years when we do this. Bugs are cheap to reopen.
Justin
L. David Baron
Are you talking about doing a mass change, or manually going through
them (to make sure such a change makes sense before resolving them)?
If you are talking about a mass change, I'd be hesitant to
mass-change bugs in which there's been discussion; those are perhaps
more likely to be useful, and may even have been inadvertently left
unconfirmed when they should have been confirmed. Though I could
certainly be convinced otherwise by statistics about the existing
bugs that this would apply to.
I think we'd also need to be careful about how such a change is seen
by the bug reporters; it's better not to offend them. So it's
probably worth thinking about the wording.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Zack Weinberg
> On Tuesday 2010-08-10 20:57 +0200, Carsten Book - Tomcat wrote:
> Are you talking about doing a mass change, or manually going through
> them (to make sure such a change makes sense before resolving them)?
>
> If you are talking about a mass change, I'd be hesitant to
> mass-change bugs in which there's been discussion; those are perhaps
> more likely to be useful, and may even have been inadvertently left
> unconfirmed when they should have been confirmed. Though I could
> certainly be convinced otherwise by statistics about the existing
> bugs that this would apply to.
>
> I think we'd also need to be careful about how such a change is seen
> by the bug reporters; it's better not to offend them. So it's
> probably worth thinking about the wording.
I think it would certainly be worth someone's time to attempt to
reproduce each such bug with a current version, and also make sure
they're not miscategorized, or duplicates. (ObJWZ:
http://www.jwz.org/doc/cadt.html ) But provided that this is done, I
don't see anything wrong with closing such bugs with a polite form
message (along the lines of "We are sorry this bug has been neglected
for so long. We are unable to reproduce your problem with a current
version of Firefox. If you still have the problem with a current
version, please reopen the bug.")
zw
Mike Beltzner
> think it would certainly be worth someone's time to attempt to
> reproduce each such bug with a current version, and also make sure
> they're not miscategorized, or duplicates.
That's a pretty big chunk of time - I think that if it were trivial, it would already be done. We'd want to be pretty harsh about saying that if no clear STR were included, the bug should be closed and re-opened when good STR show up.
Also, what version would you test against? I'd suggest Firefox 3.6.latest.
This might be a great community-outreach program, as it's a pretty trivial (though repetitive and time consuming) task: perfect for crowdsourcing.
cheers,
mike
Zack Weinberg
> On 2010-08-10, at 1:02 PM, Zack Weinberg wrote:
>
> > think it would certainly be worth someone's time to attempt to
> > reproduce each such bug with a current version, and also make sure
> > they're not miscategorized, or duplicates.
>
> That's a pretty big chunk of time - I think that if it were trivial,
> it would already be done. We'd want to be pretty harsh about saying
> that if no clear STR were included, the bug should be closed and
> re-opened when good STR show up.
Firm, yes, but polite.
> Also, what version would you test against? I'd suggest Firefox
> 3.6.latest.
That would also be my pick. Perhaps also try 4.0beta if the problem
reproduces with 3.6.
> This might be a great community-outreach program, as it's a pretty
> trivial (though repetitive and time consuming) task: perfect for
> crowdsourcing.
Bugday type event, maybe?
zw