Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Who can help triage old unconfirmed bugs?

1 view
Skip to first unread message

Robert Kaiser

unread,
Mar 21, 2008, 8:39:48 PM3/21/08
to
Hi SeaMonkey-devs and -testers!

As our project inherited a big old codebase from the Mozilla suite, we
also inherited a huge database of bugs, many of which are probably quite
old and not visible in current SeaMonkey 1.1.x or even trunk nightlies
any more.

Here's a great help for the project that everyone in the testing
community can take part in - we call it "bug triage"!

This means, go through (esp. unconfirmed) bugs in Bugzilla, look into
what they are about and try to verify that information, possibly
resolving the reports as "invalid" if it's not a real bug in SeaMonkey,
"duplicate" if it's already reported under a different number,
"incomplete" when from the description in the bug it's not clear what it
is about and more information is needed to make this a valid and clear
report, or "worksforme" when the bug can not be seen with current versions.

This is an easy job that can be done by anyone who has a current
SeaMonkey, ideally it should be done on a trunk nightly, and anyone can
take part in this!

We currently have a list of 1023 bugs that are not enhancements, in the
UNCONFIRMED state and not touched in any way in the last 180 days:

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Mozilla+Application+Suite&bug_status=UNCONFIRMED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&negate0=1&field0-0-0=days_elapsed&type0-0-0=lessthan&value0-0-0=180

We'd be vary happy about anyone who can help triaging those and
resolving the bugs on that list that are not valid bug reports for
current SeaMonkey versions (any more).

Please help our project and our developers to get a better picture of
what bug reports we actually nedd to care about!

Your help counts to make SeaMonkey a better product!

If you have any live questions, feel free to visit
irc://irc.mozilla.org/seamonkey and ask for our help in that channel,
else ask here in the newsgroups. Note that I'm setting the follow-up to
m.d.a.seamonkey for this message, as this is mainly a development topic,
but everybody in the community is invited to help.

Greetings,

Robert Kaiser

Tony Mechelynck

unread,
Mar 21, 2008, 9:33:03 PM3/21/08
to

Count me in. This way I may perhaps use my new "editbugs" privilege for
some useful purpose. :-)

Best regards,
Tony.
--
The question is: What do you do with your life?
The wrong answer is: Be the richest guy in the graveyard.
(billionaire and Oracle founder Larry Ellison)

NoOp

unread,
Mar 21, 2008, 10:26:26 PM3/21/08
to

1021 bugs found.

I think that if you want folks to assist you need to regroup and
classify by feature/event. I for one wouldn't want to venture into 1021
bugs, particularly when the bugs don't even specify that they are
SeaMonkey related. Example & picking the first bug on the list:

https://bugzilla.mozilla.org/show_bug.cgi?id=204697

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a)
Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a)
Gecko/20030401

This is a 2003 bug opened against the "Mozilla Application Suite" -
meaning 1.4a which is no longer supported. It was last touched in 2006.

Why on earth would anyone (user or developer) take time to explore the
bug any further? If the bug hasn't been touched in 180 days or so, then
close it out. Anyone with interest can reopen if they've new information
to add.

To make life easier, it would be of tremendous help if SeaMonkey were
now identified as the actual "Product".

Product: Mozilla Application Suite

only leads to folks stumbling on bugs such as listed above and wasting
everyone's time. Further, add a Version classifier so that folks can
easily see what revision of SM the bug is related to.


Product: SeaMonkey
Version: 1.1.x

Bugzilla should move into the modern ages and make it easier to search
and comment on bugs. It should also now classify SeaMonkey as a product.

Justin Wood (Callek)

unread,
Mar 21, 2008, 11:05:50 PM3/21/08
to
NoOp wrote:
> On 03/21/2008 05:39 PM, Robert Kaiser wrote:
> I think that if you want folks to assist you need to regroup and
> classify by feature/event.

Pending Bugzilla Reorg

> I for one wouldn't want to venture into 1021
> bugs, particularly when the bugs don't even specify that they are
> SeaMonkey related. Example & picking the first bug on the list:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=204697
>
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a)
> Gecko/20030401
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a)
> Gecko/20030401
>
> This is a 2003 bug opened against the "Mozilla Application Suite" -
> meaning 1.4a which is no longer supported. It was last touched in 2006.

