Personal tools

SeaMonkey/Bug events/20120921

From MozillaWiki

Jump to: navigation, search
The SeaMonkey community will hold a bug event during the 2012 fall equinox weekend. The details (the agenda, and, once known, the results) are to be found below.
If this whole page is too long for you, please read at least the table of contents. Maybe you'll be interested in one particular section.

Contents

When?

From Friday 21 to Sunday 23 September 2012. We're setting no fixed times: come as soon as you can (e.g., after getting home from work and kissing your best half and kids) and remain as late as you want to (e.g. until you're called to the dining-room or to bathe, *** and sleep).

Where?

Channel #bugday on the Mozilla IRC server. If you're using ChatZilla, just click the link. Or for any chat client:

  1. Connect to irc.mozilla.org on port 6667 (without SSL) or on port 6697 (with SSL).
  2. (Optional) IDENTIFY yourself to NickServ with a password. (See /msg NickServ help for details)
  3. /join #bugday

Before you start

  • Make sure you have a supported computer and operating system.
  • Make sure you have a Bugzilla account (and if you don't yet have one, get one here).
  • Install the latest SeaMonkey nightly but not in the same directory as your usual "release" version of SeaMonkey (unless, of course, it is already "your usual SeaMonkey" or you want to make it such; but beware that such a practice is "not recommended for most users". How to install it varies depending on your OS.
  • Notes:
    • "Mac" builds are "Universal builds" supporting both 32- and 64-bit Mac computers with Intel processors running Mac OS X 10.5 or later. OS X 10.4 is not supported anymore, and neither are PowerPC computers.
    • There are separate "Linux" builds for 32-bit (i686) and 64-bit (x86_64) systems. 32-bit builds can run on 64-bit systems (if you have the necessary 32-bit libraries installed) but not vice-versa. The 64-bit builds are still regarded as "experimental" because there are still few testers using them: a chicken-and-egg problem. If you have a 64-bit Linux system, maybe you can help us by testing the x86_64 Linux build.
    • For Windows, only 32-bit builds are available at this time. They ought to run correctly on both 32- and 64-bit Windows computers.
    • A full list of hardware and software requirements for Windows, Linux and Mac can be found here.
  • Start your new SeaMonkey as follows (at a command-line [shell] prompt, after cd to the directory containing the executable):
    ./seamonkey -no-remote -ProfileManager
    The first time, create a new profile then use it. Later on, you can just reuse that same profile.

What?

Add [2012 Fall Equinox] to the Whiteboard of any bug handled during the event, even if no other change is made to it.

Which bugs to focus on

This table tells you how many bugs are open but not yet ASSIGNED for each SeaMonkey component. Each of the numbers in the table is a link to a list of bugs. This time we'll concentrate on the Components which have the most open bugs (more than 100 to more than 700). They are listed below in decreasing order ("more than 700 at top, down to "just over 100" at bottom). The numbers are as of 2012-08-07 16:00 UTC:

What to do with them

Now what shall we do with all these bugs?

Triage

  • Is the bug in the right Component? or even in the right Product? Bugs which affect SeaMonkey can belong in any of the following Products (clicking each link will give you a list of Components, explaining briefly what each of them is for). Most SeaMonkey bugs go in the Products near the top of this list:
    • SeaMonkey (anything specific to SeaMonkey, and all SeaMonkey frontend bugs other than those for the Addons Manager)
    • MailNews Core (backend bugs affecting both SeaMonkey and Thunderbird)
    • Toolkit (This includes, among others, all Addon Manager bugs, the bugs for the Firefox-style Download Manager but not the Jökulsárlón one, Password Manager bugs, etc.)
    • Core (backend bugs affecting all three of Firefox, Thunderbird and SeaMonkey, especially about HTML page layout)
    • Plugins (i.e. Acrobat, Flash, Java, and the like)
    • Other Applications (among others, ChatZilla, DOM Inspector and Venkman, all three of which are included in all official versions of SeaMonkey)
    • Mozilla Localizations (bugs about menus & messages in other languages than en-US)
    • NSS and NSPR (these two change very little, only very few new bugs belong in them)
  • Is the bug still found in current SeaMonkey versions (latest release, latest beta, latest Aurora nightly, latest comm-central-trunk nightly)? If you can't decide, and neither can anyone present, add a comment to the bug asking the reporter, and in that case also add [CLOSEME 2012-11-01 INCO] or [CLOSEME 2012-11-01 WFM] to the Whiteboard.
  • Is the bug a valid bug? If the behaviour it describes is intentional, then the bug is INVALID. If the problem is not a Mozilla problem (if the fault is in an extension, or in the code for some plugin, etc.) the bug is also INVALID but in this case the problem should be reported to the responsible party (the extension author, the plugin makers, etc.)
  • Is the bug a real bug or enhancement request, but one not worth fixing? Only an owner or peer of the component where the bug is found can decide to resolve it WONTFIX. Check the SeaMonkey project areas page and/or the Mozilla module owners list to see who is in charge. Hopefully some of them will take part in the event so you can ping them.

Bug fixing

  • Finally, do you think you can fix the bug? Don't panic!. Some of them, including very easy one-liners, will have [good first bug] in the Whiteboard, usually with [language= (meaning the programming language) and [mentor= (with the IRC nick of someone to ask help from); and even if you aren't yet capable of fixing any single bug, all the above will still need to be done.

Resolving bugs

Here are the main Resolutions you will probably use. (There are others.)

  • DUPLICATE — This bug is a duplicate of some other bug, whose bug number must be mentioned.
  • INCOMPLETE — The steps to reproduce are either nonexistent or too vague to allow reproducing the bug, and the reporter hasn't replied to requests for further information.
  • INVALID — This is either intended behaviour ("not a bug") or else it is a bug but not in Mozilla code ("not our bug")
  • WORKSFORME — All attempts to reproduce the bug have failed; or the bug used to be found in earlier versions but it has disappeared from current versions, and we don't know what fixed it.
  • FIXED — The bug has been fixed in trunk code, and we know exactly which patch fixed it.
  • WONTFIX — Only an Owner or Peer for the relevant Module may set this Resolution, see below.
  • Also, the VERIFIED status means that someone other than whoever set RESOLVED has checked that the Resolution is correct. For FIXED bugs, this means in principle that someone (not necessarily the same person) has verified that in recent builds, the bug has disappeared from all three of Windows, Linux and Mac, or at least from those of the three where the bug had been seen before.

Whiteboard entries

  • As said earlier, please mark all bugs handled during this Event by adding [2012 Fall Equinox] to the Whiteboard. One of the entries below may be added in addition if it is not clear that the bug should be RESOLVED immediately.
    • DUPEME — you remember seeing a bug somewhere, of which this bug is a duplicate, but you can't find the other bug back.
    • [CLOSEME 2012-11-01 INCO] — bugs to be RESOLVED INCOMPLETE if the reporter doesn't answer.
    • [CLOSEME 2012-11-01 WFM] — bugs to be RESOLVED WORKSFORME unless someone can reproduce them (and say how, or at least say that it appears sporadically in such-and-such circumstances)
    • [CLOSEME INVA/WONT?] — bugs which might possibly be one of the following, but you aren't certain:
      • Intended behaviour (INVALID)
      • Not a Mozilla bug (INVALID)
      • Not worth fixing (WONTFIX)
      • Notes:
        • 1. As said earlier, only an owner or peer of the concerned module may set WONTFIX so you may want to bring such a bug to their attention. To find who they are, follow the following links for SeaMonkey in particular or for Mozilla code in general.
        • 2. Some developers have a "Bugzilla address of record" different from their listed email address. Make sure that you have JavaScript enabled (at least on bugzilla.mozilla.org), and use the Bugzilla autocomplete feature in the Cc field of the bug.

Tracking flags

Here we'll talk only about the "status-seamonkey-<something>" flags. These are on the right side of the bug page heading, lower than the Cc list. They are used to track in which versions of SeaMonkey the bug has been seen, and also on which branch it has been fixed. (RESOLVED FIXED means the bug is fixed on trunk, even if the fix hasn't yet been ported to the branches.)

  • unaffected : the bug never occurred in this version.
  • affected : the bug happens in the latest builds for this version.
  • fixed : the bug has been fixed in this version.
  • verified : someone has checked that the fix works for this version in all affected platforms.
  • wontfix : the fix won't be ported to this version. In particular, anything involving string changes will never be landed in a branch other than by the sesquimestrial repository merge. Also, only no-risk fixes will be ported to the Beta branch and only stability & security fixes will be ported to the Release branch.
  • --- (default): none of the above, or unknown, or unspecified.

Results

Where did those bugs end up?

This set of tables tell you where the bugs handled during this event ended up. Remember: before the event, they were (almost) all in the "SeaMonkey" product, and none (or hardly any) of them was either ASSIGNED or RESOLVED.

Each of the numbers in the table can be clicked to list all the bugs in question in the form of a Bugzilla bug search, and the tables will be updated if you refresh the page and more bugs have been triaged, assigned and/or fixed.

Good first bugs

Also, these bugs were found (or confirmed) to be "good first bugs" (but there are more).

Who did what?

Rankings

Px 257 bugs 89.24%
Ratty 44 bugs 15.28%
tonymec 22 bugs 7.64%
lenochod 20 bugs 6.94%
mcsmurf 8 bugs 2.78%
Neil 8 bugs 2.78%
InvisibleSmiley 6 bugs 2.08%
IanN 3 bugs 1.04%
KaiRo 3 bugs 1.04%
BenB 2 bugs 0.69%
Aleksej 1 bug 0.35%
bz 1 bug 0.35%
dbaron 1 bug 0.35%
F.Miata 1 bug 0.35%
gerv 1 bug 0.35%
J.Roderburg 1 bug 0.35%
Matti 1 bug 0.35%
Mnyromyr 1 bug 0.35%
NoOp 1 bug 0.35%
rsx11m 1 bug 0.35%
RyanVM 1 bug 0.35%
stefanh 1 bug 0.35%
therube 1 bug 0.35%
  • The total exceeds 100% because some bugs were handled by several people (up to 5 people on one bug).
  • In addition to the above, 6 bugs got a new comment by their respective reporters, which helped to ascertain the bug's status.


Detailed breakout

The magic button is the [show] or [hide] button in the top-left cell.

Click the column headings to sort (the "Severity" column sorts in logical, not alphabetical, sequence). To sort on several columns, sort last on the major key.