Bug 1092632 (Sm_tri_HowTo)

Document how to triage SeaMonkey bugs

RESOLVED FIXED

Status

defect
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: tonymec, Assigned: tonymec)

Tracking

({user-doc-complete})

Firefox Tracking Flags

(Not tracked)

Details

()

The need for this documentation has been repeatedly asserted at the fortnightly SeaMonkey status meetings (in #seamonkey channel on the moznet IRC network every second Tuesday at 14:00 Central European summer or winter time: depending on season, 13:00 GMT or BST, 13:00 or 12:00 UTC) and I've been charged with writing it up.

I'm starting this bug according to the principle, "At Mozilla, anything that has to be done gets a BMO bug — even if it's «fix headquarters coffee machine»". I'm starting the CC list with the names of #seamonkey regulars. Don't hesitate to remove yourself if you're not interested — or conversely, anyone interested may join.

I've started this bug in "Websites::www.seamonkey-project.org" but maybe the final docs should go somewhere at MozillaWiki instead; the latter would allow using Wikimedia syntax, which would make kinks to other Mozillawiki pages easier. Until there is a decision on this subject, I'll put my WIP docs at some place where I can write and anyone can read; that temporary URL will be announced once I start writing the docs.
I'll start with the text at https://wiki.mozilla.org/index.php?title=SeaMonkey/Bug_events/20120921 with the exception of the first two sections (When? Where?) and the last one (Results). Then details specific to that particular bug event will have to be weeded out.

I have started the WIP page at https://wiki.mozilla.org/User:Tonymec/Triage_HowTo — This is the first step, with a new leading blurb and the three unneeded sections cut away but nothing else yet. Comments welcome but I'm not yet putting this up for review, it needs more work.

This is still in Wikimedia format; it will need some HTML-izing if the page's final location is on a non-Wikimedia site. I can do it, but not yet.
P.S. Keeping the WIP page on wikimoz gives us automagical history and diffs.
Ccing a couple of QA people from Firefox and Thunderbird.

Wayne, Aakash, you may (or may not) want to write (or have someone write) similar pages for Fx&Tb; if you do, or if they already exist, please post the URL in a comment. FWIW, I don't want to hold intellectual property on the text beyond that for "common Mozilla knowledge". Re-use it if you want.
I think the WIP page https://wiki.mozilla.org/User:Tonymec/Triage_HowTo is ready for a first review. Ratty, want to do it?

One thing still undecided in my mind is where the final version should go.
Flags: needinfo?(philip.chee)

Comment 5

5 years ago
That page should probably go into the SeaMonkey:... name space, unless it will be a page shared with other projects/applications. Looks good, some comments:

"Moving to the right Product / Component" - maybe we can address the issue of one bug or regression affecting multiple applications here (see bug 1092553 comment #3 and following). That specific case involved a single patch covering mail/, mailnews/, and suite/, thus the question here was if such bugs should be handled in MailNews Core (though not strictly being MailNews Core).

"Address Book" and "Account Manager" (except Account Wizard, which is separate for new mail accounts in Thunderbird) are MailNews Core, maybe worth a note there.

"[FIXED] In that case, the Target Milestone in the bug heading should be set to the branch where the bug was fixed (normally the branch which was "trunk" at the time of fixing, or possibly the lowest-numbered branch to which the fix was ported)." - this has been a point of confusion in the past. I think the rule is to make the Target Milestone the current trunk version or the /highest/ version where it was fixed (if trunk is not affected), and the branhc ports to the noted in the status flag (with the highest unaffected version marked as such, e.g., for regressions or new features that need to be caught up with).
(In reply to rsx11m from comment #5)
> That page should probably go into the SeaMonkey:... name space, unless it
> will be a page shared with other projects/applications. Looks good, some
> comments:
> 
> "Moving to the right Product / Component" - maybe we can address the issue
> of one bug or regression affecting multiple applications here (see bug
> 1092553 comment #3 and following). That specific case involved a single
> patch covering mail/, mailnews/, and suite/, thus the question here was if
> such bugs should be handled in MailNews Core (though not strictly being
> MailNews Core).

Finally it was found out that the same problem (as the one I reported for SeaMonkey) had been reported separately in the "Thunderbird" product; a couple of days later it got fixed there for both Thunderbird and SeaMonkey. If the Tb guys hadn't been so attentionate towards the Suite we would have had to port the mail/ parts into suite/. It ended up being one of the rare cases where two different bugs (not really duplicates, since the problem affected forked frontend sources) were FIXED by a single changeset which was mentioned on both sides — with different Milestones, viz. Tb 3.6 and Sm 2.33.

The Thunderbird assignee could conceivably have moved his bug to MailNews Core, in which case it would have been possible to dupe the SeaMonkey bug to it. But in that case we would have lost the ability to mention Sm 2.33 in a Milestone.
> 
> "Address Book" and "Account Manager" (except Account Wizard, which is
> separate for new mail accounts in Thunderbird) are MailNews Core, maybe
> worth a note there.

Noted. I'll remember this on my next round of edits.
> 
> "[FIXED] In that case, the Target Milestone in the bug heading should be set
> to the branch where the bug was fixed (normally the branch which was "trunk"
> at the time of fixing, or possibly the lowest-numbered branch to which the
> fix was ported)." - this has been a point of confusion in the past. I think
> the rule is to make the Target Milestone the current trunk version or the
> /highest/ version where it was fixed (if trunk is not affected), and the
> branhc ports to the noted in the status flag (with the highest unaffected
> version marked as such, e.g., for regressions or new features that need to
> be caught up with).

hm, we'll see what others say. I thought the Milestone meant "the bug is FIXED starting at this release". Maybe I was mistaken. Maybe the rules are different depending on the Product, which I would find confusing (I have definitely seen Milestones stepped down after porting a fix to Aurora, but I'm not sure in which Product it was).

Comment 7

5 years ago
(In reply to Tony Mechelynck [:tonymec] from comment #6)
> If the Tb guys hadn't been so attentionate towards the Suite we would have
> had to port the mail/ parts into suite/. It ended up being one of the rare
> cases where two different bugs (...) were FIXED by a single changeset

Actually, it happens more frequently than you may think. I've seen a couple of MailNews Core fixes which also contained a suite/ part.

> The Thunderbird assignee could conceivably have moved his bug to MailNews
> Core, in which case it would have been possible to dupe the SeaMonkey bug to
> it. But in that case we would have lost the ability to mention Sm 2.33 in a
> Milestone.

In the Milestone, yes, but MailNews Core bugs have status flags for both TB and SM.
Anyway, that's up for discussion, whichever way is preferred by either side.
My current computer is in extremely bad shape. Today I could only get it to boot and remain booted-up by selecting "Fan: Silent (minimum noise, may reduce CPU performance)" in the BIOS setup. I've seen a newer model downtown (not a brand-new one but newer than this one) and I'm gonna buy it as soon as the necessary 400€ or so land on my bank account. ETA (but remember the E means "estimated") between a few days and a week. In the meantime all my computer activities are in slow gear. If someone wants to ASSIGN this to himself, go ahead, otherwise I'll come back to it if and when. In the meantime Ratty's (or some QA owner's or peer's) opinion is still desired.
I have a new (faster and bigger) computer, and since the last Sunday in August I've even found out how to get it to connect to the Internet.

I think the wiki page is essentially finished but I badly need comments about it, preferably on its Talk page, or here if you can't get a mozwiki editor account. If you have one, don't hesitate to make changes in the page itself if you think everyone will agree to them: in particular, grammar, syntax and spelling fixes are welcome.
(In reply to Tony Mechelynck [:tonymec] from comment #9)
> I have a new (faster and bigger) computer, and since the last Sunday in
> August I've even found out how to get it to connect to the Internet.
> 
> I think the wiki page is essentially finished but I badly need comments
> about it, preferably on its Talk page, or here if you can't get a mozwiki
> editor account. If you have one, don't hesitate to make changes in the page
> itself if you think everyone will agree to them: in particular, grammar,
> syntax and spelling fixes are welcome.

Still no reaction. People, if you want this page moved somewhere else, please do it, or tell me.

I'm still willing to convert this from wikicode to "plain" HTML+CSS if the page needs to be moved to some non-Wikimedia site, but of course it won't be necessary if a place for it is found among the wikimo SeaMonkey pages.

Clearing the needinfo request; let anyone interested do it.
Assignee: antoine.mechelynck → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(philip.chee)

Comment 11

4 years ago
"Bug 1208822 - SeaMonkey System Requirements need update" affects this one because system requirements are linked in the triage manual.
See Also: → 1208822

Comment 12

4 years ago
I think that manual should be moved to the wiki to SeaMonkey/QA/Bug Triage immediately. 

I added some details.
(In reply to Rainer Bielefeld from comment #12)
> I think that manual should be moved to the wiki to SeaMonkey/QA/Bug Triage
> immediately. 

Well, I've been waiting for more than a month for some consensus about where exactly this page ought to go; see comment #10.
> 
> I added some details.

Nice. I revised some of the phrasing and some of the grammar (almost nothing), but otherwise your changes can stand.
@InvisibleSmiley: after the meeting today it was decided that this HowTo should be merged with http://www.seamonkey-project.org/dev/get-involved — or maybe moved somewhere near it and linked from it.

I don't have (and don't want) push permissions to that site but I'm willing to study that get-involved page and its four CSS stylesheets, and to translate the HowTo from wikicode to HTML with the appropriate ids and classes. Are you interested? Do you prefer merge-into or link-from the get-involved page? Can I ask you for review when it's ready?
Flags: needinfo?(jh)
P.S. I see that the HowTo is already linked (at its temporary location) from https://wiki.mozilla.org/SeaMonkey/QA . Maybe just move it to a more appropriate place at wikimo and change the present URL into a redirect then?
Page has been moved to https://wiki.mozilla.org/SeaMonkey/QA/Triage_HowTo (with the top "WIP" banner commented away) and a redirect created from where it used to be. The {{SeaMonkey-QA}} template has also been amended to reflect the move.

Jens, if you think it's OK, please set this bug to FIXED, otherwise you may rename this page as you see fit. I'm still willing to rewrite it for seamonkey-project.org but of course, only if necessary. IMHO the SeaMonkey pages of wikimoz are "good enough".

In the absence of a reaction, I'll close this bug once the New Year holidays are past.
Assignee: nobody → antoine.mechelynck
Status: NEW → ASSIGNED
Adding keyword "user-doc-needed" as a reminder to post an announcement on newsgroups/forums while closing the bug (in January).
Keywords: user-doc-needed
Final location of the page (in the absence of any reaction to comment #16:
https://wiki.mozilla.org/SeaMonkey/QA/Triage_HowTo
Announcements:
mozilla.dev.apps.seamonkey: https://groups.google.com/forum/#!topic/mozilla.dev.apps.seamonkey/r9HPW3F80ms
mozilla.support.seamonkey: https://groups.google.com/forum/#!topic/mozilla.support.seamonkey/Ldp9t5kXe5Q
Mozillazine Forums ("SeaMonkey Bugs" section): http://forums.mozillazine.org/viewtopic.php?p=14478401#p14478401

There remains the question raised in comment #14, which should be done in a followup bug. (Jens, please speak up.)
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Whiteboard: [CLOSEME 2016-01-15 FIXED]
If you need changes made to the Get Involved page, please open a new bug for that and specify them (ideally as a patch against http://hg.mozilla.org/SeaMonkey/seamonkey-project-org/file/tip/src/dev/get-involved.en.html), then request review from me. Thanks.
Flags: needinfo?(jh)

Updated

a year ago
Product: Websites → SeaMonkey
You need to log in before you can comment on or make changes to this bug.