It is also a bug that was opened as filed against a codebase we
inherited when we started development on a project called "SeaMonkey",
there are parts of the code base still in use that are even older than
2006 (in terms of last time they were touched).

> Why on earth would anyone (user or developer) take time to explore the
> bug any further? If the bug hasn't been touched in 180 days or so, then
> close it out. Anyone with interest can reopen if they've new information
> to add.

Because it could still be a valid bug. I know of some bugs that are
definately valid and may not have been touched in 180 days.

> To make life easier, it would be of tremendous help if SeaMonkey were
> now identified as the actual "Product".
>
> Product: Mozilla Application Suite
>

Also pending bugzilla reorg.

> only leads to folks stumbling on bugs such as listed above and wasting
> everyone's time. Further, add a Version classifier so that folks can
> easily see what revision of SM the bug is related to.
>
>
> Product: SeaMonkey
> Version: 1.1.x
>

Version is a field in the bug reports, but just because a bug is filed
with SeaMonkey 1.1 and exists there, does NOT mean it is fixed in trunk
(SeaMonkey 2) code; nor does it mean we need (or should) file the bug a
second time just for trunk.

> Bugzilla should move into the modern ages and make it easier to search
> and comment on bugs. It should also now classify SeaMonkey as a product.

Eas*ier*, well maybe you should poke with the webtool developers and
figure out how to make those parts easier. I for one find them fairly
easy on both counts.

--
~Justin Wood (Callek)

P.S. please respect the followup-to!

NoOp

unread,
Mar 22, 2008, 12:05:42 AM3/22/08
to

But is it? That is my point. It is certainly possible that the bug
hasn't been touched in 180 days due to lack of a developer or a user
looking at it. However the bug shows:

Severity: major

Well, if a major bug hasn't been touched since 2006 I reckon that it's
dead. You don't expect a user to clear it (they can't), nor a developer
after 2 years do you?

The correct procedure is to send an email to the original opener of the
bug and last 'assigned to' and ask them if the bug is still open. If no
response, or they consider it closed/fixed, then close it. Don't waste
people's time trying to figure out if a 5-2 year old bug is still valid.

Example: start at the top of that 1021, and this particular bug. Should
you have time on your hands, how would you go about commenting and/or
even providing a status on the bug?

- Would you load up an old copy of rv:1.4a) Gecko/20030401 and test?
- Would you, if you had an IMAP account, test with that against 1.1.8 or
1.1.9?

I suppose it's possible. But point being is that to do so, and check
each 1021 on the list will most likely take to the end of the year.

>
>> To make life easier, it would be of tremendous help if SeaMonkey were
>> now identified as the actual "Product".
>>
>> Product: Mozilla Application Suite
>>
>
> Also pending bugzilla reorg.

And that has been how long now? I've used Netscape (I have my original
paid license paperwork) to SeaMonkey and in all those years I've not seen a:

Product: SeaMonkey

>
>> only leads to folks stumbling on bugs such as listed above and wasting
>> everyone's time. Further, add a Version classifier so that folks can
>> easily see what revision of SM the bug is related to.
>>
>>
>> Product: SeaMonkey
>> Version: 1.1.x
>>
>
> Version is a field in the bug reports, but just because a bug is filed
> with SeaMonkey 1.1 and exists there, does NOT mean it is fixed in trunk
> (SeaMonkey 2) code; nor does it mean we need (or should) file the bug a
> second time just for trunk.

It doesn't matter. If there were a proper version field and/or range
(1.1x 2.x) then at least folks could sort and find a bug in their
appropriate version. Currently you can't find anything; you wade through
product "Mozilla Application Suite" and hope to hit on something that
relates to your problem. After several pages of unrelated you/I give up
and say to heck with it.

I disagree. When you have a serious makeover, 1.1x v 2.x then separate
bugs should indeed be filed for the different trunks/builds/versions
whatever you wish to call them. To commingle bug reports of considerably
different builds (no matter how poorly represented by the reporting
system) is not helpful to the user or developer. To do so is akin to
commingling original Netscape bugs with existing SeaMonkey bugs.

