The roads I take...

KaiRo's weBlog

April 2024

Displaying recent entries tagged with "triage". Back to all recent entries

Popular tags: Mozilla, SeaMonkey, L10n, Status, Firefox

Used languages: English, German


July 2023

February 2022

March 2021


June 14th, 2009

It's UNCONFIRMED Bugmail Day!

I have blogged about the plans to move old untouched bugs to UNCONFIRMED some time ago, the SeaMonkey team has agreed to move forward with this in the meantime, and today I went for actually doing the change.

So, that makes it 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.

By KaiRo, at 18:42 | Tags: Bugzilla, Mozilla, SeaMonkey, triage | 4 comments | TrackBack: 1

May 22nd, 2009

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?

By KaiRo, at 21:42 | Tags: Bugzilla, Mozilla, SeaMonkey, triage | 5 comments | TrackBack: 0

May 14th, 2008

1000 Bugs Killed In 8 Weeks!

As reported here before, I asked for help help with triaging SeaMonkey bugs. Back then we had over a thousand unconfirmed non-enhancement bugs in the "Mozilla Application Suite" product that had no activity for more than 6 months. When I looked at the query today, I was quite surprised when it only showed 15 bugs!

Looking at the open bug graph for our Bugzilla product I could confirm what the query had suggested:
The people helping us here have killed about a thousand bugs in 8 weeks!
This is absolutely awesome, thanks and congratulations to everyone helping with this effort!

It would be really cool if we can prolong this Bugzilla cleanup effort and try to reduce unconfirmed and old bugs even more, so the real bugs are easier to find and deal with. In my newsgroup posting from today (web version), I have a few suggestions on what to attack next - I'd welcome your input!

By KaiRo, at 18:11 | Tags: Bugzilla, Mozilla, SeaMonkey, triage | 1 comment | TrackBack: 0

Feeds: RSS/Atom