MozillaWiki

BMO/UserGuide: Difference between revisions

Page Discussion

BMO/UserGuide (view source)

Revision as of 16:37, 16 July 2024

3,676 bytes added ,  16 July 2024
Added bug tracking statuses link
(→‎Status Flags: add product flags)
(Added bug tracking statuses link)
 
(21 intermediate revisions by 5 users not shown)
Line 1: Line 1:
[[File:Bmo-introduction-video.png|thumb|Understanding Mozilla: Bugzilla|link=https://gerv.makes.org/popcorn/1bn6]]
You've probably noticed that BMO has a lot going on. We'll now delve into some more details of various definitions, features, and processes in BMO.


You've probably noticed that BMO has a lot going on.  Hopefully you've already watched [https://gerv.makes.org/popcorn/1bn6 Understanding Mozilla: Bugzilla], which gives a quick tour of BMO. We'll now delve into some more details of various definitions, features, and processes in BMO.
For people working on Firefox, please see [https://firefox-source-docs.mozilla.org/bug-mgmt/index.html the Bug Handling section in the in-tree documentation for information on how to triage and make decisions on bugs].  


Many Mozilla teams have had their own getting-started guides to BMO usage.  Some of these have fallen out of date, recommending procedures that have been obsoleted by [[BMO/Recent_Changes|new features]].  We're hoping this will be a comprehensive guide for Mozilla contributors on any and all teams.  If your team has some useful info in your own BMO guide and it's not here, feel free to add it.  If we notice that it's no longer a recommended way to use BMO, we'll fix it.  [http://en.wikipedia.org/wiki/Wikipedia:Be_bold Be bold] in the wiki way!
Finally, this is a work in progress (and may always be, since BMO is improving all the time).  There are many stubs (indicated by italics).   
 
Finally, this is a work in progress (and may always be, since BMO is improving all the time).  There are many stubs (indicated by italics).  If you feel like you know enough to write a paragraph or two about any subject, please do!
 
= BMO vs Bugzilla =
 
Bugzilla is the name of the popular issue-tracking software application, used by many organizations and maintained by the Bugzilla project.  Its home is at http://www.bugzilla.org.  While the Bugzilla project was started by Mozilla, it is administered separately, having its own Project Lead, Assistant Project Leads, and other roles.  Most of the roles are, at current, occupied by Mozilla contributors, but in the past core Bugzilla contributors have not had significant involvement in other Mozilla projects.  Mozilla does provide resources, including employee time, to the Bugzilla project.  The best description of Mozilla's involvement in Bugzilla is that of a steward.
 
BMO is an abbreviation of bugzilla.mozilla.org.  It is Mozilla's site-specific Bugzilla installation, which is a slight fork of the standard Bugzilla source (or "upstream") with many extensions.  At the moment, the fork is technically from Bugzilla 4.2, but many features have been backported from 4.4 and master—in fact, many features in those branches were written by the BMO developers, who added them to upstream but also backported them so they could be immediately available to BMO users.  Since we've backported most fixes and features that are of particular use in BMO, we haven't been strict about keeping up with the latest official upstream release.  Another difference is that the BMO devs have not prioritized deployability in BMO, since fixes and features are just pushed out each week to the BMO installation, although they have made significant progress in making BMO [[BMO/Hacking|more hackable]].
 
In sum, the main difference between Bugzilla and BMO is that the former is the name of the general-purpose software, and the latter Mozilla's site-specific installation.  An analogue is [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] versus [https://en.wikipedia.org/wiki/Main_Page Wikipedia].


=Creating a Bugzilla Account=
=Creating a Bugzilla Account=
Line 83: Line 73:


== Comment Tagging ==
== Comment Tagging ==
''Want to convey some out-of-band information on a comment? Tag it. Want to auto-collapse a spammy, abusive, or obsolete comment? Tag it.''
Want to convey some out-of-band information on a comment? Tag it.  
Want to auto-collapse a spammy, abusive, or obsolete comment? [[BMO/Comment_Tagging|Tag it]].
 
== Comment Editing ==
 
Some users can edit comments made on bugs, if you do so, please follow [[BMO/Editing_Comments|our guidelines]].


== Keywords and the Whiteboard ==
== Keywords and the Whiteboard ==
Line 94: Line 89:
The whiteboard field is for free tagging. It's used both by teams and by people who want to track bugs they're interested in.
The whiteboard field is for free tagging. It's used both by teams and by people who want to track bugs they're interested in.


== Tracking Flags ==
== Tracking Status ==
 
See [[BMO/UserGuide/BugStatuses]]
 
== Tracking Flags ==
[[File:Flagexample.png||400px|right]]
=== tracking-firefoxXX ===
''Who's doing the tracking?  Should i even set these flags?''
''Who's doing the tracking?  Should i even set these flags?''


Tracking flags are used by developers, triagers, QA and the release management teams to keep track of bugs whose fixes are slated to go into a particular product release.
Tracking flags are used by developers, triagers, QA and the release management teams to keep track of bugs whose fixes are slated to go into a particular product release. A tracking flag shows whether a bug is being investigated for possible resolution in the Firefox XX release. Bugs marked tracking-Firefox XX are bugs that must be resolved one way or another before a particular release ships. [[Firefox/Drivers|Release drivers]] will track and shepherd the bug until it is determined the bug no longer impacts the release.


[[File:Tracking-flag-example.png|thumb]]
[[File:Tracking-flag-example.png|thumb]]
Line 123: Line 124:


If you would like to suggest a bug and its fix be considered (by release managers) for a particular release, edit the bug and set the tracking flag for that release to ''?''. This is often done for a bug that's been fixed in one release channel but needs to be uplifted to another.
If you would like to suggest a bug and its fix be considered (by release managers) for a particular release, edit the bug and set the tracking flag for that release to ''?''. This is often done for a bug that's been fixed in one release channel but needs to be uplifted to another.
Refer to [http://web.archive.org/web/20160417051846/https://blog.mozilla.org/channels/2011/06/01/more-details-about-how-to-use-the-tracking-firefox-bugzilla-flag/ these guidelines] on setting the tracking flag.
=== status-firefoxXX ===
A flag which represents the status of the bug with respect to Firefox XX.
{| class="wikitable"
|+ status-firefoxXX
|-
| --- || We don't know whether Firefox XX is affected
|-
| ? || We don't know whether Firefox XX is affected, but we want to find out
|-
| unaffected || This bug does not affect Firefox XX
|-
| affected || This bug affects Firefox XX
|-
| fix-optional || This bug affects Firefox XX, we would take a fix but don't consider it as release blocking
|-
| fixed || This bug is fixed in Firefox XX
|-
| verified || This bug is fixed and verified in Firefox XX
|-
| disabled || This feature is disabled in Firefox XX
|-
| verified disabled || Disabling the feature is verified in Firefox XX
|-
| wontfix || A fix for this bug will not be accepted in Firefox XX
|-
|}
'''Approval Flags''': Set on the attachment of a bug
All patches landing on ''mozilla-beta/release/esr'' branches must have these nominated by setting a ''''' ? ''''' flag. <br>Please make sure to fill in the populated list of questions '''[Approval Request Comment]''' that come up on the attachment.
This helps Release Management understand the user impact & the risk/reward analysis before we grant or deny approval. If this form is left incomplete it will be sent back to you for completion.
[[File:ApprovalRequest.png|750px|centre]]


== Status Flags ==
== Status Flags ==


Status flags detail, at the release level, [https://mozilla.github.io/bug-handling/triage-bugzilla#what-about-release-status-status_firefoxnn-flags if a bug is present or will be addressed in a particular version].  
Status flags detail, at the release level, if a bug is present or will be addressed in a particular version.  


[[File:Status-flag-example.png|Thumb]]
[[File:Status-flag-example.png|Thumb]]
Line 133: Line 169:


Project flags are used to supplement a bug's prioritization. These flags are defined at the product and component level and will not be present for all bugs. Most often they are used to establish when a bug is to be worked on during a multi-release spanning project.
Project flags are used to supplement a bug's prioritization. These flags are defined at the product and component level and will not be present for all bugs. Most often they are used to establish when a bug is to be worked on during a multi-release spanning project.
Example project flags are:
* [https://firefox-source-docs.mozilla.org/bug-mgmt/processes/accessibility-review.html a11y-review]
* [https://wiki.mozilla.org/Compatibility/WebCompat_Priority_Flags Webcompat Priority]
* [https://wiki.mozilla.org/Performance/Bugzilla#Project_Flag Performance Impact]


== Needinfo Flag ==
== Needinfo Flag ==
''It's good and you should use it.''


If you have a question about a bug, and you'd like to direct that question to a specific person, you can do that easily with the needinfo flag.
In some bug tracking systems, to request information from someone about a bug, the bug is usually assigned to the person asked. In Bugzilla, we use ''needinfo'' flags.
 
The ''needinfo'' flag can be set at or after a bug's creation. When a ''needinfo'' flag is set, the person asked receives an email directing them to visit the bug, logging in if necessary, and answer the question.
 
To create a ''needinfo'', you can specify the bug's assignee (if any,) the bug's triage owner (if one is defined,) the bug's reporter, or another user. Ask the question in a comment and set the ''needinfo'' flag before you save the bug.
 
Common uses of ''needinfo'' include:
 
* Asking a bug reporter for more information so that a bug can be triaged
* Asking a subject matter expert for direction or clarification
 
Please respond to ''needinfo'' requests quickly to keep others from being blocked.
 
To clear a needinfo, go to the bug's page, respond to the question and save your comment. By default the ''clear this needinfo request'' checkbox is ticked.
 
If you need to route the request to another person, leave the ''clear this needinfo request'' checkbox ticked, and set a new ''needinfo'' for the person to which you want to send the question to, then save the bug.
 
You can see the ''needinfo'' flags you have requested of others and the ones requested of you in  [https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard].
 
= Team to components mapping =
 
All Bugzilla components are linked to a team.
 
The full list of teams is available at https://bugzilla.mozilla.org/rest/config/component_teams.
 
The full list of components linked to a specific team is available at https://bugzilla.mozilla.org/rest/config/component_teams/TEAM_NAME (replace TEAM_NAME with an actual team name).


The person you need info from will get bugmail with (look up the X-Bugzilla-header) in the header. This may get a person's attention faster than adding them to the CC list of a bug.  
Use https://bugzilla.mozilla.org/rest/product?type=accessible&include_fields=name&include_fields=components.name&include_fields=components.team_name if you want to find out what team is assigned to a specific component.


You can see the needinfo flags you have requested of others and the ones requested of you in  [https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard].
When creating a new component, make sure to link it to the right team. If you are not sure, use the team the triage owner of the new component belongs to.
 
== Adding a new team or changing an existing one ==
 
File a bug at https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration asking to change component info.
 
Make sure :marco is CCed so they can adjust the quality weekly reports. Needinfo :dveditz to adjust the weekly security report


= Other Ways to use BMO and its Data =
= Other Ways to use BMO and its Data =
Line 181: Line 252:
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].


= BMO vs Bugzilla =
Bugzilla is the name of the popular issue-tracking software application, used by many organizations and maintained by the Bugzilla project.  Its home is at http://www.bugzilla.org.  While the Bugzilla project was started by Mozilla, it is administered separately, having its own Project Lead, Assistant Project Leads, and other roles.  Most of the roles are, at current, occupied by Mozilla contributors, but in the past core Bugzilla contributors have not had significant involvement in other Mozilla projects.  Mozilla does provide resources, including employee time, to the Bugzilla project.  The best description of Mozilla's involvement in Bugzilla is that of a steward.
BMO is an abbreviation of bugzilla.mozilla.org.  It is Mozilla's site-specific Bugzilla installation, which is a slight fork of the standard Bugzilla source (or "upstream") with many extensions.  At the moment, the fork is technically from Bugzilla 4.2, but many features have been backported from 4.4 and master—in fact, many features in those branches were written by the BMO developers, who added them to upstream but also backported them so they could be immediately available to BMO users.  Since we've backported most fixes and features that are of particular use in BMO, we haven't been strict about keeping up with the latest official upstream release.  Another difference is that the BMO devs have not prioritized deployability in BMO, since fixes and features are just pushed out each week to the BMO installation, although they have made significant progress in making BMO [[BMO/Hacking|more hackable]].
In sum, the main difference between Bugzilla and BMO is that the former is the name of the general-purpose software, and the latter Mozilla's site-specific installation.  An analogue is [https://www.mediawiki.org/wiki/MediaWiki MediaWiki] versus [https://en.wikipedia.org/wiki/Main_Page Wikipedia].
[[Category:BMO]]
[[Category:BMO]]
DanielNL
64

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1215014...1251326"