>
>> Bugzilla should move into the modern ages and make it easier to search
>> and comment on bugs. It should also now classify SeaMonkey as a product.
>
> Eas*ier*, well maybe you should poke with the webtool developers and
> figure out how to make those parts easier. I for one find them fairly
> easy on both counts.
>

Here is an easy example: try to find a bug related to SeaMonkey (or
anything Mozilla) and the ability to filter newsgroup headers by message
header. Go ahead:

https://bugzilla.mozilla.org/query.cgi

Now unless someone actually tells you that it is:

https://bugzilla.mozilla.org/show_bug.cgi?id=16913

you most likely won't find it.

FWIW: the bug isn't fixed. It fails on duplicate headers within a
message, example:

Delivered-To: mailing list us...@openoffice.org
Delivered-To: moderator for us...@openoffice.org

the patch triggers on the first "Delivered-To" header and ignores the
second.

Justin Wood (Callek)

unread,
Mar 22, 2008, 12:28:19 AM3/22/08
to

This is why we are asking for help. And as KaiRo said, test with the
current *trunk* build (or at least 1.1.x). I do *not* expect anyone to
test with Mozilla Suite 1.x let alone 1.4.x As those bugs would not be
fixed for that version.

>>> To make life easier, it would be of tremendous help if SeaMonkey were
>>> now identified as the actual "Product".
>>>
>>> Product: Mozilla Application Suite
>>>
>> Also pending bugzilla reorg.
>
> And that has been how long now?

Quite a while, but progress is going, and it is a lot of work (and has
to happen outside of the major Firefox release pushing). And benefits
more than just us.

> I've used Netscape (I have my original
> paid license paperwork) to SeaMonkey and in all those years I've not seen a:
>
> Product: SeaMonkey
>

Thats because, in bugzilla, it doesn't exist yet.

>>> only leads to folks stumbling on bugs such as listed above and wasting
>>> everyone's time. Further, add a Version classifier so that folks can
>>> easily see what revision of SM the bug is related to.
>>>
>>>
>>> Product: SeaMonkey
>>> Version: 1.1.x
>>>
>> Version is a field in the bug reports, but just because a bug is filed
>> with SeaMonkey 1.1 and exists there, does NOT mean it is fixed in trunk
>> (SeaMonkey 2) code; nor does it mean we need (or should) file the bug a
>> second time just for trunk.
>
> It doesn't matter. If there were a proper version field and/or range
> (1.1x 2.x) then at least folks could sort and find a bug in their
> appropriate version. Currently you can't find anything; you wade through
> product "Mozilla Application Suite" and hope to hit on something that
> relates to your problem. After several pages of unrelated you/I give up
> and say to heck with it.

If you have problems with bugzilla searching, talk to bugzilla devs. If
you want to make us all re-file bugs for trunk builds when a bug filed
from a release build also applies to trunk, well then, you're talking to
the wrong crowd. As we don't have the manpower, and I don't think it
makes sense with the software we use.

If you are advocating a software feature, this is the wrong crowd again.

> I disagree. When you have a serious makeover, 1.1x v 2.x then separate
> bugs should indeed be filed for the different trunks/builds/versions
> whatever you wish to call them. To commingle bug reports of considerably
> different builds (no matter how poorly represented by the reporting
> system) is not helpful to the user or developer. To do so is akin to
> commingling original Netscape bugs with existing SeaMonkey bugs.

It *is* helpful, because the code the bug reports are regarding have not
changed (or changed little enough to still [potentially] be a bug that
needs fixing) this potentially is what KaiRo's request for help is about.

>>> Bugzilla should move into the modern ages and make it easier to search
>>> and comment on bugs. It should also now classify SeaMonkey as a product.
>> Eas*ier*, well maybe you should poke with the webtool developers and
>> figure out how to make those parts easier. I for one find them fairly
>> easy on both counts.
>>
>
> Here is an easy example: try to find a bug related to SeaMonkey (or
> anything Mozilla) and the ability to filter newsgroup headers by message
> header. Go ahead:
>
> https://bugzilla.mozilla.org/query.cgi
>
> Now unless someone actually tells you that it is:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=16913
>
> you most likely won't find it.
>

