mass QA ... changes to mailnews:* bugs

Wayne Mery

unread,

Jun 23, 2008, 8:08:16 PM6/23/08

to

Posting this for feedback.

Draft Proposal for cleaning mailnews:* pre and post reorg. For purposes
of this proposal, "reorg" is simply justdave's/gerv's moving of core:
mailnews: xxx bugs to mailnews: xxx. Please refer to prior reorg threads
in m.d.a.t and m.d.planning.

The goals here are to a) a mass clean obsolete QA and assignee settings,
and b) where useful, make additional changes and in some cases annotate
bugs to simplify or expedite future triage work. Additional goals are to
do this with a minimum amount of steps, effort and bugmail, and do it in
the immediate vicinity of the component reorg so that bugs' last changed
date can resume aging.

One might ask why bother with a mass cleanup, why not continue the
gradual cleaning of these fields one bug at a time as has been done for
the past 2 years (since the generic QA address have in place). I won't
attempt an iron clad response but offer these bullet points
- many people want accurate QA so Bugzilla "watches" are more effective
- many want assigned="nobody" for bugs not being worked
- to do this over time, at our present closure and triage rate, will
probably take 2-3 years. Since bug date changes are going to happen
anyway this seems an opportune time to do quickly improve the quality of
the bug information in this little corner of the bug world.

Now on to specifics. Please note I have not attempted perfection in the
following - this is a rough draft. Indeed, if some of my numbers are
off and component information sketchy then it's because I'm on
information and patience overload. Feel free to disagree, improve, etc,
but be kind :) Note also we should expect to parcel out the work to
several people (in an organized manner of course) even if we minimize
the steps. For now, I won't address this point further.

First, the process I foresee so you can see this in concrete terms. The
analysis done before developing the process is listed after. It may seem
like a lot of information, but it's not as complex as it sounds.

My rough estimate of number of bugs that will be touched is 1,000.
Add several hundred if ENH bugs are also changed.

=====================================================
PROCESS

PREPARATION:
- triage sev=major+critical bugs, *which have patches*, before date and
mass changes to preclude unwanted/bad changes to "important bugs"
* 76 bugs, qa or assignee contains formerly-netscape -
http://tinyurl.com/5rnue9
* 30 bugs, neither qa or assignee contains formerly-netscape
http://tinyurl.com/5orpgb
- save results (list of bug#) of date based queries that may be of
future interest. examples:
- 105 dated 2007-06-21 ss
- 646 dated < 2007-04-21 (roughly pre TB2.0)
- major+critical last changed 2007-01-01

MASS CHANGES:
1. touch ldap integration >=2007-01-01 to default QA
2. touch ldap integration < 2007-01-01 to default QA and assignee
3. because last changed date will be less useful for a few months,
comment in some (~300?) old bugs to a) ping reporter, b) annotate with
closeme and/or comment to facilitate post reorg triage // reverify
"confirmed status". These are the only bugs I foresee getting comments,
and also getting two touches.
4. afaict, mass changes to the other 16 components can occur before or
after justdave's component reorg.

CLEANUP: (one-off changes which can be any time before or after reorg)
- fix assignee contains seamonkey.bugs (will be <13 after mass changes)
- sev=major+critical 79 bugs that don't have patches
http://tinyurl.com/5evqam

QUESTIONS:
1. Is there a need for bug comment to accompany changes that are only QA
and assignee? (not having comments will reduce bugmail)
2. Regarding step 3 of "mass changes" a) what bugs are worth bug
comments to request further info, and b) should there be any subsets
that get different comments or closeme dates?
3. Do we care much about fixing status=assigned for bugs that are
changed to a=nobody? (maybe 20-30 bugs - maybe a CLEANUP item)
4. Do we do ENH bugs in the same pass?

NOTES:
1. Whiteboard updates not advisable in mass changes

=====================================================
ANALYSIS

There are 20 mailnews components. I suggest 3 might be excluded from
immediate cleanup:
- bidi (moving to a core:layout)
- intl (the component is rather abandoned and IMO is a special case)
- palmsync (also needs separate follow up)

