<< Weekly Status Report, W20/2009 | The roads I take... | Integration eines Magento-2-Webshops mit FreeFinance und selbstgebautem Warenmanagement >>

Should NEW Untouched SeaMonkey Bugs Be UNCONFIRMED?

I posted an idea in a triage-related newsgroup post a month ago and lacking any reaction, I brought it up in the recent SeaMonkey Status Meeting, 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 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-resolve 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?

Entry written by KaiRo and posted on May 22nd, 2009 21:42 | Tags: Bugzilla, Mozilla, SeaMonkey, triage | 5 comments | TrackBack



Tony Mechelynck

from Brussels, Belgium

Sounds good
Sounds good to me, and better than the RESOLVED/EXPIRED episode of some years ago. This way, triagers with appropriate privs can re-confirm the bug (bring it back to NEW) if it can be reliably reproduced in a current build, or else resolve it (WORKSFORME, INCOMPLETE, DUPLICATE, whatever) if that seems appropriate, all with a minimum of fuss, and a minimum of surprise to whoever might still be interested in those bugs; and in the meantime, the still-untouched bugs will appear in the "SeaMonkey Unconfirmed" bug lists which have already been set up.
2009-05-22 22:41

Niek Dekker

+1. Good idea to set those old bugs apart and concentrate on current ones.
2009-05-24 04:11

Gervase Markham

Why not expire them?
Given that you have a limited amount of QA and triage resource, when will these bugs ever be a good use of someone's time? And if they will never be a good use of someone's time, why not keep things honest and clear, and resolve them EXPIRED?

We need to be unashamed about concentrating our efforts on the bugs which are most likely to be valid, and therefore result in an improvement to the product. Non-RFE bugs untouched for three years are very unlikely to be in that category.

Also, if you resolve them expired, their original reporters may, in some cases, come back and say "but I still see this". Which is also a good result.
2009-05-26 13:51


from USA

Expired vs. Unconfirmed
Quote of Gervase Markham:
Given that you have a limited amount of QA and triage resource, when will these bugs ever be a good use of someone's time? And if they will never be a good use of someone's time, why not keep things honest and clear, and resolve them EXPIRED?

This strikes me as a good question. Is there any functional difference between EXPIRED and UNCONFIRMED in Bugzilla? Is EXPIRED already used to signify something else for Mozilla and/or SeaMonkey?

If the answer to both these questions is "no" then it seems that EXPIRED would be the obvious choice if a bug could be just as easily returned from this state as it could from UNCONFIRMED.

I do agree that it is overly presumptuous to assume that just because a bug has no new comments it is no longer present. Good netiquette is not to post unless you have something new to add (otherwise you seem to be contributing little more than an AOL-style "Me too!") Also keep in mind that most people are only looking at SeaMonkey 1 which has essentially been on life support since January 2007. A lack of attention to non-security-related bugs from developers might breed a certain amount of neglect from bug reporters as well.

A more accurate indicator of whether or not a bug still exists might be new subscriptions to it. People don't subscribe to bugs they aren't experiencing. If there is any way to take this into account you could not only find obsolete bugs easier, you could also get a good idea of where user priority is in general for all bugs by plotting out number of subscriptions over time.

I'm just a random user, however.
2009-05-26 20:11



Gerv, given the somewhat harsh reactions we tend to get especially in the SeaMonkey community when mass-resolving bugs, my intent with this is to go at least as far as to get a significant portion of bugs off the NEW state, which holds over 5000 bugs in the SeaMonkey product alone right now.
If it's up to me, we'll look into expiring a good amount of them later if they continue to be UNCONFIRMED. I'd like to wait until after the SeaMonkey 2 release with that step though, as that event will enable us to move off some components to the Graveyard and make it easier to explain why so many reports are obsolete now.
2009-05-26 21:21

Add comment