I am willing to bet I could have found it, but since you provided the
bug# I surely would not have proven it to you (so haven't tried).

--
~Justin Wood (Callek)

Chris Ilias

unread,
Mar 22, 2008, 12:58:22 AM3/22/08
to
On 3/22/08 12:05 AM, _NoOp_ spoke thusly:

> On 03/21/2008 08:05 PM, Justin Wood (Callek) wrote:
>
>> Also pending bugzilla reorg.
>
> And that has been how long now? I've used Netscape (I have my original
> paid license paperwork) to SeaMonkey and in all those years I've not seen a:
>
> Product: SeaMonkey

Back when you had to pay for Netscape, there was no bugzilla, let alone
SeaMonkey. :-)

The SeaMonkey project (to continue the Mozilla Suite) is only around
three years old, and shortly after that, a bug was filed for renaming
the product in bugzilla.
<https://bugzilla.mozilla.org/show_bug.cgi?id=298904>

At some point last summer, it was decided that all these bug would be
addressed in on big re-org.
<http://groups.google.com/group/mozilla.dev.planning/msg/998d54b31737197f>

At the end of last month, Gerv indicated that the re-org would be
happening after Firefox 3 ships.
<http://weblogs.mozillazine.org/gerv/archives/2008/02/fosdem_writeup_1.html>

--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia

Andrew Schultz

unread,
Mar 22, 2008, 1:01:22 AM3/22/08
to
NoOp wrote:
> But is it? That is my point. It is certainly possible that the bug
> hasn't been touched in 180 days due to lack of a developer or a user
> looking at it. However the bug shows:
>
> Severity: major
>
> Well, if a major bug hasn't been touched since 2006 I reckon that it's
> dead. You don't expect a user to clear it (they can't), nor a developer
> after 2 years do you?

Perhaps it's simply not major...

> The correct procedure is to send an email to the original opener of the
> bug and last 'assigned to' and ask them if the bug is still open. If no
> response, or they consider it closed/fixed, then close it. Don't waste
> people's time trying to figure out if a 5-2 year old bug is still valid.

Well, you could comment in the bug. That seems better (and easier!)
than sending email.

> Example: start at the top of that 1021, and this particular bug. Should
> you have time on your hands, how would you go about commenting and/or
> even providing a status on the bug?
>
> - Would you load up an old copy of rv:1.4a) Gecko/20030401 and test?

no... that'd be a bit silly.

> - Would you, if you had an IMAP account, test with that against 1.1.8 or
> 1.1.9?

Yes, that'd be a start. Testing trunk would get you a gold star. :)

> I suppose it's possible. But point being is that to do so, and check
> each 1021 on the list will most likely take to the end of the year.

Yes, it would certainly take one person a long time. A year seems a bit
extreme (10 minutes to test, 30 minutes a day would take a year). But
there is (hopefully) more than one person who can work on bug triage.
Some bugs will be very quick because you can't test or the reporter
simply didn't provide enough information. Bugs that take longer are
typically the ones that seem to be valid. But spending time on valid
bugs... is a good thing. :)

> It doesn't matter. If there were a proper version field and/or range
> (1.1x 2.x) then at least folks could sort and find a bug in their

There is a version field.
version=1.8 = SeaMonkey 1.1
version=trunk = SeaMonkey 2.x

> I disagree. When you have a serious makeover, 1.1x v 2.x then separate
> bugs should indeed be filed for the different trunks/builds/versions
> whatever you wish to call them. To commingle bug reports of considerably
> different builds (no matter how poorly represented by the reporting
> system) is not helpful to the user or developer. To do so is akin to
> commingling original Netscape bugs with existing SeaMonkey bugs.