That leaves 17 components that by sheer coincidence all need QA of the
form xx...@mail.bugs. This does help simplify things. After some analysis
(below) one finds some components' bugs need no touching, some need just
a little, and some are, hmm, messy.

Quick numbers:
800 ENH bugs
296 major+critical
1,611 normal+minor+trivial bugs.

Interesting stats, which may or may not be indicative of "future
resolution rates" of old bugs...

severity not-major or critical, resolved in the last year
--resolution--
FIXED other still unresolved
created prior 2007 19% 81% 1374
created 2007/2008 85% 15% 236

I reduced the size of and simplified my initial analysis by excluding
ENH bugs. So the numbers below are mostly based on non-ENH bugs. At some
point we need to decide how we want to handle ENH bugs, i.e. whether
they are "on par" and as important as non-ENH bugs, AND whether
including them in this mass cleanup greatly complicates the process of
making the queries and bug changes, and is worth the bugmail.

After scanning the bugs, I thought removing severity=major and critical
bugs from the pool might help simplify things is some ways - they tend
to have recent activity, they tend to have better QA and assignee
information, they tend to have an assignee that we don't want to risk
losing/not want to change. (And if bug is valid, many should be
priorities for work in the short term) Discretion in this subset of
bugs may be worth the effort of manual triage - it's not only ~150 bugs.

ACTION BY COMPONENT

no touch needed: lightly touch:
filters - QA only
movemail migration - QA only
search security - QA only
?address book (or don't touch)

mixed bag, reset several fields (multiple queries?)
attachments
backend
composition - QA, some a=
MIME - QA all, ducaroz assignee, more??
ldap integ - < 2007-01-01 reset QA and assignee, >=2007-01-01 just QA
import - 2 steps
printing

reset all (QA, assignee, status, ...)
localization
s.mapi - set all QA,assignee,NEW and then fix 4 assign bienvenu + jshin
?networking - QA,assignee then fix mcsmurf bug 294824, ?174692 bienvenu

=====================================================

By component (sev=trivial, minor, normal):

? QA Assign #
good good? bugs component comments
---- ------ --- ----------- -------------------------
1 all most? 115 address bk clean
2 half ? 67 attachments
3 2/3 many? 402 backend clean, *~1/5 a=mscott, a few -netscape
4 half most* 387 composition *except assignee=dacarroz
5 all all 56 database clean, no last changed < 2007-05-18!
6 3/4 all? 147 filters qa= ~1/4 blank or formerly-netscape
7 1/4 3/4 52 import a=cavin>nobody+QA,reset QA of blank+former
8 few 1/2 86 ldap int. do by date/#218712 assignee=bienvenu
9 none ~3 16 localiz. mostly bad except 2-3 #392307 christian
10 few ?few? 128 MIME mess, but too touchy for wholesale reassign?
11 all all 8 movemail clean
12 none ?* 46 networking QA+assignee=mscott, 1 mcsmurf
13 none all~ 15 printing reset a+q where q<>prin...@mail.bugs
14 1/4 all? 15 prof migr fix QAs, some a=
15 all all 26 search clean
16 1/3 most 17 security QA, maybe change some old a=
17 few few 27 simp.mapi reset all then fix a=, 2 bienvenu,2 jshin

Note: mime and backend present the bigggest challenge IMO

=======================================
MISC FIGURES (some not so relevant)

~800 ENH bugs ...

~2000 non-ENH bugs, bug last changed:
~240 = 2004
242 dated 2004-11-22 m...@mozilla.org did product=mailnews>core
~135 = 2005
~180 = 2006
---
~555 (566 exactly: 24 critical, 38 major)
- almost 0 have useful whiteboard info, except nab-xxx
- 103 reported by formerly-netscape
- 103 have qa x...@mail.bugs (90% are address, backend, composition)

qa has mail.bugs 1116
qa not mail.bugs 790 (689 excluding major+critical)
of these, most are assigned to
mscott
formerly-netscape
duca...@ducarroz.org
bienvenu
nobody
to a lesser extent
ma...@seamonkey.bugs
nhottanscp
smontagu
ssu0626
timeless

Gary Kwong

unread,

Jun 23, 2008, 8:48:35 PM6/23/08

to

After a quick glance, I would say this sounds like a fine plan. However,
some form of early warning email or something should be given to the bug
assignees since they are the ones that are highly likely to receive the
most bugmail.

About the issue of comments, there are arguments both ways, though I'm
not sure how people will mass delete bugmail without changes in
comments. I'm really leaning towards having no comments though. That
will preserve the "no comments" queries to search for old bugs.

I would think that enhancement requests ought to be touched as well,
since we're doing it, why not just be comprehensive. Touching enh bugs,
though, may send out a wrong message that someone is working on the bug
reporter's proposal, when in reality we're just tidying up.

-Gary

Wayne Mery wrote:
> Posting this for feedback.
>
> Draft Proposal for cleaning mailnews:* pre and post reorg. For purposes
> of this proposal, "reorg" is simply justdave's/gerv's moving of core:
> mailnews: xxx bugs to mailnews: xxx. Please refer to prior reorg threads
> in m.d.a.t and m.d.planning.
>
> The goals here are to a) a mass clean obsolete QA and assignee settings,
> and b) where useful, make additional changes and in some cases annotate
> bugs to simplify or expedite future triage work. Additional goals are to
> do this with a minimum amount of steps, effort and bugmail, and do it in
> the immediate vicinity of the component reorg so that bugs' last changed
> date can resume aging.

