SeaMonkey/Bug events/20120921

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:

•  733 MailNews:Message Display
•  476 UI Design
•  228 Bookmarks & History
•  165 Preferences
•  141 Composer
•  127 General
• 1870 All of the above

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.
  • If you think you can fix some particular bugs, "take" them by clicking <take> on the Assigned to: line in the bug header, and also set the bug status to ASSIGNED at the very bottom.
  • Don't try to tackle too many of them at one time: By assigning a bug to yourself, you are committing yourself to work on it, and you are also telling other people that the bug is taken. Better take no more than you can handle, fix them, and possibly come later for additional bugs after you finish those you had taken.
  • See also:
    • The Life Cycle of a Patch
    • Getting comm-central source code using Mercurial
    • Getting mozilla-central with limited bandwidth
    • Mercurial bundles for Mozilla
    • Creating a patch that can be checked in
    • and other pages linked from there. Also don't forget to use hg help to get the Mercurial online help.

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

• 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.