Much of SeaMonkey code in 2.0.x is somewhat similar to what was in
1.1.x. Other parts have been rewritten and still other parts replaced
with what's in toolkit. For instance, bugs in our old form manager
(which we don't use any more at all) can die a swift death, unless
they're critical bugs that should be fixed in 1.1.x. But valid tabbed
browser bugs from 1.1.x are very likely to be valid unless we've
explicitly fixed fix them on trunk.

> Here is an easy example: try to find a bug related to SeaMonkey (or
> anything Mozilla) and the ability to filter newsgroup headers by message
> header. Go ahead:
>
> https://bugzilla.mozilla.org/query.cgi

OK.
https://bugzilla.mozilla.org/query.cgi?format=advanced
select Product=Core
select all the Mailnews components
for Summary, choose "contains all the words/strings" and enter "header
news filter" in the textbox
Unselect all Resolutions

==> 5 bugs, one of which is the bug you wanted

If you were using the simple query, searching Closed bugs in Core for
"header news filter" gives me 200 bugs. The bug of interest is second
in that list.

> Now unless someone actually tells you that it is:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=16913
>
> you most likely won't find it.
>
> FWIW: the bug isn't fixed. It fails on duplicate headers within a
> message, example:
>
> Delivered-To: mailing list us...@openoffice.org
> Delivered-To: moderator for us...@openoffice.org
>
> the patch triggers on the first "Delivered-To" header and ignores the
> second.

It sounds like the bug is fixed for some cases and not others. The
patch was 50KB (quite large) even to fix the simpler cases... it's not
really realistic to expect a patch for a new feature to handle every
case initially. Your best bet is to file a followup bug and CC Joshua.

--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/

Robert Kaiser

unread,
Mar 22, 2008, 8:17:56 AM3/22/08
to
NoOp wrote:
> The correct procedure is to send an email to the original opener of the
> bug and last 'assigned to' and ask them if the bug is still open. If no
> response, or they consider it closed/fixed, then close it.

Actually, the correct way is to do this via a bugzilla comment, which
sends email to the reporter _and_ shows others that the reporter was
contacted.

And exactly this is what I'm asking people to do. Either verify
themselves that a bug is still valid or not valid any more or comment an
the bug asking the reporter to re-test and then resolve if no word is
heard back.

I expect that a good number of those bugs _are_ still valid, but we
should find out which are and which aren't.

Robert Kaiser

Robert Kaiser

unread,
Mar 22, 2008, 8:18:38 AM3/22/08
to
Tony Mechelynck wrote:
> Count me in. This way I may perhaps use my new "editbugs" privilege for
> some useful purpose. :-)

Cool, feel free to start working on the list, every bug we can strike
off is a good thing!

Robert Kaiser

Robert Kaiser

unread,
Mar 22, 2008, 8:22:54 AM3/22/08
to
NoOp wrote:
> To make life easier, it would be of tremendous help if SeaMonkey were
> now identified as the actual "Product".
>
> Product: Mozilla Application Suite
>
> only leads to folks stumbling on bugs such as listed above and wasting
> everyone's time. Further, add a Version classifier so that folks can
> easily see what revision of SM the bug is related to.
>
> Product: SeaMonkey

That's planned with the Bugzilla reorganization, but this has been
pushed out by the relevant people for more than a year now, so I decided
to go forward and start with this even before that reorganization is
done. We inherited a lot of those bugs in any case, and will have them
in the our database, whenever the reorg is going to happen. The sooner
we can clean out potentially invalid bugs, the better, so developers can
work with the database more seriously.

Robert Kaiser

Nelson Bolyard

unread,
Mar 22, 2008, 1:51:57 PM3/22/08
to
NoOp wrote, On 2008-03-21 19:26:

> This is a 2003 bug opened against the "Mozilla Application Suite" -
> meaning 1.4a which is no longer supported. It was last touched in 2006.
>
> Why on earth would anyone (user or developer) take time to explore the
> bug any further? If the bug hasn't been touched in 180 days or so, then
> close it out. Anyone with interest can reopen if they've new information
> to add.

There are literally HUNDREDS of bugs that were filed more than 2 years
ago that are still very much present in SM today. Quite a few have
5-digit numbers! Many of them have not been touched in a long time,
simply because there is no one to work on them, and the bugs are already
sufficiently well-described that there's nothing of value to add.

The bug you cite has been experienced by 5 separate people who have
commented on it in the bug. The fact that it is not yet marked
confirmed is a testament to the understaffing of mail/news, IMO.