/snip

Mark Banner

unread,

Jun 24, 2008, 3:41:44 AM6/24/08

to

Wayne Mery wrote:
> QUESTIONS:
> 1. Is there a need for bug comment to accompany changes that are only QA
> and assignee? (not having comments will reduce bugmail)

Can we not temporarily close bugzilla and turn off bugmail for this? I
haven't summed the numbers, but considering what I watch, I'd expect
anywhere above 500 bugmails for this. Anything inbetween I'm probably
going to miss without some sort of filtering.

A comment would allow filtering, but is annoying. If I get several
hundred bugmails I'm just going to delete them and not check to see if
something has been incorrectly assigned (which I probably also won't do
if we turn off bugmail).

Standard8

Gervase Markham

unread,

Jun 24, 2008, 5:12:44 AM6/24/08

to

Mark Banner wrote:
> Can we not temporarily close bugzilla and turn off bugmail for this? I

We can, but not everyone wants not to get bugmail for this stuff, IYSWIM.

> haven't summed the numbers, but considering what I watch, I'd expect
> anywhere above 500 bugmails for this. Anything inbetween I'm probably
> going to miss without some sort of filtering.
>
> A comment would allow filtering, but is annoying.

Why is it annoying? You can set up a temporary filter. If this is too
hard, then we should ask a Thunderbird developer to fix the UI. Er... ;-)

> If I get several
> hundred bugmails I'm just going to delete them and not check to see if
> something has been incorrectly assigned (which I probably also won't do
> if we turn off bugmail).

So your course of action will be the same whether or not there is bugmail?

Gerv

Wayne Mery

unread,

Jun 24, 2008, 7:27:31 AM6/24/08

to

On 6/24/2008 5:12 AM, Gervase Markham wrote:
> Mark Banner wrote:
>> Can we not temporarily close bugzilla and turn off bugmail for this? I
>
> We can, but not everyone wants not to get bugmail for this stuff, IYSWIM.
>
>> haven't summed the numbers, but considering what I watch, I'd expect
>> anywhere above 500 bugmails for this. Anything inbetween I'm probably
>> going to miss without some sort of filtering.
>>
>> A comment would allow filtering, but is annoying.
>
> Why is it annoying? You can set up a temporary filter. If this is too
> hard, then we should ask a Thunderbird developer to fix the UI. Er... ;-)

