Should NEW Untouched SeaMonkey Bugs Be UNCONFIRMED?
Robert Kaiser
<http://home.kairo.at/blog/2009-05/should_new_untouched_seamonkey_bugs_be_u>]
I posted an idea in a triage-related newsgroup post [1] a month ago and
lacking any reaction, I brought it up in the recent SeaMonkey Status
Meeting [2], where it was decided to get feedback on it before deciding
on it, so please tell me what you think about this:
SeaMonkey inherited a large legacy of of bugs from the Mozilla suite,
most of which have an unconfirmed value nowadays, four years after
founding the new project. The Bugzilla database reflects those as
current bugs though, often bringing them up in queries as if they were
current, even though we can't confirm nowadays that they still apply to
our current development code or even releases.
We have almost 2800 bugs that haven't seen a comment since the project
was started but are still in the NEW state, see the bug query [3] if you
don't believe it.
Ideally, we'd go and actively triage every single one of those bugs
manually to try to find out if they are still valuable. If that takes
only 5 minutes in average per bug, that's 29 8-hour workdays or almost 6
full work weeks for one person, and even if we would have someone with a
capacity of so much time to work on SeaMonkey alone, I think we'd have
higher priority stuff to spend the time on than finding out if bugs that
weren't touch for more than 4 years still have any value.
When I thought about this and about how just mass-resolving bugs without
warning is quite rude (we already had such incidents), I realized that
we already have an identifier in Bugzilla that tells that "this bug is
not confirmed to be valid" that also doesn't mean the bug is resolved
for good in any way: UNCONFIRMED.
(That even includes enhancement requests for which we can't tell if they
still apply to current code or project plans, by the way.)
So, what I'm proposing is that we mass-move those bugs in the SeaMonkey
component that had no comment since 2005-03-10 and are still NEW to the
UNCONFIRMED state.
This leaves them open but shows everyone that we are unsure that they
are still valid within the SeaMonkey project nowadays without just
kicking them off into nowhere land. Everyone who get bugmail about this
and considers his pet bug in there to be still valid, can comment on
that and/or move the bug back to NEW, which is easy - but instead of
making one person go though a pile of rotten stuff to find the good
stuff, we push the work to more people and to those who actually care
about the specific bugs.
In a few months, when that has likely been sorted out and SeaMonkey 2.0
is out the door as a stable release, we can think about what to do with
those bugs that still remain UNCONFIRMED - we might leave them as such
or ultimately mass-resolves parts or all of them, but we have months
before even thinking about this. For now, the proposal is just to make
the state reflect reality and make them UNCONFIRMED.
What do you think about this idea to clean up our bug queries to find
relevant stuff more easily?
Robert Kaiser
[1] <h72dnbTCLcffmG_U...@mozilla.org> or
http://markmail.org/message/r67aq3qjwms4ij53
[2] https://wiki.mozilla.org/SeaMonkey:StatusMeetings:2009-05-19
[3]
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=SeaMonkey&bug_status=NEW&chfieldto=Now&negate0=1&field0-0-0=longdesc&type0-0-0=changedafter&value0-0-0=2005-03-10
dominique
.../...
> So, what I'm proposing is that we mass-move those bugs in the SeaMonkey
> component that had no comment since 2005-03-10 and are still NEW to the
> UNCONFIRMED state.
That sounds a very sensible proposal...
I am a newbie not really able to help deeply with triaging, but I've
been following for already a SM development, using the nightlies....
Keep on the (very) good work Robert !
Dominique
Philip Chee
> [X-Post from blog post
> <http://home.kairo.at/blog/2009-05/should_new_untouched_seamonkey_bugs_be_u>]
From:
<http://forums.mozillazine.org/viewtopic.php?f=5&t=1262005&p=6545605#p6545605>
On Sat 23 May 2009 19:54 Euchre wrote:
> I think any bugs that relate to performance of SeaMonkey in and of
> itself would best be marked UNCONFIRMED, but that some others probably
> need other resolutions. If they relate to plugins, the builds of those
> plugins have probably moved on to the point that the bug is almost
> assuredly irrelevant or valid - thus those ought to be mass solved.
> The ones for enhancements would probably be the ones best reserved for
> actual triage, and that number might be far more reasonable to tackle,
> especially with community help. Basically, the pile of bugs could be
> broken down into 3-4 categories and handled in an appropriate manner,
> so that items which may still bear valid and useful fruit might not be
> lost.
> I don't entirely understand the bug method that coders use, not sure
> it's something end users do understand. If there's some explanation of
> the bug method, it might help with end user feedback.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]I had a handle on life, but it broke.
* TagZilla 0.066.6
David E. Ross
This is a better idea than merely closing them.
I track a list of open bugs that includes all the bugs I have submitted
that are still open. The list includes a very few closed bugs where I'm
not sure the fixes were valid. It also includes those bugs closed in
Gecko 1.9.x, which are not closed in SeaMonkey 1.1.x because the latter
uses Gecko 1.8.x.
Once I have installed SeaMonkey 2.0 on my PC, I will revisit all of my
own open bugs to see if they are still problems. I may also visit some
of the bugs on my list that are not mine. (Note, however, that this
requires an end-user, final release of SeaMonkey 2.0, not an alpha,
beta, or candidate. I have a dial-up connection and generally do not
download unstable versions of software.)
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Ricardo Palomares Martínez
> So, what I'm proposing is that we mass-move those bugs in the SeaMonkey
> component that had no comment since 2005-03-10 and are still NEW to the
> UNCONFIRMED state.
>
> relevant stuff more easily?
As irrelevant as my opinion can be (just a SM user and localizer), I
like your idea. Also, Euchre's comment quoted by Philip Chee sounds
sensible, too, but I'd rather go with the UNCONFIRMED plan first.
Anything best serving to the purpose of reaching 2.0 final should
prevail, IMHO.
Ricardo
Georg Maaß
> When I thought about this and about how just mass-resolving bugs without
> warning is quite rude (we already had such incidents), I realized that
> we already have an identifier in Bugzilla that tells that "this bug is
> not confirmed to be valid" that also doesn't mean the bug is resolved
> for good in any way: UNCONFIRMED.
Is the initial state of a bug not UNCONFIRMED?
If some or all of the old bugs you are talking about came into live with
an other initial state than UNCONFIRMED you may reset those from NEW to
UNCONFIRMED.
For other bugs with no new comment since 4 years a new bugzilla bug
state EXPIRED may be useful.
This mass closing should be done in a way that also sends an eMail to
the original bug author and those manually CCed to give them a chance to
review their bug and reopen it, if they think it being still valid.
What is the advantage of UNCONFIRMED over NEW? Both are OPEN. Correct
state for most of them is probably WFM (fixed without explicit working
on it) but this can not be set automatically, so an EXPIRED state with
notification to the bug author is probably the best for all of them. The
author may reopen it, if he thinks his bug being still valid.
I've closed some of my bugs as WFM because they disappeared with newer
releases without anybody explicit working on them.
Robert Kaiser
> For other bugs with no new comment since 4 years a new bugzilla bug
> state EXPIRED may be useful.
RESOLVED/EXPIRED does exist.
> This mass closing should be done in a way that also sends an eMail to
> the original bug author and those manually CCed to give them a chance to
> review their bug and reopen it, if they think it being still valid.
That happens by default.
> I've closed some of my bugs as WFM because they disappeared with newer
> releases without anybody explicit working on them.
Thanks for doing that.
Robert Kaiser
Serge Gautherie
> Is the initial state of a bug not UNCONFIRMED?
> If some or all of the old bugs you are talking about came into live with
> an other initial state than UNCONFIRMED you may reset those from NEW to
> UNCONFIRMED.
I don't know if we can/want to do this, but it may be a valid condition...
> For other bugs with no new comment since 4 years a new bugzilla bug
> state EXPIRED may be useful.
We explicitly don't want to close them (yet).
> I've closed some of my bugs as WFM because they disappeared with newer
> releases without anybody explicit working on them.
Resolving bugs after triaging them is wanted :-)
(But that's different from mass-changing them.)
Serge Gautherie
> I posted an idea in a triage-related newsgroup post [1] a month ago and
> lacking any reaction, I brought it up in the recent SeaMonkey Status
> Meeting [2], where it was decided to get feedback on it before deciding
> on it, so please tell me what you think about this:
I was one of those who did not fully agree iirc.
> So, what I'm proposing is that we mass-move those bugs in the SeaMonkey
> component that had no comment since 2005-03-10 and are still NEW to the
> UNCONFIRMED state.
I can agree with the 'Unconfirmed' change, as it seems an easy/good
solution to (hopefully) get an improvement in the triage area.
(Fwiw, as an example, 'Seamonkey' has a lot of legacy bug reports which
should (now) be moved (back) to 'Core' or 'MailNews Core'...)
> In a few months, when that has likely been sorted out and SeaMonkey 2.0
> is out the door as a stable release, we can think about what to do with
> those bugs that still remain UNCONFIRMED
I don't like much the mass-resolving idea, but I agree we can discuss it
when time comes.
Wayne Mery
> Robert Kaiser wrote:
>> When I thought about this and about how just mass-resolving bugs without
>> warning is quite rude (we already had such incidents), I realized that
>> we already have an identifier in Bugzilla that tells that "this bug is
>> not confirmed to be valid" that also doesn't mean the bug is resolved
>> for good in any way: UNCONFIRMED.
>
> Is the initial state of a bug not UNCONFIRMED?
not necessarily. Reporters with bugzilla privileges can file in NEW state.
Wayne Mery
topic in the Thunderbird context (though not as a full fledged
proposal). So these comments resemble my rough thinking, put in the
context of SM and this UNCO proposal.
It is postulated two big things to be gained are 1) a better reflection
of reality, 2) a bump in people triaging those bugs. I'm all for biting
into these bugs, and thinking big is good. However, I don't think
either is realistic. For example, I doubt the percentage of bugs that no
longer exist is as high as one might think. And, I'll bet it varies by
greatly by component (composer is one example I'm rather certain about).
One could do a sampling of a couple components to roughly validate
either point. As for these bugs showing up in queries for confirmed
bugs, one can just add the last comment date to queries to exclude these
bugs. In short, at this time, the reasons for moving these to UNCO
don't seem compelling, and I don't think moving them puts them in a
significantly better state.
Rather, I suggest waiting until after 2.0 to do all or part of what you
suggest. And use the time until then to get a lot of these bugs to a
better state straight from NEW. In fact, in reducing UNCO to 512, it's
likely many good things have been done there that can be applied to NEW
bugs.
Additional reasons to not go UNCO as a first step:
1. Getting to 512 unconfirmed bugs is an incredible achievement, why mix
in a mass change of 2770?
2. In terms of SM 2.0 benefiting I would guess there's little to be
gained from these bugs. Not many, if any, will make SM 2.0 significantly
better, and besides it's unlikely a significant percentage will get
quick feedback (see next point). Ergo, no need to rush.
3. The rate of reporter or commenter feedback will be very low**, which
means you'll have roughly the same amount of work to be done as when
they were NEW.
** Expect low feedback rate because: a) most reporters and cc are
gone except, obviously, current SM regulars, b) most commenters are not
in the cc: list (bugzilla didn't cc: commenters by default until early
07 or 06).
4. Lowering the number of bugs that need individual attention, and
spreading the work around is even more important than you state -
because the example of triaging at 5 minutes average per bug is overly
optimistic. (except perhaps INCOMPLETEs which are the easiest, and even
those probably require 3-4 minutes per bug)
5. In the next couple months there is probably plenty of work to keep
current triagers busy in existing UNCO bugs (like bug 373517), in
getting SM up to speed with TB3 and other things you want to deliver for
2.0, plus doing what is is suggested in item #1 of the steps listed below.
6. Less bugmail.
7. The last changed date will get changed, which is the only useful date
one can list in a bugzilla query and thus is useful, if inexact, hint
during triage.
8. Tons of mail fixes and behavior are happening - so it would be better
to reexamine all mail related bugs after, rather than before, TB3, and
SM 3.0 are done.
9. After 2.0 ships you can get more bang for the bugmail buck by
including something like
"Please check if the problem still occurs in the new version 2.0,
found at ..."
So if SM people are in no hurry, I suggest a layered approach that looks
at groups of bugs. The bugs we are talking about are [1]
http://tinyurl.com/ztuybb (chart of NEW bugs with no comment after
2005-03-10).
Suggested Approach:
1. Handle severity Major and Critical bugs on a separate track, i.e.
touch them all, retriage them as if they were all UNCO, because: a) many
don't meet the criteria for the severity b) many are likely easy to
verify c) they arguably deserve more attention than other bugs -
http://tinyurl.com/ozua7b 98 bugs
2. Continue to hit low hanging fruit, and easily identified
*chunks/hunks* of bugs.
Doing it by component using the query chart [2] may make make it
easier.
a) kill those related to dead or near dead functionality
b) move to more appropriate severity and component - examples:
* bugs in general that belong in other components of SM, core or
mailnews core
* bugs in mail components that belong in mailnews core
3. Continue to hit both UNCO and NEW that require user feedback, like
UNCO bug 373517
4. After 2.0 ships deal with what's left. Maybe outright close some,
have a SM mailnews bugday or two, do the UNCO thing etc. If you wait til
then, you get the finished mail product, and your bug comment can state
that people should try the released, QAed version 2.0.
Lastly:
* I haven't thought much about ENH bugs - perhaps they deserve different
thinking than non-ENH bugs.
* Why 2005-03-10? Can you be more aggressive and go 400-800 more bugs,
eg for those created before 2005-03-10 but no comment since 2006-03-10
* You might defer or outright skip touching component composer. My
experience with them is most aren't fixed. Besides, there's almost no
one to care for them anyway.
* Look harder at using autoresolve for small classes of bugs. For every
200 bugs you don't have to touch individually saves at least 16 man
hours, which might be put to better use in triaging newly arrived bugs,
fixes or new functionality. More in a future post.
* I won't be much affected by the results or SM bugmail, but I wouldn't
be happy getting bugmail that did little than move a bug from NEW to UNCO.
[1] http://tinyurl.com/ztuybb chart of NEW bugs, with no comment after
2005-03-10
[2] http://tinyurl.com/obd4xg chart of NEW, severity ENH...Normal bugs,
with no comment after 2005-03-10 (i.e query [1] without the bugs which
are severity Critical and Major)
John Vivirito
> dev-apps-seamonkey mailing list
> dev-apps-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-seamonkey
>
This question is sort of related to this.
What does it take to get more privileges?
Example Marking bugs as duplicates or status changing.
--
Sincerely Yours,
John Vivirito
https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246
"How can i get lost, if i have no where to go"
-- Metallica from Unforgiven III
Clint Talbert
> What do you think about this idea to clean up our bug queries to find
> relevant stuff more easily?
proposal makes a lot of sense. I'd say go for it.
Clint
Serge Gautherie
> So these comments resemble my rough thinking, put in the
> context of SM and this UNCO proposal.
> [...]
(That's +/- what I think too ;-)
Though I said wouldn't "block" KaiRo if he did want to try his (very)
optimistic way.)
Asrail
> [snippeg]
I liked the idea of putting effort on dead bugs after 2.0 as the
proposal, as is, will make it harder to triage new unconfirmed bugs.
I know reducing the number of open bugs will help, but maybe that's an
insane ammount of work which could effectively slow down SM 2.0 bug
triage - as we wouldn't have new people working here.
Regarding the last touched date... I suggest an ID for the mass change.
I've seen things like this before and that works.
You put a comment saying:
"THIS IS THE SEAMONKEY BUG'S MASS CHANGE OF {DATE}".
So you can still query these bugs.
The better point is that they could be mass resolved if received no
input after a month, for instance.
Robert Kaiser
> I don't have a strong vested interest in SM but I've thought about this
> topic in the Thunderbird context (though not as a full fledged
> proposal). So these comments resemble my rough thinking, put in the
> context of SM and this UNCO proposal.
Thanks a lot for taking your time to think about this!
> 4. After 2.0 ships deal with what's left. Maybe outright close some,
> have a SM mailnews bugday or two, do the UNCO thing etc. If you wait til
> then, you get the finished mail product, and your bug comment can state
> that people should try the released, QAed version 2.0.
Actually, that's the plan I have in the back of my head, and I'll be
very tempted to propose to mass-expire all bugs that are unconfirmed
with this round and aren't touched until then.
> * I haven't thought much about ENH bugs - perhaps they deserve different
> thinking than non-ENH bugs.
IMHO, any enh bugs from the old Mozilla Suite era needs to be
re-evaluated in SeaMonkey terms, and if nobody cares to post to in in 4
years and nobody does react to us unconfirming it, it just can expire in
peace. It's not like it would be worth a lot any more in that case.
> * Why 2005-03-10? Can you be more aggressive and go 400-800 more bugs,
> eg for those created before 2005-03-10 but no comment since 2006-03-10
2005-03-10 is the day when the Mozilla Suite was officially discontinued
and the new SeaMonkey project began forming. So this is my way to say
"any bug that didn't even see a comment since the old Mozilla Suite
times ended".
> * Look harder at using autoresolve for small classes of bugs. For every
> 200 bugs you don't have to touch individually saves at least 16 man
> hours, which might be put to better use in triaging newly arrived bugs,
> fixes or new functionality. More in a future post.
That's something probably valuable for bugs that have seen some activity
(as in comments) in the time when the SeaMonkey project had taken over
the old suite code. Those that have been dead since then should IMHO die
for good (but I know mass-resolving is quite controversial in our
community).
Overall, your proposal sounds good as well, though I doubt it will get
us rid of the majority of the bogus bugs until some timeframe shortly
after the 2.0 release, and I feel we really should try to push hard to
get there. Hvaing about 6000 open bugs in the SeaMonkey product, 4-5000
of which are probably bogus is bad enough hat I usually don't care to
search for SeaMonkey bugs at all because I rarely find the few that are
valid.
Robert Kaiser
Wayne Mery
I hope that's not the impression I gave - that's certainly not the
intention nor a goal. In fact, I'd be surprised if it handled more than
15-20%. Which is also why I wouldn't expect it to require much time to
do. But ultimately, it's your goals that count.
I forgot to mention, most of the severity Major and Critical mailnews
bugs have already been looked at for potential move to mailnews core.
Robert Kaiser
> [X-Post from blog post
> <http://home.kairo.at/blog/2009-05/should_new_untouched_seamonkey_bugs_be_u>]
>
>
> So, what I'm proposing is that we mass-move those bugs in the SeaMonkey
> component that had no comment since 2005-03-10 and are still NEW to the
> UNCONFIRMED state.
It's bugmail day. So far, I have handled about 900 of the 2750 bugs, and
I've run into a problem with Bugzilla that made me re-post the status
change and comment, sometimes multiple times, until I realized that it
was actually processing the bugs but only cutting the connection for
sending me the feedback. Because of that, some bugs with IDs under
110000 ended up with multiple comments from this. I'm very sorry about that.
I'll do the rest of the bugs when Bugzilla has calmed down a bit and
will try to avoid the problem causing those multiple comments.
You can filter the bugmail from this change looking for the string
"mass-UNCONFIRM-20090614" and this string can also be queried as part of
the comment when looking for those bugs later.
Robert Kaiser