I would oppose a wholesale effort to discard old mail/news bugs, except
in the event of a wholesale effort to discard mail/news.

I am particularly disturbed by the fact that "mailco" is focused on new
features, considering that the existing code base is such a wreck.
Closing old bugs will surely not help that problem.

> To make life easier, it would be of tremendous help if SeaMonkey were
> now identified as the actual "Product".
>
> Product: Mozilla Application Suite
>
> only leads to folks stumbling on bugs such as listed above and wasting
> everyone's time.

The bug you cited above is NOT a waste of time. Closing it would waste
the time that was spent on it, and would probably lead to a duplicate
being filed.

/Nelson (+112998/62935)

Simon Paquet

unread,
Mar 22, 2008, 2:38:41 PM3/22/08
to
Nelson Bolyard wrote on 22. Mar 2008:

> I am particularly disturbed by the fact that "mailco" is focused on
> new features, considering that the existing code base is such a wreck.
> Closing old bugs will surely not help that problem.

How does the current issue (evaluation of old SeaMonkey bugs) relate to
Mozilla Messaging's mail efforts? I really don't see any connection
here.

Simon

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar

Tony Mechelynck

unread,
Mar 22, 2008, 3:16:06 PM3/22/08
to
Nelson Bolyard wrote:
[...]

> There are literally HUNDREDS of bugs that were filed more than 2 years
> ago that are still very much present in SM today. Quite a few have
> 5-digit numbers! Many of them have not been touched in a long time,
> simply because there is no one to work on them, and the bugs are already
> sufficiently well-described that there's nothing of value to add.
>
> The bug you cite has been experienced by 5 separate people who have
> commented on it in the bug. The fact that it is not yet marked
> confirmed is a testament to the understaffing of mail/news, IMO.
>
> I would oppose a wholesale effort to discard old mail/news bugs, except
> in the event of a wholesale effort to discard mail/news.
[...]

The way I see it, the present effort is not to discard old Suite bugs
wholesale, be they mail/news, browser or other, but to:

1) look at them one by one.
-- Many years-old bugs have been forgotten by their own
reporters, just because there was no traffic on them, hence no
bugmail.

2) try to find out if current builds are still affected by them.
-- Some are. Many aren't.

3) if "we" (tinw) can't answer (2), ask the reporter.
-- I just got a comment from a reporter saying: "Thanks for
looking at these old bugs". The reporter also resolved that bug
WORKSFORME.

4) If the reporter was asked to provide more info, and didn't, resolve
INCOMPLETE.
-- If the info finally arrives, we can always REOPEN.

And so on. The fact that each bug is looked at severally makes IMHO the
process retail. (Launching a batch process to mass-resolve these old
bugs would "discard them wholesale", but, AFAIK, no one is seriously
advocating such a mass process at the moment.)


Best regards,
Tony.
--
All the taxes paid over a lifetime by the average American are spent by
the government in less than a second.
-- Jim Fiebig

Robert Kaiser

unread,
Mar 23, 2008, 7:33:56 AM3/23/08
to
Tony Mechelynck schrieb:

> The way I see it, the present effort is not to discard old Suite bugs
> wholesale, be they mail/news, browser or other, but to:
>
> 1) look at them one by one.
> -- Many years-old bugs have been forgotten by their own
> reporters, just because there was no traffic on them, hence no
> bugmail.
>
> 2) try to find out if current builds are still affected by them.
> -- Some are. Many aren't.
>
> 3) if "we" (tinw) can't answer (2), ask the reporter.
> -- I just got a comment from a reporter saying: "Thanks for
> looking at these old bugs". The reporter also resolved that bug
> WORKSFORME.
>
> 4) If the reporter was asked to provide more info, and didn't, resolve
> INCOMPLETE.
> -- If the info finally arrives, we can always REOPEN.
>
> And so on.

Exactly. And if you can confirm the bug is still present, esp. in trunk
builds, confirm them and change their state to "new".

Robert Kaiser

Robert Kaiser

unread,
Mar 23, 2008, 7:38:19 AM3/23/08
to
Nelson Bolyard schrieb:

> The bug you cited above is NOT a waste of time. Closing it would waste
> the time that was spent on it, and would probably lead to a duplicate
> being filed.