Most of the work requires QA changes, so I think filtering on
"QAContact| " (QA changing from blank) and "@formerly-netscape" will
catch 90+% of the bugmail.

Wayne Mery

unread,

Jun 24, 2008, 9:00:53 AM6/24/08

to

On 6/23/2008 8:48 PM, Gary Kwong wrote:
> After a quick glance, I would say this sounds like a fine plan. However,
> some form of early warning email or something should be given to the bug
> assignees since they are the ones that are highly likely to receive the
> most bugmail.

that list is pretty short, but absolutely.

I wonder if "watchers" of those assignees might not be more impacted, or
at least, less aware/less reachable of pending changes.

Robert Kaiser

unread,

Jun 24, 2008, 10:20:52 AM6/24/08

to

Wayne Mery wrote:
> QUESTIONS:
> 1. Is there a need for bug comment to accompany changes that are only QA
> and assignee? (not having comments will reduce bugmail)
> 2. Regarding step 3 of "mass changes" a) what bugs are worth bug
> comments to request further info, and b) should there be any subsets
> that get different comments or closeme dates?

I'd be careful with adding comments at all, as we can keep all the
triage "last comment older than xxx" queries in place when no comments
are added.

> 3. Do we care much about fixing status=assigned for bugs that are
> changed to a=nobody? (maybe 20-30 bugs - maybe a CLEANUP item)

I think it makes sense. status=assigned should only be set if the person
the bug is assigned to is really committed to work on this - which is
irrelevant if the assignee is "nobody".

> 4. Do we do ENH bugs in the same pass?

That probably also makes sense, I guess people watching bugs will also
want to get bugmail when someone's working on an RFE.

Robert Kaiser

Tony Mechelynck

unread,

Jun 24, 2008, 3:52:40 PM6/24/08

to

I don't know, but OTOH, "watchers" of the default QA will start seeing
some of the bugs which had stood out of their radar because they had,
let's say, est...@formerly-netcape.com.tld instead of the expected
gen...@seamonkey.bugs . Maybe they aren't yet all aware of the upcoming
impact, but all in all I think that's what watching is for. In the case
of nondefault assignees of long-asleep open bugs (and their watchers), I
suppose some of them will be reassigned to nob...@mozilla.org or
somesuch, which means one bugmail per affected bug -- other changes to
the same bug should happen afterwards if possible. Or should these
assignees be moved to the CC list?

Anyway, I'm not sure how to get ahold of "who is watching whom" -- the
bug page don't display that.

Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
22. You've already visited all the links at Yahoo and you're halfway through
Lycos.

Wayne Mery

unread,

Jul 14, 2008, 8:02:37 PM7/14/08

to

On 6/23/2008 8:08 PM, Wayne Mery wrote:
> Posting this for feedback.
>
> Draft Proposal for cleaning mailnews:* pre and post reorg. For purposes
> of this proposal, "reorg" is simply justdave's/gerv's moving of core:
> mailnews: xxx bugs to mailnews: xxx. Please refer to prior reorg threads
> in m.d.a.t and m.d.planning.
>
> The goals here are to a) a mass clean obsolete QA and assignee settings,
> and b) where useful, make additional changes and in some cases annotate
> bugs to simplify or expedite future triage work. Additional goals are to
> do this with a minimum amount of steps, effort and bugmail, and do it in
> the immediate vicinity of the component reorg so that bugs' last changed
> date can resume aging.

>...

> PREPARATION:
> - triage sev=major+critical bugs, *which have patches*, before date and
> mass changes to preclude unwanted/bad changes to "important bugs"
> * 76 bugs, qa or assignee contains formerly-netscape -
> http://tinyurl.com/5rnue9
> * 30 bugs, neither qa or assignee contains formerly-netscape
> http://tinyurl.com/5orpgb
> - save results (list of bug#) of date based queries that may be of
> future interest. examples:
> - 105 dated 2007-06-21 ss
> - 646 dated < 2007-04-21 (roughly pre TB2.0)

I've concluded it's not worth saving a list of these last categories of
bugs. If anyone thinks otherwise please comment.