1) If it is a general mailnews bug, and not just a bug in
SeaMonkey-specific code, then it is misfiled, it should move into Core's
MailNews components instead.

2) If it is still a valid bug and can be seen by other as you imply, it
should not be UNCONFIRMED, and the right thing to do in this effort that
I've proposed here is to confirm it and change its state to NEW.

From what you imply, esp. with making Mozilla Messaging responsible,
both actions might be appropriate for this bug. And you obviously don't
know what work is actually going on or you wouldn't blindly imply that
the problems in mailnews codebase aren't being worked on.

Robert Kaiser

Tony Mechelynck

unread,
Mar 23, 2008, 8:14:33 AM3/23/08
to

Yes, I forgot to mention this explicitly, but in my mind it was part of
step 2 if current builds are indeed affected by the bug.

Also, if we can ascertain that the bug is a duplicate of some other bug
we know, find which one (maybe by looking in the "My Votes" page, or by
some well-chosen search), double-check that they are the same, and if
they are, resolve DUPLICATE.

Best regards,
Tony.
--
Surprise your boss. Get to work on time.

V Leher

unread,
Mar 23, 2008, 11:32:59 AM3/23/08
to
Robert Kaiser wrote:
>
> Exactly. And if you can confirm the bug is still present, esp. in trunk
> builds, confirm them and change their state to "new".
>
> Robert Kaiser

The trunk builds are the 2.0alpha builds...is that correct ?

- Leher

Edward

unread,
Mar 23, 2008, 12:13:45 PM3/23/08
to

Tony went through some of mine. I searched and found 13 that I opened,
the older bugs with issues that had corrected themselves over time have
all been closed. Other issues relating to SeaMonkey 2.0 (and one where
the issue in SM 1.1.x remains), I kept open.

Thanks again, Tony.

Ed

Justin Wood (Callek)

unread,
Mar 23, 2008, 12:58:12 PM3/23/08
to

Correct.

--
~Justin Wood (Callek)

Wayne Mery

unread,
Mar 25, 2008, 6:36:38 AM3/25/08
to
On 3/22/2008 1:51 PM, Nelson Bolyard wrote:
> NoOp wrote, On 2008-03-21 19:26:
>
>> This is a 2003 bug opened against the "Mozilla Application Suite" -
>> meaning 1.4a which is no longer supported. It was last touched in 2006.
>>
>> Why on earth would anyone (user or developer) take time to explore the
>> bug any further? If the bug hasn't been touched in 180 days or so, then
>> close it out. Anyone with interest can reopen if they've new information
>> to add.
>
> There are literally HUNDREDS of bugs that were filed more than 2 years
> ago that are still very much present in SM today. Quite a few have
> 5-digit numbers! Many of them have not been touched in a long time,
> simply because there is no one to work on them, and the bugs are already
> sufficiently well-described that there's nothing of value to add.
>
> The bug you cite has been experienced by 5 separate people who have
> commented on it in the bug. The fact that it is not yet marked
> confirmed is a testament to the understaffing of mail/news, IMO.

I think Bug 204697 – Offline IMAP folders are not sync'ed - suffers more
from the fate of being misfiled in seamonkey. This is not a slam on
seamonkey, but there's not many people looking at old SM bugs.

There are hundreds of such bugs in product seamonkey - and as far as I
can see this condition is not the fault of the current owners of
Seamonkey nor Thunderbird. But a triage effort by the Seamonkey folk,
which appears to be starting, can help resolve this state of affairs.
Perhaps a case could also be made for a Thunderbird bugday to address
some of issues currently misfiled in Seamonkey.


> I am particularly disturbed by the fact that "mailco" is focused on new
> features, considering that the existing code base is such a wreck.

Perhaps you are only reading the press and the big features pages. Bugs
are still being fixed. And planning meetings publicly show there is
much more happening than big features
http://wiki.mozilla.org/Thunderbird/StatusMeetings


> Closing old bugs will surely not help that problem.

On the contrary, closing old bugs that are not useful helps focus
efforts on old bugs that are useful - many of which are about
infrastructure.

0 new messages