https://wiki.mozilla.org/api.php?action=feedcontributions&user=Emceeaich&feedformat=atomMozillaWiki - User contributions [en]2024-03-28T17:03:26ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=QA/Bug_Triage_Guidelines&diff=1236765QA/Bug Triage Guidelines2021-07-18T20:46:54Z<p>Emceeaich: /* IRC nicknames for contact persons in regards to Bug Triage */ Removing Emma H from contacts</p>
<hr />
<div>'''Revision History'''<br />
<br />
This section describes the modifications that have been made to this wiki page. A new row has been completed each time the content of this document is updated (small corrections for typographical errors do not need to be recorded). The description of the modification contains the differences from the prior version, in terms of what sections were updated and to what extent.<br />
<br />
{| class="wikitable" style="width:60%"<br />
|-<br />
! Date !! Version !! Author !! Description <br />
|-<br />
| 04/22/2016 || 1.0 || Rares Bologa || Created first draft<br />
|-<br />
| || || || <br />
|}<br />
<br />
= Overview =<br />
== Scope ==<br />
This document has the purpose of improving our team’s work quality in regards to Mozilla bug triage process. Intended audience: All team members of '''Mozilla QA Engineering Team''' and any third party members interested in this process.<br />
<br /><br />
<br /><br />
<br />
'''Bug Triage Diagram'''<br /><br />
[[File:Bug_Triage_Diagram.png|1000px]]<br /><br />
<br /><br />
<br /><br />
<br />
== Ownership ==<br />
Manager, Firefox Quality Engineering - [mailto:rvandermeulen@mozilla.com Ryan VanderMeulen]<br /><br />
PM, QA Engineering Team - [mailto:rares.bologa@softvisioninc.eu Rares Bologa]<br /><br />
<br />
= Components, Contacts and Suggested Comments= <br />
== Bugzilla Component Ownership ==<br />
You can find a list of Bugzilla component ownership for bug decision [https://docs.google.com/spreadsheets/d/10i30CFUPJM7snz0xX3czFJeBh2tNwjwjtI409DQw3x0/edit?pref=2&pli=1#gid=1391890455/ here]<br />
<br />
== Bug Triage Component Selection: Firefox & CORE ==<br />
Information (description, keywords, additional notes..) about the components under Firefox & CORE can be found [https://docs.google.com/spreadsheets/d/1zknF791ExFjnAbaqiJ8h0rMMfQwPCpJl0JXyXj-18ac/edit?pli=1#gid=1206060726/ here]<br />
<br />
== Suggested Comments, Contacts & Actions ==<br />
<br />
=== IRC nicknames for contact persons in regards to Bug Triage ===<br />
<br />
{{note|this is out of date}}<br />
<br />
{| class="wikitable"<br />
|-<br />
! IRC nickname !! Name !! Reason for contacting<br />
|-<br />
| mhoye || Mike Hoye || Ping Mike for bugs where the Reporter may be difficult and he will take a look into the issue<br />
|-<br />
| RyanVM || Ryan VanderMeulen || Clearly mark bug with comments when they later on need to be discussed with Ryan<br />
|}<br />
<br />
=== Different actions to be taken for bugs ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! State/Case !! Action<br />
|-<br />
| Component || Where a Component is set to something other than Untriaged, leave the bug alone unless asked to do MozRegression or QAWanted<br />
|-<br />
| Untriaged vs. Unconfirmed || The goal is to reduce the Untriaged issues number, by placing them under the correct component. <br />
|-<br />
| New || Where there is no Component, set one. Where it cannot be reproduced, ask the Reporter for additional information or close as Incomplete / WFM<br />
'''NOTE''': Sometimes, reporters mark issues as New without being confirmed by a Mozillian or Community Member. Read carefully to see if it needs confirmation to remain New or it needs to be changed back to Unconfirmed until it can be reproduced<br />
|-<br />
| Crash || If there is no activity by Mozilla, ping or email Emma (:emceeaich) so that she can get someone to look into the issue. Place the crash tag also.<br />
|-<br />
| Mozilla Communication || When there is a lot of Mozilla Communication within the bug, ping a developer on IRC and ask him to set the appropriate component<br />
|-<br />
| Close Me <date> || Apply at your comfort, there is no standard. If you apply it, please give the reporter a chance to respond (two weeks)<br />
|-<br />
| Enhancement & Feature Requests || Enhancements and Feature Requests should have an appropriate Component assigned. The developers and PM in that component will decide if it will be implemented or marked as Resolved-Won't Fix<br />
'''NOTE''': If you are sure that a Feature Request or an Enhancement is a valid one, you could also set its status to NEW, but usually this is the component owner's job.<br />
|-<br />
| Context || Bugs that contain sensitive information or that may be harmful to the testers should be marked Context. These items can be reviewed with Ryan or Emma<br />
|}<br />
<br />
=== Suggested responses and comments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Action for bug !! Responses/Comments<br />
|-<br />
| Not reproducible || I have tested your issue on latest FF release (version) and latest Nightly build and could not reproduce it. I have <what and how it has been tested to eliminate the cause of faulty testing><br />
<Ask additional details regarding environment if needed><br />
<br />
Is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E). <br />
<br />
|-<br />
| Reproducible || <User Agent><br />
<br />
I have tested your issue on latest FF release (version), latest Nightly build (buid ID) and managed to reproduce it. I have <what and how it has been tested><br />
<br />
Reproducible also on: version + build ID (if necessary)<br />
|-<br />
| WFM || For the case when reporter commented that issue is not reproducible for him:<br />
1. Based on Comment <comment number> from the reporter, changing status to RESOLVED WORKS FOR ME.<br />
<br />
For the cases when reporter did not added requested info and we cannot reproduce (bug has explicit STR):<br />
<br />
<br />
2.Considering the fact that I cannot reproduce this and the fact that the reporter did not answered to my/<name> request until now, I will mark this as Resolved - Worksforme.<br />
<br />
If anyone can still reproduce it, feel free to reopen the issue and provide more information.<br />
|-<br />
| Incomplete || Marking this as Resolved: Incomplete due to the lack of response from the reporter.<br />
If anyone can still reproduce it on latest versions, feel free to reopen the issue and provide more information.<br />
|-<br />
| Enhancement || This seems to be more of an enhancement than an issue in my opinion. <br />
However, I am assigning a component to this issue in order to involve the development team and get an opinion on this.<br />
|-<br />
| Crash not encountered anymore || <User Agent> + "I have tried to reproduce this crash on latest FF release (versions) and Nightly build (build ID) but without any luck." <- optional sentence if there are STR or testcase<br />
<br />
There are no crash reports in the last 7/14/28 days in the crash signatures provided, therefore closing this bug as Resolved: Works for me. Please reopen the bug if the crash still reproduces and provide more information.<br />
|-<br />
| MozRegression: When we ask a user to use MozRegression || Given the fact that the issue seems to be related to something that is specific to your setup, could you please try to find a regression range using MozRegression tool?<br />
Information on the tool is available at http://mozilla.github.io/mozregression/. Please don't hesitate to contact us if you encounter any problems.<br />
|-<br />
| MozRegression: When we find it is fixed || It was confirmed broken in version xx but it is fixed in Nightly <version><br />
Use MozRegression to find where the fix occurred - If time permits, probably lower priority<br />
|-<br />
| MozRegression: When we find it broke || If it was working in version xx and it is now broken the MozRegression should be applied to find where that break occurred<br />
|}<br />
<br />
== Lessons Learned ==<br />
Below you can find a couple of lessons learned that we've gathered from the beginning of our bug triage process. <br /><br />
<br />
{| class="wikitable"<br />
|-<br />
! About!! What To Do<br />
|-<br />
| Old builds needed in zip format || If you have to test old release builds but you don't want to install them, you will need a ".zip" format. But that can be hard to find when it comes to old builds.<br />
<br />
What you can do is to download the installer form "http://archive.mozilla.org" and have an archive manager program like "7zip" installed (freeware program). Open the folder where the installer was downloaded and right click it in order to use 7zip program to extract the installer. After doing that, you will have a folder where the Firefox build is extracted and from where you can start the actual version without installing it. As a suggestion use the command window to open it with a different profile and with no remote setting.<br />
<br />
|-<br />
| Mac OS Update Privileges || When choosing to update a software on Mac OS platform, the behavior is different than on other OSes. <br />
<br />
It will prompt the current user for the credentials of the user that installed the software. So, if the administrator installed the software, and the software is available also on a 2nd user desktop, updating the software should and will request the administrators password in order to update it. If the software that you are trying to update was installed by the current user on which you are logged in, it will require the current user credentials in order to update it.<br />
<br />
|-<br />
| Using MozRegression Tool on Mac OS || If you need to find when an issue was introduced (regression), the easiest and best way to do this is by using the MozRegression tool. <br />
<br />
In order to do this, you'll need to install a couple of things before starting the tool. Here are the steps needed depending on OS needed for testing:<br />
<br />
• Mac OS X (10.11 only, for older versions see next bullet)<br />
<br />
In order to use MozRegression tool on Mac OS X 10.11, you will need to perform some additional steps than on other Mac OS versions. One of the steps is installing a virtual environment trough python so you won't get any conflicts between python and MozRegression.<br />
<br />
Here are the complete steps to install and use MozRegression trough Virtual environment:<br />
<br />
1. First, you will need to open a Terminal window and enter the following command "sudo su" (without quotes). You will be prompted to insert the PC user password (the password used for logging in on the Mac OS user). If you don't see the characters you are entering, don't worry, they are entered but due to security are hidden. After entering them press the "Enter" key.<br><br />
2. After credentials are confirmed it's time to install the Python 2.7 component by entering the next command "sudo easy_install pip".<br><br />
3. Next you will need to install the virtual environment using the next command "sudo pip install virtualenv".<br><br />
4. After the virtual environment was installed, you will need to provide a directory name for the virtual environment using <br>"virtualenv <directory_name>" command (eg: "virtualenv mozregression" will create the environment folder under your current profile).<br><br />
5. Next you will need to activate the environment from a file that was created in the environment folder using "source /Users/profile_name/folder_name/bin/activate" command (eg: "source /Users/pauloiegas/mozregression/bin/activate").<br><br />
6. You will notice that your command line is now changed into "(mozregression) < code >". Now you will need to install the mozregression tool into the virtual environment using "pip install mozregression" command.<br><br />
7. After the installation is completed, you can check if everything is ok using a simple command like "mozregression -h" to see if the tool help is displayed (if not, you did something wrong along the way).<br><br />
8. After doing this you are ready to start digging into builds. You can do that by using the next two commands "mozregression --good <build_date>" (eg: mozregression --good 2014-12-31) when you only know the build when it was ok, or "mozregression --good <build_date> --bad <build_date>" (eg: mozregression --good 2014-12-31 --bad 2015-12-31) when you know both a good build and a bad build.<br><br />
9. Mozregression will start downloading builds and open them to test your issue. After testing the issue you must validate the build with "good" or "bad". The tool will continue to download and open builds until the search is narrowed down to two builds and will throw a "Pushlog link" that you will need to provide in the bug comment together with any additional information that we consider to be helpful.<br><br />
10. You will need to deactivate the virtual environment after you complete the regression using "deactivate" command that will return you to the normal command line.<br><br />
11. '''REMEMBER''' ! The environment must be activated each time when you want to use the Mozregression tool.<br><br />
<br />
• Mac OS X (10.10 and under)<br />
<br />
1. First, you will need to open a Terminal window and enter the following command "sudo su" (without quotes). You will be prompted to insert the PC user password (the password used for logging in on the Mac OS user). If you don't see the characters you are entering, don't worry, they are entered but due to security are hidden. After entering them press the "Enter" key.<br><br />
2. After credentials are confirmed it's time to install the Python 2.7 component by entering the next command "sudo easy_install pip".<br><br />
3. After the Python installation is finalized, you'll need to install the latest version of mozregression by entering the next command "sudo pip2 install -U mozregression"<br><br />
4. After doing this you are ready to start digging into builds. You can do that by using the next two commands "mozregression --good <build_date>" (eg: mozregression --good 2014-12-31) when you only know the build when it was ok, or "mozregression --good <build_date> --bad <build_date>" (eg: mozregression --good 2014-12-31 --bad 2015-12-31) when you know both a good build and a bad build.<br><br />
5. MozRegression will start downloading builds and open them to test your issue. After testing the issue you must validate the build with "good" or "bad". The tool will continue to download and open builds until the search is narrowed down to two builds and will throw a "Pushlog link" that you will need to provide in the bug comment together with any additional information that we consider to be helpful.<br><br />
<br />
If something has been missed you can find all the mentioned information also at this link -> http://mozilla.github.io/mozregression/quickstart.html. <br />
<br />
'''NOTE''': MozRegression tool is not perfect and will throw some errors on some old builds. If it is your case, please refer to my other lesson from above this where you have information on how to manually create the "Pushlog link" for the found builds.<br />
<br />
If you encounter some errors involving Python while trying to use MozRegression on Mac OS, please look at the next lesson to resolve this issue.<br />
|-<br />
| Instaling virtual Environment for MozRegression to work on Mac OS || It seams that nowadays, not only the Mac OS 10.11 has some conflicts between python and MozRegression when trying to do a regression window. In order to resolve these conflicts, you will need to install and use MozRegression trough a virtual environment. Here are the steps you need to follow in order to do that:<br />
<br />
1. First, you will need to open a Terminal window and enter the following command "sudo su" (without quotes). You will be prompted to insert the PC user password (the password used for logging in on the Mac OS user). If you don't see the characters you are entering, don't worry, they are entered but due to security are hidden. After entering them press the "Enter" key.<br><br />
2. After credentials are confirmed it's time to install the Python 2.7 component by entering the next command "sudo easy_install pip".<br><br />
3. Next you will need to install the virtual environment using the next command "sudo pip install virtualenv".<br><br />
4. After the virtual environment was installed, you will need to provide a directory name for the virtual environment using "virtualenv <directory_name>" command (eg: "virtualenv mozregression" will create the environment folder under your current profile).<br><br />
5. Next you will need to activate the environment from a file that was created in the environment folder using "source /Users/profile_name/folder_name/bin/activate" command (eg: "source /Users/pauloiegas/mozregression/bin/activate").<br><br />
6. You will notice that your command line is now changed into "(mozregression) < code >". Now you will need to install the mozregression tool into the virtual environment using "pip install mozregression" command.<br><br />
7. After the installation is completed, you can check if everything is ok using a simple command like "mozregression -h" to see if the tool help is displayed (if not you did something wrong along the way).<br><br />
8. You will need to deactivate the virtual environment after you complete the regression using ""deactivate" command that will return you to the normal command line.<br><br />
9. '''REMEMBER''' ! The environment must be activated each time when you want to use the Mozregression tool.<br><br />
|-<br />
| Using MozRegression Tool on Windows || On Windows platform you can either use the MozRegression gui from github releases page, or you can use the tool trough command line as on Mac OS. In the next steps I will present the command line way on Windows.<br />
<br />
1. First, you will need to download and install Python 2.7 from ActiveState website (http://www.activestate.com/activepython/downloads).<br><br />
2. After installing Python you will need to open a command prompt window and enter the next command "pip install -U mozregression".<br><br />
3. After doing this you are ready to start digging into builds. You can do that by using the next two commands "mozregression --good <build_date>" (eg: mozregression --good 2014-12-31) when you only know the build when it was ok, or "mozregression --good <build_date> --bad <build_date>" (eg: mozregression --good 2014-12-31 --bad 2015-12-31) when you know both a good build and a bad build.<br><br />
4. MozRegression will start downloading builds and open them to test your issue. After testing the issue you must validate the build with "good" or "bad". The tool will continue to download and open builds until the search is narrowed down to two builds and will throw a "Pushlog link" that you will need to provide in the bug comment together with any additional information that we consider to be helpful.<br><br />
<br />
If I missed something you can find all the mentioned information also at this link -> http://mozilla.github.io/mozregression/quickstart.html. <br />
<br />
'''NOTE''': MozRegression tool is not perfect and will throw some errors on some old builds. If it is your case, please refer to my other lesson from above this where you have informations on how to manually create the "Pushlog link" for the found builds.<br />
|-<br />
| Using MozRegression Tool on Linux || On Linux platform you can either use the MozRegression GUI from github releases page, or you can use the tool trough command line as on Mac OS. In the next steps I will present the command line way on Linux.<br />
<br />
1. First, you will need to open a Terminal window and enter the following command "sudo su" (without quotes). You will be prompted to insert the PC user password (the password used for logging in on the Linux user). If you don't see the characters you are entering, don't worry, they are entered but due to security are hidden. After entering them press the "Enter" key.<br><br />
2. After credentials are confirmed it's time to install the Python 2.7 component by entering the next command "sudo apt-get install python-pip". You will be asked if you are sure you want to install it and you must confirm by entering "y" key and confirm the choice after.<br><br />
3. After the Python installation is finalized, you'll need to install the latest version of mozregression by entering the next command "sudo pip2 install -U mozregression"<br><br />
4. After doing this you are ready to start digging into builds. You can do that by using the next two commands "mozregression --good <build_date>" (eg: mozregression --good 2014-12-31) when you only know the build when it was ok, or "mozregression --good <build_date> --bad <build_date>" (eg: mozregression --good 2014-12-31 --bad 2015-12-31) when you know both a good build and a bad build.<br><br />
5. Mozregression will start downloading builds and open them to test your issue. After testing the issue you must validate the build with "good" or "bad". The tool will continue to download and open builds until the search is narrowed down to two builds and will throw a "Pushlog link" that you will need to provide in the bug comment together with any additional information that we consider to be helpful.<br><br />
<br />
If I missed something you can find all the mentioned information also at this link -> http://mozilla.github.io/mozregression/quickstart.html.<br />
<br />
'''NOTE''': MozRegression tool is not perfect and will throw some errors on some old builds. If it is your case, please refer to my other lesson from above this where you have information on how to manually create the "Pushlog link" for the found builds.<br />
|-<br />
| Using MozRegression Tool with "--find-fix" attribute || If you are dealing with an issue that still reproduces on latest Firefox release build but no longer on Beta, Aurora or Nightly you can use the "--find-fix" attribute while performing regression range in mozregression. This will help you to provide information to the reporter regarding his issue. In most of the cases his issue will end up as "duplicate" or "works for me" since the problem was treated in a different bug. <br />
<br />
1. First, you'll need to manually find a bad Nightly build date by downloading builds from http://ftp.mozilla.org/ . For quick testing I suggest to download zip-ed builds, extract them and use the command window / terminal to launch the build with "-no-remote" and "-p" commands. <br />
In Windows you just need to navigate to the extracted folder, hold Shift + right click on free area of the window, then click the "Open command window here" option. After the cmd is opened, write "firefox -no-remote -p" and hit "Enter" key. This will open a separate instance of Firefox with the profiler window, where you can choose to use a no update profile created before (will not update an older version of FF). After that, just test the build and see if it's reproducible. <br />
On Mac OS, you can install the build, and in order to open it with a no update profile, you need to navigate ti instalation directory manually from terminal window (/Applications/FirefoxNightly.app/Contents/MacOS/firefox -no-remote- -p)<br /><br />
<br />
2. After you find a bad build, the next step would be to open a command window and start using mozregression by typing "mozregression --bad year-month-day --good year-month-day --find-fix". You need to be sure that bad build is older than good build, otherwise this won't work.Usually the good build would be the latest Nightly so use that date, otherwise it's a regression issue that needs to be treated like in previous lessons.<br />
The "--find-fix" atribute in mozregression does exactly what bisect does in normal usage. It searches for the exact push that fixed the issue. In most of the cases you end up with only one issue that you can provide to the reporter of your triaged issue as more information.<br />
|-<br />
| Using MozRegression Tool with targeted profile for each downloaded build || Sometimes there are cases when you are unable to reproduce an issue on MozRegression downloaded builds. But if you manually download the same build and test it, you can reproduce it without problems. This could possibly happen because MozRegression has a different way of storing downloaded builds on your PC and it seams it does not uses a profile when opening the build to test. This case can be avoided by targeting a previously created profile that will be used for each downloaded build. Here are the steps to follow:<br />
<br />
Windows:<br />
<br />
1. First you'll need to have a good build date and a bad build date as for any other regression window checked.<br /> <br />
2. Open a Command Prompt window and observe the path displayed. It should be something like "C:\Users\profile_name>"<br /><br />
3. Start Firefox with the profiler and create a test profile if you don't have one (you will need a specific name in order to find it faster).<br /><br />
4. Open "My Computer" and navigate to your OS partition in Users\<your_profile_name>\AppData\Roaming\Mozilla\Firefox\Profiles\<created_profile_name>\ folder. '''Remember''' that "AppData" folder is only displayed when "Show hidden files" option is checked.<br /><br />
5. Click the window address bar in order to view the complete path and copy it from the end to start, leaving behind only the already existing path from command prompt.<br /><br />
6. With the good and bad build dates, write a command like "mozregression --good year-month-day --bad year-month-day --profile \AppData\Roaming\Mozilla\Firefox\Profiles\<created_profile_name>\" (eg: C:\Users\paul.oiegas>mozregression --bad 2015-06-06 --good 2016-02-23 --profile \AppData\Roaming\Mozilla\Firefox\Profiles\w9gzt0rd.testrelease2). <br /><br />
<br />
Mac OS X:<br />
<br />
The steps are the same, only the path is different.<br />
Profile folders are in one of these locations:<br />
~/Library/Application Support/Firefox/Profiles/<profile folder><br />
~/Library/Mozilla/Firefox/Profiles/<profile folder> <br />
The tilde character (~) refers to the current user's Home folder, so ~/Library is the /Macintosh HD/Users/<username>/Library folder. (--profile=/Users/pauloiegas/Library/Application\ Support/Firefox/Profiles/rg0ayjkt.PrintTESTn)<br />
<br />
After this steps, you are all set and can perform the regression range as normal. By using the "--profile <path>" attribute, each downloaded build trough mozregression, will use the same profile and store data on it. <br />
This flow can be used also with "--find-fix" attribute as mentioned in the above lesson by adding it after the default command contents and the "--profile <path>" one (eg: C:\Users\paul.oiegas>mozregression --bad 2015-06-06 --good 2016-02-23 --find-fix --profile \AppData\Roaming\Mozilla\Firefox\Profiles\w9gzt0rd.testrelease2).<br />
|-<br />
| MozZRegression on Android (with Windows) || <br />
If you encounter a regression bug on Android OS, you will need to perform a couple of steps in order to be able to run MozRegression tool on an Android device. Here are the steps that you need to follow on Windows in order to find a regression range. Will update the lesson with steps also for Mac OS and Linux after I will find how to set the "Environment variables" on each of them.<br />
<br />
1. Install the latest Android SDK with Android Studio from (http://goo.gl/OPyvqU ) or only the command line tools from next link<br />
Windows - http://dl.google.com/android/installer_r24.4.1-windows.exe<br />
Android studio contains also the SDK needed for this to work, but it's also a coding and debugging software for android with a friendly user interface. But if you don't need this, you can install just the command line tools.<br /><br />
<br />
2. Install the latest Java JDK from Oracle website (http://goo.gl/rknzzs). It should be straight forward, no extra settings needed.<br /><br />
<br />
3. For best results install PDA Net software in order to have most of the Android devices drivers installed (http://pdanet.co/). However, there are cases when this software does not contains the drivers for all the new devices. For example there have been reported that LG G4 driver is not contained. In this case you will have to manually search and install the driver for your device.<br /><br />
<br />
4. Next step is a bit trickier and you must pay attention at what changes you are doing.<br />
- First you must navigate to "System" window in Windows (right click on My Computer + Proprieties).<br />
- Chose the "Advanced System Settings" option from left side of the window, and from the bottom of the displayed window select "Environment Variables" option.<br />
- In the "Environment Variables" window, you need to add first a new "System variable". Click the "New..." button and add "ANDROID" for variable name and in the variable value field, you need to add the path where you have installed the SDK (eg: C:\Users\profile_name\AppData\Local\Android\sdk where "profile_name" is usually your PC user name). After that click "Ok" button to save the variable.<br />
- Next step would be to edit the "Path" system variable (double click on it), and add two new strings. First is "%ANDROID%\tools\" and second "%ANDROID%\platform-tools\". Hit "Ok" button for every window and you are all done with this step.<br /><br />
<br />
5. Next you will need to install MozRegression tool by using the steps from the above lessons learned or to use the MozRegression GUI that you can download from here (https://goo.gl/DyFFok).<br /><br />
<br />
6. On your Android device be sure you have the "Developer options" enabled. Tap multiple times on "Build number" area in "About device" section of device "Settings" page. Return to device "Settings" main page and from the "Developer options" that are now displayed, switch to "On" the "USB debugging" option.<br /><br />
<br />
7. After this, you are almost good to go. Connect your Android device to the PC, run a command window (make sure you have the latest mozregression version "pip install -U mozregression") or the Mozregression GUI.<br />
For the command window mode, the only thing that is different from the PC testing is the "--app=fennec" command that you need to introduce before good & bad dates. The command will look like "mozregression --app=fennec --good 2015-05-06 --bad 2015-07-09".<br /><br />
<br />
'''Notes and Tips & Tricks''':<br><br />
- There are cases when the build is installed and opened instantly but there are times when the build takes a few minutes to load. Just have patience young Jedi.<br><br />
- If you need to test on older Android versions like 2.3x, you need to use the command as "app=fennec-2.3" This will only work for as high as Firefox 48.0. The support for Android 2.3x will be dropped after v48.0.<br><br />
- Multiple profiles are not available on mobile platform. You will need to clear the saved data from Settings>Applications>Nightly application in order to simulate a new profile.<br><br />
<br />
|-<br />
| Manual regression and manual creation of Pushlog link || When Mozregression tool fails to work (errors when trying to open the builds for test), or when you cannot use it because you need to perform some steps outside the browser before you can test an issue, all you can do is manual regression testing. But in order to help locate the issue you will still need the "Pushlog link" that points to the exact pushes that were made in the specific day when issue appeared. In order to create the pushlog link manually, you will need the next things:<br />
1. Latest good build and the first bad build where issue appeared.<br><br />
2. You will need to either install both the builds (one at the time) or extract them. The most convenient is to extract both the zipped builds.<br><br />
3. Search in installation folder/build folder for the "application.ini" file (Mac OS path is /Applications/Firefox.app/Contents/MacOS/application.ini).<br><br />
4. Open the ".ini" files with a text editor and search for the "SourceStamp" values.<br><br />
5. After doing this you will have to use the " http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=good_build_stamp&tochange=bad_build_stamp " link and replace the <good_build_stamp> and <bad_build_stamp> strings with the one obtained from the .ini files.<br> <br />
<br />
<br />
You should verify the link obtained, and if it works and it is related with the period when the issue appeared, you should add it to the comment for the bug where regression was performed. <br />
If you have enough experience you could also point in the comment the exact push from the pushlog page that affected the build, and CC the developer that did it (if it's still available) in order to obtain the information faster. For the moment Ryan was doing this for the pushlog links I provided but we can experience this too in the future.<br />
|-<br />
| Performing quick Regression test by searching in build release notes || In cases when reporter mentions that in a previous version of Firefox his issue was not present and after updating it appeared, you can also do a quick manual regression by searching the problematic build release notes and observe the changes that have been made on it. To better explain this process I will refer to an Issue that I triaged, where the reported problem was an audio malfunction in an html5 game that he and his team develops, that appeared after updating from Firefox 39.0 to 40.0.<br />
<br />
In order to find the build release notes you can easily search on google for "Firefox release notes" and open the "https://www.mozilla.org/en-US/firefox/releases/" page. In this page you can view all the release notes from version 0.1 to the latest release (42.0 in the moment of writing). In my case I chose "40.0" version (https://www.mozilla.org/en-US/firefox/40.0/releasenotes/). After choosing the build, you are redirected to a page where all the major changes that entered in this build are mentioned. By looking trough the changes I observed that there were 2 changes on "html5" technology and one of them was related to "Audio Buffer". In my case the change also had a link that pointed to a page with detailed explanations and code chunks to better explain the change. This seamed that could be related a lot with the reporter problem. In my bug reply comment I mentioned the exact link of the change and asked him or his development team to look into it, since it may be the source of his problem and report any findings.<br />
<br />
This quick search could reduce a lot the time we invest in trying to set up the environment and reproduce the issue. This procedure was reported to be one of the most used in the Firefox Desktop Validation team when triaging a bug that appeared from a version to another.<br />
|-<br />
| CentOS's || CentOS 6 provides only GTK+ version 2. GTK+ 3 is officially supported by CentOS only in CentOS 7. <br />
<br />
This is a change that was made for version 43. <br />
<br />
https://www.mozilla.org/en-US/firefox/43.0beta/system-requirements/<br />
<br />
https://www.mozilla.org/en-US/firefox/42.0/system-requirements/<br />
|-<br />
| How to deal with bugs that are reproducible between the latest official release and the latest Nightly || One of the possibilities when working on the Bug triage task is to encounter bugs that are reproducible between the latest official release and the latest Nightly (for example, the bug is reproducible only on the latest Aurora). In this case we take the following actions:<br />
<br />
1. Confirm the bug.<br><br />
2. If it's the case: set the right component.<br><br />
3. In Bugzilla, edit the tracking flags area: set as affected or unaffected the status-firefox fields for all Firefox versions (official Release, latest Beta, latest Aurora and latest Nightly).<br><br />
4. Knowing the patch that fixed the issue is an asset in getting the fix on the affected Firefox version (the MozRegression tool is very helpful - ask the reporter or do it yourself).<br><br />
|-<br />
| How to simulate bad internet connection on Mac OS || If you encounter an issue where the reporter specifies that he has a slow / bad internet connection, or you think the issue appears only when internet connection is not good enough, you can simulate this kind of environment by using a bandwidth throttling tool.<br />
Here are the steps you need to follow to install and use the tool under Mac OS:<br />
<br />
1. First you will need to navigate to https://developer.apple.com/downloads/ and if you don't have an apple ID, you should create one.<br /><br />
2. After you manage to Sign In, a list with available downloads for Apple Developers is displayed. You need to chose the most recent "Hardware IO Tools for Xcode" package (you don't need Xcode installed to use this tools). Expand the package from "+" sign on the left and click the link from right side with ".dmg" format.<br /><br />
3. After the package is downloaded, mount it from downloads. A folder will be opened after containing the tools from the package. You will need to double click the "Network Link Conditioner.prefPane" file and choose to install it when prompted. The tool will be installed and added to "System Preferences" panel and you can always start it from there, each time when you need it.<br><br />
4. The Tool comes with a couple of predefined profiles, but I suggest you to create a new one. You can do this by tapping the "manage Profiles" button. If grayed out, you need to unlock the edit possibility by clicking the "Lock" icon from bottom left and enter the user and password.<br /><br />
5. A new window will pop up where you can click the "+" button from bottom left to add a new profile (any name you desire). <br /><br />
6. After you have a new profile created, you will need to enter the desired values in "Downlink Bandwidth" for download speed and in "Uplink Bandwidth" for upload speed. Please take into consideration that the speed there is represented by default in "Kbps" which means that if you want to simulate a real 100KBps download speed, you will need to multiply the value with 8 to have the value in "kbps" (800kbps).<br /><br />
7. After the values are introduced, press the "OK" button to close the profiles management window and switch the tool to "ON" in order to initialize the bandwidth limitation.<br /><br />
<br />
Please '''REMEMBER''' that in order to return to the normal internet bandwidth speed, you will always need to switch the Tool to "OFF" after testing, otherwise the limitation will remain always ON.<br />
|-<br />
| How to simulate bad internet connection on Windows || If you encounter an issue where the reporter specifies that he has a slow / bad internet connection, or you think the issue appears only when internet connection is not good enough, you can simulate this kind of environment by using a bandwidth limiter tool.<br />
Here are the steps you need to follow to install and use the tool under Windows:<br />
<br />
1. First you will need to to navigate to https://netbalancer.com/download page and download the latest version of the NetBalancer software. The unregistered version is limited to a maximum of 3 process priorities/limits and 3 rules at a time. <br /><br />
2. Install the software and restart the computer after.<br /><br />
3. After restarting, start the program and you will observe a list with all processes under windows. <br /><br />
4. Right click the desired process (eg: firefox) and chose to "Limit" it. A window will be displayed where you can add the desired bandwidth value for download. You can also select the value for upload by choosing "Limit" value from the drop-down related to upload.<br /><br />
5. Confirm the settings and you are all done. In order to properly limit the process you desire, be sure you choose the one that consumes bandwidth while navigating trough websites / listening to videos in the browser.<br /><br />
<br />
Please '''REMEMBER''' that in order to return to the normal internet bandwidth speed, you will always need to reset all the limitations from the "refresh" like button from the software toolbar after testing, otherwise the limitation will remain always ON.<br />
|-<br />
| General Bug Triage process || - Close the NeedInfo bugs for which the reporter has not come back with a reply within 2 weeks (previous period was 1 month) - but '''keep the NeedInfo flag alive''', just in case the reporter will come back to it<br />
<br />
- Don’t use the ‘Reporter’ expression inside bugs when you’re addressing him/her. Instead, try using his/her name or Bugzilla username. (applicable for reporters with an intelligible name/email address) The desire here is to make the communication more personal. You can still use ‘reporter’ word inside comments when you’re not directly addressing him.<br />
<br />
- If a certain developer has started working on an untriaged bug (has relevant comments inside it, changed bug’s status…) and we’re not very sure to what component to assign this bug to, first expected action would be to ask directly the developer for it (either he tells you the component or set it himself). Just in case you’re not receiving any reply from the developer, it’s ok to bring this bug into Ryan’s attention.<br />
<br />
- For old bugs (ex: 3.2k list ones) – if the bug still reproduces and we consider it a high impact – it is ok to set comments for it. If the bug still reproduces but is lower severity, we should not add new comments to it (just change the status if case requires it). This change has come as a complain from several developers that they’re getting spammed with bug triage work for not so relevant bugs. <br />
If the low severity reproducible bug has by any chance Priority P1, we should decrease it. Applicable only if P1 has been set by the reporter. (if it has been set by dev or somebody else from Mozilla, please leave it as is)<br />
If the bug is a web compatibility one and we’re not being able to reproduce it on Chrome, then it’s ok to set a comment for it (even though it might have a lower severity).<br />
<br />
- take enough time to try to reproduce the bug and only when we could not reproduce it or don’t have enough info to reproduce it, then ask the reporter to try other cases. We should explain the reporter what we have tried, on what version of Firefox we tried to reproduce and then ask for more information if we cannot reproduce the bug (or ask him to try to reproduce the bug in safe mode or with clean profile).<br />
<br />
- Make sure to set the release status flags appropriately, and nominate release tracking flags if there's any uncertainty about whether the bug should block.<br />
|}</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/new-version&diff=1229544BMO/new-version2020-07-28T08:21:12Z<p>Emceeaich: /* Versions */ Update thunderbird products</p>
<hr />
<div>{{note|These activities should be completed before or at the same time we have the merge for the next major release of Firefox.}}<br />
<br />
= Adding a new "rapid release" version to Firefox/Core/Thunderbird = <br />
<br />
== Status and Release Flags == <br />
<br />
The flags for release status and tracking are created with the [https://bugzilla.mozilla.org/page.cgi?id=tracking_flags_admin_list.html release tracking flags administration page], not the "custom fields" page.<br />
<br />
This is now done by the Release Management team.<br />
<br />
* Create a copy of the current release's version of the following flags, updating the name and sort-order:<br />
** copy cf_tracking_firefox''N'' to cf_tracking_firefox''N+1''<br />
** copy cf_status_firefox''N'' to cf_status_firefox''N+1''<br />
<br />
Only members of the <code>mozilla-next-drivers</code> group may set a tracking flag to something other than ''?''. Members of the <code>canconfirm</code> group can set status flags or set a tracking flag to ''?''.<br />
<br />
** copy cf_tracking_thunderbird''N'' to cf_tracking_thunderbird''N+1''<br />
** copy cf_status_thunderbird''N'' to cf_status_thunderbird''N_1''<br />
* edit the flags for previous (now released) versions (N-3) and uncheck 'active':<br />
** cf_tracking_firefox''N-3''<br />
** cf_status_firefox''N-3''<br />
** cf_tracking_thunderbird''N-3''<br />
** cf_status_thunderbird''N-3''<br />
<br />
* update cf_tracking_firefox_relnote (which is relnote-firefox in the UI) (add N+1, disable N-3 except for ESR)<br />
* update the current esr tracking field: cf_tracking_firefox_esr* (add N+2)<br />
<br />
== Milestones ==<br />
<br />
* Use the [https://bugzilla.mozilla.org/editmilestones.cgi milestone admin page] to add new milestones<br />
* Move the --- milestone marker to between N-1 and N for all products where a milestone was added<br />
* Leave all milestones from most recent ESR to nightly (and '---' and 'Future') active. Disable others <br />
* ''Don't delete old milestones''<br />
<br />
=== Products ===<br />
<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Calendar Calendar]: "Thunderbird N.0"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Chat%20Core Chat Core]: "Instantbird N"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Cloud%20Services Cloud Services]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Core Core]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=DevTools DevTools]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox Firefox]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox%20Build%20System Firefox Build System]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox%20for%20Android Firefox for Android]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=GeckoView GeckoView]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Remote%20Protocol Remote Protocol]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Thunderbird Thunderbird]: "NN Branch<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Toolkit Toolkit]: "NN Branch<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=WebExtensions WebExtensions]: "NN Branch"<br />
<br />
== Versions ==<br />
<br />
Use the [https://bugzilla.mozilla.org/editversions.cgi version admin page] to add new versions.<br />
<br />
* Calendar: "Thunderbird NN"<br />
* Chat Core: "Thunderbird NN"<br />
* Cloud Services: "Firefox NN"<br />
* Core: "Firefox NN"<br />
* DevTools: "Firefox NN"<br />
* Firefox: "Firefox NN"<br />
* Firefox Build System: "Firefox NN"<br />
* Firefox for Android: "Firefox NN"<br />
* GeckoView: "Firefox NN"<br />
* MailNews Core: "Thunderbird NN"<br />
* Remote Protocol: "Firefox NN"<br />
* SeaMonkey: "SeaMonkey N.0"<br />
* Thunderbird: "Thunderbird NN"<br />
* Toolkit: "Firefox NN"<br />
* WebExtensions: "Firefox NN"<br />
<br />
= Adding a "rapid release" version to SeaMonkey =<br />
<br />
To determine the correct version number to add, check with a SeaMonkey owner first (Callek, or any member of the [http://www.seamonkey-project.org/about SeaMonkey Council]).<br />
<br />
these steps use 2.27 as an example.<br />
<br />
use the [https://bugzilla.mozilla.org/page.cgi?id=tracking_flags_admin_list.html release tracking flags admin page] to:<br />
* copy the prior flags and edit as per firefox<br />
** copy cf_tracking_seamonkey226 to cf_tracking_seamonkey_227<br />
** copy cf_status_seamonkey226 to cf_status_seamonkey_227<br />
* deactivate old flags for previous (now released) versions (N-4)<br />
** deactivate cf_tracking_seamonkey223 and cf_status_seamonkey223<br />
<br />
use the [https://bugzilla.mozilla.org/editmilestones.cgi?product=SeaMonkey milestone admin page] to:<br />
* add a new milestone "seamonkey2.27"<br />
* move the --- milestone marker to between seamonkey2.26 and seamonkey2.27<br />
<br />
use the [https://bugzilla.mozilla.org/editversions.cgi?product=SeaMonkey version admin] page to:<br />
* add a new version "SeaMonkey 2.27 Branch"<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/new-version&diff=1229543BMO/new-version2020-07-28T08:20:08Z<p>Emceeaich: /* Products */ Add Thunderbird</p>
<hr />
<div>{{note|These activities should be completed before or at the same time we have the merge for the next major release of Firefox.}}<br />
<br />
= Adding a new "rapid release" version to Firefox/Core/Thunderbird = <br />
<br />
== Status and Release Flags == <br />
<br />
The flags for release status and tracking are created with the [https://bugzilla.mozilla.org/page.cgi?id=tracking_flags_admin_list.html release tracking flags administration page], not the "custom fields" page.<br />
<br />
This is now done by the Release Management team.<br />
<br />
* Create a copy of the current release's version of the following flags, updating the name and sort-order:<br />
** copy cf_tracking_firefox''N'' to cf_tracking_firefox''N+1''<br />
** copy cf_status_firefox''N'' to cf_status_firefox''N+1''<br />
<br />
Only members of the <code>mozilla-next-drivers</code> group may set a tracking flag to something other than ''?''. Members of the <code>canconfirm</code> group can set status flags or set a tracking flag to ''?''.<br />
<br />
** copy cf_tracking_thunderbird''N'' to cf_tracking_thunderbird''N+1''<br />
** copy cf_status_thunderbird''N'' to cf_status_thunderbird''N_1''<br />
* edit the flags for previous (now released) versions (N-3) and uncheck 'active':<br />
** cf_tracking_firefox''N-3''<br />
** cf_status_firefox''N-3''<br />
** cf_tracking_thunderbird''N-3''<br />
** cf_status_thunderbird''N-3''<br />
<br />
* update cf_tracking_firefox_relnote (which is relnote-firefox in the UI) (add N+1, disable N-3 except for ESR)<br />
* update the current esr tracking field: cf_tracking_firefox_esr* (add N+2)<br />
<br />
== Milestones ==<br />
<br />
* Use the [https://bugzilla.mozilla.org/editmilestones.cgi milestone admin page] to add new milestones<br />
* Move the --- milestone marker to between N-1 and N for all products where a milestone was added<br />
* Leave all milestones from most recent ESR to nightly (and '---' and 'Future') active. Disable others <br />
* ''Don't delete old milestones''<br />
<br />
=== Products ===<br />
<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Calendar Calendar]: "Thunderbird N.0"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Chat%20Core Chat Core]: "Instantbird N"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Cloud%20Services Cloud Services]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Core Core]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=DevTools DevTools]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox Firefox]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox%20Build%20System Firefox Build System]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox%20for%20Android Firefox for Android]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=GeckoView GeckoView]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Remote%20Protocol Remote Protocol]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Thunderbird Thunderbird]: "NN Branch<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Toolkit Toolkit]: "NN Branch<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=WebExtensions WebExtensions]: "NN Branch"<br />
<br />
== Versions ==<br />
<br />
Use the [https://bugzilla.mozilla.org/editversions.cgi version admin page] to add new versions.<br />
<br />
* Calendar: "Thunderbird NN"<br />
* Chat Core: "NN"<br />
* Cloud Services: "Firefox NN"<br />
* Core: "Firefox NN"<br />
* DevTools: "Firefox NN"<br />
* Firefox: "Firefox NN"<br />
* Firefox Build System: "Firefox NN"<br />
* Firefox for Android: "Firefox NN"<br />
* GeckoView: "Firefox NN"<br />
* MailNews Core: "NN"<br />
* Remote Protocol: "Firefox NN"<br />
* SeaMonkey: "SeaMonkey N.0"<br />
* Thunderbird: "NN"<br />
* Toolkit: "Firefox NN"<br />
* WebExtensions: "Firefox NN"<br />
<br />
= Adding a "rapid release" version to SeaMonkey =<br />
<br />
To determine the correct version number to add, check with a SeaMonkey owner first (Callek, or any member of the [http://www.seamonkey-project.org/about SeaMonkey Council]).<br />
<br />
these steps use 2.27 as an example.<br />
<br />
use the [https://bugzilla.mozilla.org/page.cgi?id=tracking_flags_admin_list.html release tracking flags admin page] to:<br />
* copy the prior flags and edit as per firefox<br />
** copy cf_tracking_seamonkey226 to cf_tracking_seamonkey_227<br />
** copy cf_status_seamonkey226 to cf_status_seamonkey_227<br />
* deactivate old flags for previous (now released) versions (N-4)<br />
** deactivate cf_tracking_seamonkey223 and cf_status_seamonkey223<br />
<br />
use the [https://bugzilla.mozilla.org/editmilestones.cgi?product=SeaMonkey milestone admin page] to:<br />
* add a new milestone "seamonkey2.27"<br />
* move the --- milestone marker to between seamonkey2.26 and seamonkey2.27<br />
<br />
use the [https://bugzilla.mozilla.org/editversions.cgi?product=SeaMonkey version admin] page to:<br />
* add a new version "SeaMonkey 2.27 Branch"<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide&diff=1229537BMO/UserGuide2020-07-28T02:38:46Z<p>Emceeaich: /* Needinfo Flag */ update documentation</p>
<hr />
<div>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.<br />
<br />
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]. <br />
<br />
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). <br />
<br />
=Creating a Bugzilla Account=<br />
<br />
To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.<br />
<br />
==Create a Local Account==<br />
<br />
From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.<br />
<br />
==Log in With GitHub==<br />
<br />
If you have a GitHub account you can use it to log in and create an account.<br />
<br />
* First click "Log in".<br />
* Then click the Octocat/GitHub logo. <br />
* If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.<br />
* If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.<br />
* You'll be identified by the email address you use on GitHub.<br />
<br />
'''Note:''' If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.<br />
<br />
= Searching =<br />
''Omg, so many ways to search; why do we have so many, and how do they work?''<br />
<br />
== Quick Search ==<br />
''Quick Search rocks! You should use it.''<br />
<br />
== Advanced Search, Pronouns ==<br />
''Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.''<br />
<br />
== Other Searches (Instant, Simple, Google) ==<br />
''In case you were looking for more ways to search.''<br />
<br />
= Bugmail =<br />
<br />
''Bugmail'' is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.<br />
<br />
== Filtering ==<br />
''Too much bugmail? Filter on BMO itself and/or via x-headers!''<br />
<br />
=== Filtering with GMail ===<br />
GMail's ability to filter on headers is somewhat limited. We've got a separate, complete [[/Filtering Bugzilla Email in GMail|guide]] on advanced bugmail filtering with GMail.<br />
<br />
= Users =<br />
<br />
Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.<br />
<br />
== User Profiles ==<br />
<br />
By selecting [https://bugzilla.mozilla.org/user_profile My Profile] from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.<br />
<br />
There's a [[BMO/UserProfiles|project page]] about User Profiles which has brief description of the fields.<br />
<br />
== "New to Bugzilla" ==<br />
<br />
A user's comments will be tagged as "New to Bugzilla" under the following conditions:<br />
* The user does ''not'' have editbugs access.<br />
* The user has made 25 comments or less '''OR''' the account is less than 60 days old.<br />
<br />
The "New to Bugzilla" indicator doesn't mean ''this account was created recently'', it's an indicator that ''this user hasn't used Bugzilla much, please tailor your responses accordingly''.<br />
<br />
This is only displayed to people with canconfirm or editbugs access.<br />
<br />
= Understanding, Editing, and Filing Bugs =<br />
<br />
== Standard Bug Fields ==<br />
Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described [[BMO/UserGuide/BugFields|here]].<br />
<br />
== Comment Tagging ==<br />
Want to convey some out-of-band information on a comment? Tag it. <br />
Want to auto-collapse a spammy, abusive, or obsolete comment? [[BMO/Comment_Tagging|Tag it]].<br />
<br />
== Comment Editing == <br />
<br />
Some users can edit comments made on bugs, if you do so, please follow [[BMO/Editing_Comments|our guidelines]].<br />
<br />
== Keywords and the Whiteboard ==<br />
''What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?''<br />
<br />
'''Keywords''':<br />
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.<br />
<br />
'''Whiteboard''':<br />
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.<br />
<br />
== Tracking Flags ==<br />
''Who's doing the tracking? Should i even set these flags?''<br />
<br />
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.<br />
<br />
[[File:Tracking-flag-example.png|thumb]]<br />
<br />
Tracking flags have the values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value !! Meaning<br />
|-<br />
| --- || Default/Not nominated<br />
|-<br />
| ? || Bug is nominated for this release<br />
|-<br />
| + || Bug is tracked for this release<br />
|-<br />
| - || Bug will not be tracked for this release<br />
|-<br />
| blocking || Bug is considered a blocker for this release<br />
|}<br />
<br />
Most users will only be able to [[Release_Management/Release_Process#All_about_Flags|nominate a bug for tracking]] by setting the tracking flag for a release to ''?''. The Release Drivers group (which includes Release Management) will respond to the request for tracking.<br />
<br />
For example, a [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_beta&o1=equals&v1=%2B search for tracking Firefox Beta and "+"] would list the bugs which release managers decided to track for the Beta release of Firefox. <br />
<br />
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.<br />
<br />
== Status Flags ==<br />
<br />
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]. <br />
<br />
[[File:Status-flag-example.png|Thumb]]<br />
<br />
== Project Flags == <br />
<br />
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.<br />
<br />
== Needinfo Flag ==<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Common uses of ''needinfo'' include:<br />
<br />
* Asking a bug reporter for more information so that a bug can be triaged<br />
* Asking a subject matter expert for direction or clarification <br />
<br />
Please respond to ''needinfo'' requests quickly to keep others from being blocked. <br />
<br />
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. <br />
<br />
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.<br />
<br />
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].<br />
<br />
= Other Ways to use BMO and its Data =<br />
<br />
== Whining ==<br />
''Bugzilla can automatically send you buglists (requires canconfirm).''<br />
<br />
BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to [https://bugzilla.mozilla.org/editwhines.cgi create whines].<br />
<br />
== APIs ==<br />
''I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.''<br />
<br />
BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found [http://bmo.readthedocs.io/en/latest/api/index.html here].<br />
<br />
== Dashboards ==<br />
''Trying to answer the "what should i do today" question? Go no further than the dashboards.''<br />
<br />
[https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard] has some nice options for viewing lists of bugs that may be of interest to you.<br />
<br />
=Permissions and Groups=<br />
<br />
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org. <br />
<br />
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive. <br />
<br />
==How to apply for upgraded permissions==<br />
<br />
If you want '''canconfirm''', you can add it yourself using [https://bugzilla.mozilla.org/page.cgi?id=triage_request.html triage request form].<br />
<br />
If you want '''editbugs''', [https://mzl.la/2izLT4J file a new bug, including]:<br />
<br />
* The URLs of two bugs to which you have attached patches or testcases.<br />
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.<br />
<br />
'''Note:''' '''editbugs''' implies '''canconfirm''' there's no need to apply for both.<br />
<br />
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group '''everyone'''. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.<br />
<br />
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].<br />
<br />
= BMO vs Bugzilla =<br />
<br />
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.<br />
<br />
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]].<br />
<br />
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].<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide&diff=1229536BMO/UserGuide2020-07-28T02:23:58Z<p>Emceeaich: /* How to apply for upgraded permissions */ move BMO vs Bugzilla section to end</p>
<hr />
<div>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.<br />
<br />
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]. <br />
<br />
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). <br />
<br />
=Creating a Bugzilla Account=<br />
<br />
To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.<br />
<br />
==Create a Local Account==<br />
<br />
From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.<br />
<br />
==Log in With GitHub==<br />
<br />
If you have a GitHub account you can use it to log in and create an account.<br />
<br />
* First click "Log in".<br />
* Then click the Octocat/GitHub logo. <br />
* If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.<br />
* If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.<br />
* You'll be identified by the email address you use on GitHub.<br />
<br />
'''Note:''' If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.<br />
<br />
= Searching =<br />
''Omg, so many ways to search; why do we have so many, and how do they work?''<br />
<br />
== Quick Search ==<br />
''Quick Search rocks! You should use it.''<br />
<br />
== Advanced Search, Pronouns ==<br />
''Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.''<br />
<br />
== Other Searches (Instant, Simple, Google) ==<br />
''In case you were looking for more ways to search.''<br />
<br />
= Bugmail =<br />
<br />
''Bugmail'' is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.<br />
<br />
== Filtering ==<br />
''Too much bugmail? Filter on BMO itself and/or via x-headers!''<br />
<br />
=== Filtering with GMail ===<br />
GMail's ability to filter on headers is somewhat limited. We've got a separate, complete [[/Filtering Bugzilla Email in GMail|guide]] on advanced bugmail filtering with GMail.<br />
<br />
= Users =<br />
<br />
Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.<br />
<br />
== User Profiles ==<br />
<br />
By selecting [https://bugzilla.mozilla.org/user_profile My Profile] from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.<br />
<br />
There's a [[BMO/UserProfiles|project page]] about User Profiles which has brief description of the fields.<br />
<br />
== "New to Bugzilla" ==<br />
<br />
A user's comments will be tagged as "New to Bugzilla" under the following conditions:<br />
* The user does ''not'' have editbugs access.<br />
* The user has made 25 comments or less '''OR''' the account is less than 60 days old.<br />
<br />
The "New to Bugzilla" indicator doesn't mean ''this account was created recently'', it's an indicator that ''this user hasn't used Bugzilla much, please tailor your responses accordingly''.<br />
<br />
This is only displayed to people with canconfirm or editbugs access.<br />
<br />
= Understanding, Editing, and Filing Bugs =<br />
<br />
== Standard Bug Fields ==<br />
Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described [[BMO/UserGuide/BugFields|here]].<br />
<br />
== Comment Tagging ==<br />
Want to convey some out-of-band information on a comment? Tag it. <br />
Want to auto-collapse a spammy, abusive, or obsolete comment? [[BMO/Comment_Tagging|Tag it]].<br />
<br />
== Comment Editing == <br />
<br />
Some users can edit comments made on bugs, if you do so, please follow [[BMO/Editing_Comments|our guidelines]].<br />
<br />
== Keywords and the Whiteboard ==<br />
''What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?''<br />
<br />
'''Keywords''':<br />
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.<br />
<br />
'''Whiteboard''':<br />
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.<br />
<br />
== Tracking Flags ==<br />
''Who's doing the tracking? Should i even set these flags?''<br />
<br />
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.<br />
<br />
[[File:Tracking-flag-example.png|thumb]]<br />
<br />
Tracking flags have the values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value !! Meaning<br />
|-<br />
| --- || Default/Not nominated<br />
|-<br />
| ? || Bug is nominated for this release<br />
|-<br />
| + || Bug is tracked for this release<br />
|-<br />
| - || Bug will not be tracked for this release<br />
|-<br />
| blocking || Bug is considered a blocker for this release<br />
|}<br />
<br />
Most users will only be able to [[Release_Management/Release_Process#All_about_Flags|nominate a bug for tracking]] by setting the tracking flag for a release to ''?''. The Release Drivers group (which includes Release Management) will respond to the request for tracking.<br />
<br />
For example, a [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_beta&o1=equals&v1=%2B search for tracking Firefox Beta and "+"] would list the bugs which release managers decided to track for the Beta release of Firefox. <br />
<br />
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.<br />
<br />
== Status Flags ==<br />
<br />
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]. <br />
<br />
[[File:Status-flag-example.png|Thumb]]<br />
<br />
== Project Flags == <br />
<br />
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.<br />
<br />
== Needinfo Flag ==<br />
''It's good and you should use it.''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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].<br />
<br />
= Other Ways to use BMO and its Data =<br />
<br />
== Whining ==<br />
''Bugzilla can automatically send you buglists (requires canconfirm).''<br />
<br />
BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to [https://bugzilla.mozilla.org/editwhines.cgi create whines].<br />
<br />
== APIs ==<br />
''I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.''<br />
<br />
BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found [http://bmo.readthedocs.io/en/latest/api/index.html here].<br />
<br />
== Dashboards ==<br />
''Trying to answer the "what should i do today" question? Go no further than the dashboards.''<br />
<br />
[https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard] has some nice options for viewing lists of bugs that may be of interest to you.<br />
<br />
=Permissions and Groups=<br />
<br />
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org. <br />
<br />
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive. <br />
<br />
==How to apply for upgraded permissions==<br />
<br />
If you want '''canconfirm''', you can add it yourself using [https://bugzilla.mozilla.org/page.cgi?id=triage_request.html triage request form].<br />
<br />
If you want '''editbugs''', [https://mzl.la/2izLT4J file a new bug, including]:<br />
<br />
* The URLs of two bugs to which you have attached patches or testcases.<br />
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.<br />
<br />
'''Note:''' '''editbugs''' implies '''canconfirm''' there's no need to apply for both.<br />
<br />
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group '''everyone'''. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.<br />
<br />
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].<br />
<br />
= BMO vs Bugzilla =<br />
<br />
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.<br />
<br />
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]].<br />
<br />
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].<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide&diff=1229535BMO/UserGuide2020-07-28T02:23:14Z<p>Emceeaich: /* BMO vs Bugzilla */ move section</p>
<hr />
<div>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.<br />
<br />
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]. <br />
<br />
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). <br />
<br />
=Creating a Bugzilla Account=<br />
<br />
To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.<br />
<br />
==Create a Local Account==<br />
<br />
From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.<br />
<br />
==Log in With GitHub==<br />
<br />
If you have a GitHub account you can use it to log in and create an account.<br />
<br />
* First click "Log in".<br />
* Then click the Octocat/GitHub logo. <br />
* If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.<br />
* If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.<br />
* You'll be identified by the email address you use on GitHub.<br />
<br />
'''Note:''' If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.<br />
<br />
= Searching =<br />
''Omg, so many ways to search; why do we have so many, and how do they work?''<br />
<br />
== Quick Search ==<br />
''Quick Search rocks! You should use it.''<br />
<br />
== Advanced Search, Pronouns ==<br />
''Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.''<br />
<br />
== Other Searches (Instant, Simple, Google) ==<br />
''In case you were looking for more ways to search.''<br />
<br />
= Bugmail =<br />
<br />
''Bugmail'' is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.<br />
<br />
== Filtering ==<br />
''Too much bugmail? Filter on BMO itself and/or via x-headers!''<br />
<br />
=== Filtering with GMail ===<br />
GMail's ability to filter on headers is somewhat limited. We've got a separate, complete [[/Filtering Bugzilla Email in GMail|guide]] on advanced bugmail filtering with GMail.<br />
<br />
= Users =<br />
<br />
Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.<br />
<br />
== User Profiles ==<br />
<br />
By selecting [https://bugzilla.mozilla.org/user_profile My Profile] from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.<br />
<br />
There's a [[BMO/UserProfiles|project page]] about User Profiles which has brief description of the fields.<br />
<br />
== "New to Bugzilla" ==<br />
<br />
A user's comments will be tagged as "New to Bugzilla" under the following conditions:<br />
* The user does ''not'' have editbugs access.<br />
* The user has made 25 comments or less '''OR''' the account is less than 60 days old.<br />
<br />
The "New to Bugzilla" indicator doesn't mean ''this account was created recently'', it's an indicator that ''this user hasn't used Bugzilla much, please tailor your responses accordingly''.<br />
<br />
This is only displayed to people with canconfirm or editbugs access.<br />
<br />
= Understanding, Editing, and Filing Bugs =<br />
<br />
== Standard Bug Fields ==<br />
Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described [[BMO/UserGuide/BugFields|here]].<br />
<br />
== Comment Tagging ==<br />
Want to convey some out-of-band information on a comment? Tag it. <br />
Want to auto-collapse a spammy, abusive, or obsolete comment? [[BMO/Comment_Tagging|Tag it]].<br />
<br />
== Comment Editing == <br />
<br />
Some users can edit comments made on bugs, if you do so, please follow [[BMO/Editing_Comments|our guidelines]].<br />
<br />
== Keywords and the Whiteboard ==<br />
''What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?''<br />
<br />
'''Keywords''':<br />
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.<br />
<br />
'''Whiteboard''':<br />
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.<br />
<br />
== Tracking Flags ==<br />
''Who's doing the tracking? Should i even set these flags?''<br />
<br />
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.<br />
<br />
[[File:Tracking-flag-example.png|thumb]]<br />
<br />
Tracking flags have the values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value !! Meaning<br />
|-<br />
| --- || Default/Not nominated<br />
|-<br />
| ? || Bug is nominated for this release<br />
|-<br />
| + || Bug is tracked for this release<br />
|-<br />
| - || Bug will not be tracked for this release<br />
|-<br />
| blocking || Bug is considered a blocker for this release<br />
|}<br />
<br />
Most users will only be able to [[Release_Management/Release_Process#All_about_Flags|nominate a bug for tracking]] by setting the tracking flag for a release to ''?''. The Release Drivers group (which includes Release Management) will respond to the request for tracking.<br />
<br />
For example, a [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_beta&o1=equals&v1=%2B search for tracking Firefox Beta and "+"] would list the bugs which release managers decided to track for the Beta release of Firefox. <br />
<br />
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.<br />
<br />
== Status Flags ==<br />
<br />
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]. <br />
<br />
[[File:Status-flag-example.png|Thumb]]<br />
<br />
== Project Flags == <br />
<br />
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.<br />
<br />
== Needinfo Flag ==<br />
''It's good and you should use it.''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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].<br />
<br />
= Other Ways to use BMO and its Data =<br />
<br />
== Whining ==<br />
''Bugzilla can automatically send you buglists (requires canconfirm).''<br />
<br />
BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to [https://bugzilla.mozilla.org/editwhines.cgi create whines].<br />
<br />
== APIs ==<br />
''I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.''<br />
<br />
BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found [http://bmo.readthedocs.io/en/latest/api/index.html here].<br />
<br />
== Dashboards ==<br />
''Trying to answer the "what should i do today" question? Go no further than the dashboards.''<br />
<br />
[https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard] has some nice options for viewing lists of bugs that may be of interest to you.<br />
<br />
=Permissions and Groups=<br />
<br />
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org. <br />
<br />
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive. <br />
<br />
==How to apply for upgraded permissions==<br />
<br />
If you want '''canconfirm''', you can add it yourself using [https://bugzilla.mozilla.org/page.cgi?id=triage_request.html triage request form].<br />
<br />
If you want '''editbugs''', [https://mzl.la/2izLT4J file a new bug, including]:<br />
<br />
* The URLs of two bugs to which you have attached patches or testcases.<br />
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.<br />
<br />
'''Note:''' '''editbugs''' implies '''canconfirm''' there's no need to apply for both.<br />
<br />
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group '''everyone'''. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.<br />
<br />
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide&diff=1229534BMO/UserGuide2020-07-28T02:22:42Z<p>Emceeaich: Link to Bug Handling docs</p>
<hr />
<div>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.<br />
<br />
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]. <br />
<br />
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). <br />
<br />
= BMO vs Bugzilla =<br />
<br />
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.<br />
<br />
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]].<br />
<br />
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].<br />
<br />
=Creating a Bugzilla Account=<br />
<br />
To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.<br />
<br />
==Create a Local Account==<br />
<br />
From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.<br />
<br />
==Log in With GitHub==<br />
<br />
If you have a GitHub account you can use it to log in and create an account.<br />
<br />
* First click "Log in".<br />
* Then click the Octocat/GitHub logo. <br />
* If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.<br />
* If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.<br />
* You'll be identified by the email address you use on GitHub.<br />
<br />
'''Note:''' If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.<br />
<br />
= Searching =<br />
''Omg, so many ways to search; why do we have so many, and how do they work?''<br />
<br />
== Quick Search ==<br />
''Quick Search rocks! You should use it.''<br />
<br />
== Advanced Search, Pronouns ==<br />
''Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.''<br />
<br />
== Other Searches (Instant, Simple, Google) ==<br />
''In case you were looking for more ways to search.''<br />
<br />
= Bugmail =<br />
<br />
''Bugmail'' is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.<br />
<br />
== Filtering ==<br />
''Too much bugmail? Filter on BMO itself and/or via x-headers!''<br />
<br />
=== Filtering with GMail ===<br />
GMail's ability to filter on headers is somewhat limited. We've got a separate, complete [[/Filtering Bugzilla Email in GMail|guide]] on advanced bugmail filtering with GMail.<br />
<br />
= Users =<br />
<br />
Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.<br />
<br />
== User Profiles ==<br />
<br />
By selecting [https://bugzilla.mozilla.org/user_profile My Profile] from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.<br />
<br />
There's a [[BMO/UserProfiles|project page]] about User Profiles which has brief description of the fields.<br />
<br />
== "New to Bugzilla" ==<br />
<br />
A user's comments will be tagged as "New to Bugzilla" under the following conditions:<br />
* The user does ''not'' have editbugs access.<br />
* The user has made 25 comments or less '''OR''' the account is less than 60 days old.<br />
<br />
The "New to Bugzilla" indicator doesn't mean ''this account was created recently'', it's an indicator that ''this user hasn't used Bugzilla much, please tailor your responses accordingly''.<br />
<br />
This is only displayed to people with canconfirm or editbugs access.<br />
<br />
= Understanding, Editing, and Filing Bugs =<br />
<br />
== Standard Bug Fields ==<br />
Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described [[BMO/UserGuide/BugFields|here]].<br />
<br />
== Comment Tagging ==<br />
Want to convey some out-of-band information on a comment? Tag it. <br />
Want to auto-collapse a spammy, abusive, or obsolete comment? [[BMO/Comment_Tagging|Tag it]].<br />
<br />
== Comment Editing == <br />
<br />
Some users can edit comments made on bugs, if you do so, please follow [[BMO/Editing_Comments|our guidelines]].<br />
<br />
== Keywords and the Whiteboard ==<br />
''What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?''<br />
<br />
'''Keywords''':<br />
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.<br />
<br />
'''Whiteboard''':<br />
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.<br />
<br />
== Tracking Flags ==<br />
''Who's doing the tracking? Should i even set these flags?''<br />
<br />
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.<br />
<br />
[[File:Tracking-flag-example.png|thumb]]<br />
<br />
Tracking flags have the values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value !! Meaning<br />
|-<br />
| --- || Default/Not nominated<br />
|-<br />
| ? || Bug is nominated for this release<br />
|-<br />
| + || Bug is tracked for this release<br />
|-<br />
| - || Bug will not be tracked for this release<br />
|-<br />
| blocking || Bug is considered a blocker for this release<br />
|}<br />
<br />
Most users will only be able to [[Release_Management/Release_Process#All_about_Flags|nominate a bug for tracking]] by setting the tracking flag for a release to ''?''. The Release Drivers group (which includes Release Management) will respond to the request for tracking.<br />
<br />
For example, a [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_beta&o1=equals&v1=%2B search for tracking Firefox Beta and "+"] would list the bugs which release managers decided to track for the Beta release of Firefox. <br />
<br />
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.<br />
<br />
== Status Flags ==<br />
<br />
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]. <br />
<br />
[[File:Status-flag-example.png|Thumb]]<br />
<br />
== Project Flags == <br />
<br />
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.<br />
<br />
== Needinfo Flag ==<br />
''It's good and you should use it.''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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].<br />
<br />
= Other Ways to use BMO and its Data =<br />
<br />
== Whining ==<br />
''Bugzilla can automatically send you buglists (requires canconfirm).''<br />
<br />
BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to [https://bugzilla.mozilla.org/editwhines.cgi create whines].<br />
<br />
== APIs ==<br />
''I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.''<br />
<br />
BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found [http://bmo.readthedocs.io/en/latest/api/index.html here].<br />
<br />
== Dashboards ==<br />
''Trying to answer the "what should i do today" question? Go no further than the dashboards.''<br />
<br />
[https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard] has some nice options for viewing lists of bugs that may be of interest to you.<br />
<br />
=Permissions and Groups=<br />
<br />
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org. <br />
<br />
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive. <br />
<br />
==How to apply for upgraded permissions==<br />
<br />
If you want '''canconfirm''', you can add it yourself using [https://bugzilla.mozilla.org/page.cgi?id=triage_request.html triage request form].<br />
<br />
If you want '''editbugs''', [https://mzl.la/2izLT4J file a new bug, including]:<br />
<br />
* The URLs of two bugs to which you have attached patches or testcases.<br />
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.<br />
<br />
'''Note:''' '''editbugs''' implies '''canconfirm''' there's no need to apply for both.<br />
<br />
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group '''everyone'''. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.<br />
<br />
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide&diff=1229533BMO/UserGuide2020-07-28T02:16:38Z<p>Emceeaich: Remove no-longer supported documentation from introduction</p>
<hr />
<div>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.<br />
<br />
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!<br />
<br />
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!<br />
<br />
= BMO vs Bugzilla =<br />
<br />
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.<br />
<br />
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]].<br />
<br />
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].<br />
<br />
=Creating a Bugzilla Account=<br />
<br />
To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.<br />
<br />
==Create a Local Account==<br />
<br />
From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.<br />
<br />
==Log in With GitHub==<br />
<br />
If you have a GitHub account you can use it to log in and create an account.<br />
<br />
* First click "Log in".<br />
* Then click the Octocat/GitHub logo. <br />
* If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.<br />
* If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.<br />
* You'll be identified by the email address you use on GitHub.<br />
<br />
'''Note:''' If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.<br />
<br />
= Searching =<br />
''Omg, so many ways to search; why do we have so many, and how do they work?''<br />
<br />
== Quick Search ==<br />
''Quick Search rocks! You should use it.''<br />
<br />
== Advanced Search, Pronouns ==<br />
''Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.''<br />
<br />
== Other Searches (Instant, Simple, Google) ==<br />
''In case you were looking for more ways to search.''<br />
<br />
= Bugmail =<br />
<br />
''Bugmail'' is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.<br />
<br />
== Filtering ==<br />
''Too much bugmail? Filter on BMO itself and/or via x-headers!''<br />
<br />
=== Filtering with GMail ===<br />
GMail's ability to filter on headers is somewhat limited. We've got a separate, complete [[/Filtering Bugzilla Email in GMail|guide]] on advanced bugmail filtering with GMail.<br />
<br />
= Users =<br />
<br />
Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.<br />
<br />
== User Profiles ==<br />
<br />
By selecting [https://bugzilla.mozilla.org/user_profile My Profile] from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.<br />
<br />
There's a [[BMO/UserProfiles|project page]] about User Profiles which has brief description of the fields.<br />
<br />
== "New to Bugzilla" ==<br />
<br />
A user's comments will be tagged as "New to Bugzilla" under the following conditions:<br />
* The user does ''not'' have editbugs access.<br />
* The user has made 25 comments or less '''OR''' the account is less than 60 days old.<br />
<br />
The "New to Bugzilla" indicator doesn't mean ''this account was created recently'', it's an indicator that ''this user hasn't used Bugzilla much, please tailor your responses accordingly''.<br />
<br />
This is only displayed to people with canconfirm or editbugs access.<br />
<br />
= Understanding, Editing, and Filing Bugs =<br />
<br />
== Standard Bug Fields ==<br />
Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described [[BMO/UserGuide/BugFields|here]].<br />
<br />
== Comment Tagging ==<br />
Want to convey some out-of-band information on a comment? Tag it. <br />
Want to auto-collapse a spammy, abusive, or obsolete comment? [[BMO/Comment_Tagging|Tag it]].<br />
<br />
== Comment Editing == <br />
<br />
Some users can edit comments made on bugs, if you do so, please follow [[BMO/Editing_Comments|our guidelines]].<br />
<br />
== Keywords and the Whiteboard ==<br />
''What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?''<br />
<br />
'''Keywords''':<br />
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.<br />
<br />
'''Whiteboard''':<br />
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.<br />
<br />
== Tracking Flags ==<br />
''Who's doing the tracking? Should i even set these flags?''<br />
<br />
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.<br />
<br />
[[File:Tracking-flag-example.png|thumb]]<br />
<br />
Tracking flags have the values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value !! Meaning<br />
|-<br />
| --- || Default/Not nominated<br />
|-<br />
| ? || Bug is nominated for this release<br />
|-<br />
| + || Bug is tracked for this release<br />
|-<br />
| - || Bug will not be tracked for this release<br />
|-<br />
| blocking || Bug is considered a blocker for this release<br />
|}<br />
<br />
Most users will only be able to [[Release_Management/Release_Process#All_about_Flags|nominate a bug for tracking]] by setting the tracking flag for a release to ''?''. The Release Drivers group (which includes Release Management) will respond to the request for tracking.<br />
<br />
For example, a [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_beta&o1=equals&v1=%2B search for tracking Firefox Beta and "+"] would list the bugs which release managers decided to track for the Beta release of Firefox. <br />
<br />
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.<br />
<br />
== Status Flags ==<br />
<br />
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]. <br />
<br />
[[File:Status-flag-example.png|Thumb]]<br />
<br />
== Project Flags == <br />
<br />
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.<br />
<br />
== Needinfo Flag ==<br />
''It's good and you should use it.''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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].<br />
<br />
= Other Ways to use BMO and its Data =<br />
<br />
== Whining ==<br />
''Bugzilla can automatically send you buglists (requires canconfirm).''<br />
<br />
BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to [https://bugzilla.mozilla.org/editwhines.cgi create whines].<br />
<br />
== APIs ==<br />
''I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.''<br />
<br />
BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found [http://bmo.readthedocs.io/en/latest/api/index.html here].<br />
<br />
== Dashboards ==<br />
''Trying to answer the "what should i do today" question? Go no further than the dashboards.''<br />
<br />
[https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard] has some nice options for viewing lists of bugs that may be of interest to you.<br />
<br />
=Permissions and Groups=<br />
<br />
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org. <br />
<br />
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive. <br />
<br />
==How to apply for upgraded permissions==<br />
<br />
If you want '''canconfirm''', you can add it yourself using [https://bugzilla.mozilla.org/page.cgi?id=triage_request.html triage request form].<br />
<br />
If you want '''editbugs''', [https://mzl.la/2izLT4J file a new bug, including]:<br />
<br />
* The URLs of two bugs to which you have attached patches or testcases.<br />
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.<br />
<br />
'''Note:''' '''editbugs''' implies '''canconfirm''' there's no need to apply for both.<br />
<br />
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group '''everyone'''. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.<br />
<br />
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/new-version&diff=1229504BMO/new-version2020-07-27T06:26:25Z<p>Emceeaich: Changes for https://bugzilla.mozilla.org/show_bug.cgi?id=1553533</p>
<hr />
<div>{{note|These activities should be completed before or at the same time we have the merge for the next major release of Firefox.}}<br />
<br />
= Adding a new "rapid release" version to Firefox/Core/Thunderbird = <br />
<br />
== Status and Release Flags == <br />
<br />
The flags for release status and tracking are created with the [https://bugzilla.mozilla.org/page.cgi?id=tracking_flags_admin_list.html release tracking flags administration page], not the "custom fields" page.<br />
<br />
This is now done by the Release Management team.<br />
<br />
* Create a copy of the current release's version of the following flags, updating the name and sort-order:<br />
** copy cf_tracking_firefox''N'' to cf_tracking_firefox''N+1''<br />
** copy cf_status_firefox''N'' to cf_status_firefox''N+1''<br />
<br />
Only members of the <code>mozilla-next-drivers</code> group may set a tracking flag to something other than ''?''. Members of the <code>canconfirm</code> group can set status flags or set a tracking flag to ''?''.<br />
<br />
** copy cf_tracking_thunderbird''N'' to cf_tracking_thunderbird''N+1''<br />
** copy cf_status_thunderbird''N'' to cf_status_thunderbird''N_1''<br />
* edit the flags for previous (now released) versions (N-3) and uncheck 'active':<br />
** cf_tracking_firefox''N-3''<br />
** cf_status_firefox''N-3''<br />
** cf_tracking_thunderbird''N-3''<br />
** cf_status_thunderbird''N-3''<br />
<br />
* update cf_tracking_firefox_relnote (which is relnote-firefox in the UI) (add N+1, disable N-3 except for ESR)<br />
* update the current esr tracking field: cf_tracking_firefox_esr* (add N+2)<br />
<br />
== Milestones ==<br />
<br />
* Use the [https://bugzilla.mozilla.org/editmilestones.cgi milestone admin page] to add new milestones<br />
* Move the --- milestone marker to between N-1 and N for all products where a milestone was added<br />
* Leave all milestones from most recent ESR to nightly (and '---' and 'Future') active. Disable others <br />
* ''Don't delete old milestones''<br />
<br />
=== Products ===<br />
<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Calendar Calendar]: "Thunderbird N.0"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Chat%20Core Chat Core]: "Instantbird N"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Cloud%20Services Cloud Services]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Core Core]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=DevTools DevTools]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox Firefox]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox%20Build%20System Firefox Build System]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox%20for%20Android Firefox for Android]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=GeckoView GeckoView]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Remote%20Protocol Remote Protocol]: "NN Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Toolkit Toolkit]: "NN Branch<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=WebExtensions WebExtensions]: "NN Branch"<br />
<br />
== Versions ==<br />
<br />
Use the [https://bugzilla.mozilla.org/editversions.cgi version admin page] to add new versions.<br />
<br />
* Calendar: "Thunderbird NN"<br />
* Chat Core: "NN"<br />
* Cloud Services: "Firefox NN"<br />
* Core: "Firefox NN"<br />
* DevTools: "Firefox NN"<br />
* Firefox: "Firefox NN"<br />
* Firefox Build System: "Firefox NN"<br />
* Firefox for Android: "Firefox NN"<br />
* GeckoView: "Firefox NN"<br />
* MailNews Core: "NN"<br />
* Remote Protocol: "Firefox NN"<br />
* SeaMonkey: "SeaMonkey N.0"<br />
* Thunderbird: "NN"<br />
* Toolkit: "Firefox NN"<br />
* WebExtensions: "Firefox NN"<br />
<br />
= Adding a "rapid release" version to SeaMonkey =<br />
<br />
To determine the correct version number to add, check with a SeaMonkey owner first (Callek, or any member of the [http://www.seamonkey-project.org/about SeaMonkey Council]).<br />
<br />
these steps use 2.27 as an example.<br />
<br />
use the [https://bugzilla.mozilla.org/page.cgi?id=tracking_flags_admin_list.html release tracking flags admin page] to:<br />
* copy the prior flags and edit as per firefox<br />
** copy cf_tracking_seamonkey226 to cf_tracking_seamonkey_227<br />
** copy cf_status_seamonkey226 to cf_status_seamonkey_227<br />
* deactivate old flags for previous (now released) versions (N-4)<br />
** deactivate cf_tracking_seamonkey223 and cf_status_seamonkey223<br />
<br />
use the [https://bugzilla.mozilla.org/editmilestones.cgi?product=SeaMonkey milestone admin page] to:<br />
* add a new milestone "seamonkey2.27"<br />
* move the --- milestone marker to between seamonkey2.26 and seamonkey2.27<br />
<br />
use the [https://bugzilla.mozilla.org/editversions.cgi?product=SeaMonkey version admin] page to:<br />
* add a new version "SeaMonkey 2.27 Branch"<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BugBot&diff=1227263BugBot2020-05-17T22:39:26Z<p>Emceeaich: /* Without autofix */ cleanup</p>
<hr />
<div>{{ DISPLAYTITLE:Autonag: Bugzilla triaging bot and alerting system }}<br />
<br />
<p style="font-size: larger; font-weight:bold;"><br />
This page lists all the actions done by the [https://github.com/mozilla/relman-auto-nag/ Autonag bot].</p><br />
<br />
= Introduction =<br />
Every day hundreds of tickets are opened in [https://bugzilla.mozilla.org Bugzilla] which track the tasks, defects and enhancements needed for the development of Firefox and other Mozilla projects. <br />
Triaging and priotirizing these bugs are an essential part of our development process and we automate part of this process so as to increase our development turn around and improve the quality of our bugs metadata. The set of scripts we use to improve the quality of our bugs, decrease our triaging time and help Release Management ship better quality software is called '''Autonag'''.<br />
<br />
Initially created as an alerting system (by email) to our triagers, Autonag rules now also make changes to our bugs metadata on Bugzilla so as to fix inconsistencies. <br />
<br />
Rules that change automatically some data in Bugzilla (change a priority, needinfo somebody, close a bug…) are called "Rules with Autofix" and those rules are applied once per hour. ''For now, security bugs aren't touched.''<br />
<br />
Rules that do not change data but have other results such as generate a report or send an email are called "Rules without Autofix". Rules without autofix are processed once a day (at 2PM CET).<br />
<br />
= Rules =<br />
== With autofix ==<br />
<br />
{{AutonagRule<br />
| Rule name = Bug assigned but marked as <code>UNCONFIRMED</code><br />
| Purpose = Mitigate an issue in Bugzilla (bugs reported by new users are not tagged as <code>NEW</code><br />
| Action = Change the status from <code>UNCONFIRMED</code> to <code>ASSIGNED</code> if there is an assignee<br />
| Example = 1495908<br />
| Source = assignee_but_unconfirmed.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Regression keyword is missing<br />
| Purpose = Regression keyword is important to differentiate an actual defect<br />
| Action = Sets the <code>regression</code> keyword on bugs with the <code>regression-range-wanted</code> keyword is set<br />
| Example = 1461034<br />
| Source = has_regression_range_no_keyword.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remove <code>leave-open</code> keyword on closed bug<br />
| Purpose = Clean up a mismatch in metadata<br />
| Action = If a bug is closed but the <code>leave-open</code> keyword is still set, remove it<br />
| Example = 1382185<br />
| Source = leave_open.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = [meta] in title but not in keywords<br />
| Purpose = Improve metedata quality<br />
| Action = Adds the <code>meta</code> keyword if the bug title starts by [META]<br />
| Example = 1435799 <br />
| Source = meta_summary_missing.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Update Firefox Status flags for bugs reopened during Nightly cycle<br />
| Purpose = Avoids potential issues for sheriffs and release managers<br />
| Action = Set <code>firefox-status</code> flag back from ''fixed'' to ''affected''<br />
| Example = 1495962<br />
| Source = nightly_reopened.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bug with no assignee but a patch landed<br />
| Purpose = Attribute unassigned bug to the developer that fixed it<br />
| Action = The ASSIGNEE field on the bug is changed from nobody@mozilla.org to the author of the patch that landed in mozilla-central<br />
| Example = 1514338<br />
| Source = no_assignee.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Close crash bugs with no crashes over 12 weeks<br />
| Purpose = Reduce the backlog of bugs to check for Release Managers <br />
| Action = Crash bugs without any crash reports for more than 12 weeks<br />
| Example = 1470864<br />
| Source = no_crashes.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remove <code>stalled</code> keyword on closed bugs<br />
| Purpose = Fix inconsistency between metadata and bug status<br />
| Action = If a bug is marked as <code>FIXED</code> and also has a <code>stalled</code> keyword set, the keyword is removed<br />
| Example = 1491624<br />
| Source = stalled.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Has meta keyword but not [meta] in the bug title<br />
| Purpose = Having [meta] in the bug title helps with quick search results<br />
| Action = If a bug has the meta keyword set, [meta] is added to the bug title<br />
| Example = 1257692<br />
| Source = summary_meta_missing.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Set a Firefox status flag for beta if there is one for nightly and release<br />
| Purpose = Fix inconsistency in Firefox status flags that can lead to a bug going undetected by Release Managers during the beta cycle<br />
| Action = If a status exists for Firefox N-1 and for Firefox N+1, guess a value for Firefox N <br />
| Example = 1500273<br />
| Source = missing_beta_status.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Increase priority of bugs tracked by Release Managers<br />
| Purpose = Priotitizes bugs needing an action for shipping quality software<br />
| Action = If a bug is tracked by a Release Manager, update the priority (P2 for nightly, P1 for the rest)<br />
| Example = 1515946,1508277,1512493<br />
| Source = mismatch_priority_tracking_release.py<br />
| Note = There are multiple files mismatch-priority-tracking-*.py, one per channel<br />
}}<br />
{{AutonagRule<br />
| Rule name = Add <code>regression</code> keywords to bugs (uses Machine Learning)<br />
| Purpose = Surface regressions not filed as such<br />
| Action = If a bug is tracked by a Release Manager, update the priority (P2 for nightly, P1 for the rest)<br />
| Example = 1529139<br />
| Source = regression.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Move untriaged bug into the correct component (uses machine learning) <br />
| Purpose = Decrease manual triage time<br />
| Action = Uses machine learning to mass move bugs in Firefox::Untriaged into a better component<br />
| Example = 1530316 <br />
| Source = component.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Copy crash signature from duplicate bugs to main bugs<br />
| Purpose = Crash bugs marked as duplicate of another one may have a different crash signature. We need to consolidate all signatures in the bug where a patch to fix them is being worked on, other wise we may not fix them all<br />
| Action = If a crash bug is marked as a duplicate, the signatures it referenced are added to the new bug<br />
| Example = 1517205<br />
| Source = copy_duplicate_info.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Increase severity of bugs tracked by Release Managers<br />
| Purpose = Fix inconsistency in metadata<br />
| Action = If a bug is tracked for an upcoming release but it's severity field is low, the severity is increased<br />
| Example = 1538966<br />
| Source = tracked_bad_severity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner to set priority on bugs<br />
| Purpose = Every defect should have a severity set. Also bugs with no severity set are harder to prioritize for Release Managers with regards to the release (see [https://firefox-source-docs.mozilla.org/bug-mgmt/policies/triage-bugzilla.html#what-do-you-triage what-do-you-triage])<br />
| Action = The triage owner is needinfoed in Bugzilla or nagged via email to set a priority on bugs<br />
| Example = 1527818<br />
| Source = workflow/no_severity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner on P1 bugs with no activity<br />
| Purpose = Since P1 means that the bug should be fixed for the next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), the bug needs to show any progress in its resolution (or maybe the priority should be decreased)<br />
| Action = The triage owner is nagged via email to have a reminder<br />
| Example = 1507251<br />
| Source = workflow/p1_no_activity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner to find an assignee for P1 bugs with no assignee and no activity<br />
| Purpose = Since P1 means that the bug should be fixed for the next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), the bug urgently needs to have an assignee (or the priority should be decreased)<br />
| Action = The triage owner is needinfoed in Bugzilla or nagged via email to find an assignee on bugs<br />
| Example = 1541291<br />
| Source = workflow/p1_no_assignee.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Change the priority from P2 to P1 on assigned bug the merge day<br />
| Purpose = Since P2 means that the bug should be fixed for the next next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), when we are the merge day then this bug automatically becomes a P1.<br />
| Action = Update the priority to P1 and add a comment to explain.<br />
| Example = <br />
| Source = workflow/p2_merge_day.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Patch not landed <br />
| Purpose = Identify bugs with an unlanded r+ patch. Maybe the patch is now obsolete or the bug needs to have a sheriff land the code with the <code>checkin-needed</code> keyword set.<br />
| Action = The bug assignee is needinfoed in Bugzilla to ask her/him to have look<br />
| Example = 1496844<br />
| Source = not_landed.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Regression without regressed_by and some bug dependencies <br />
| Purpose = Identify regressions which have dependencies (blocks or depends_on) and an empty regressed_by, probably people forgot to use the new field.<br />
| Action = The bug assignee or the person who added some dependencies or the reporter is needinfoed to ask to fill regressed_by when it's possible.<br />
| Example = 1545797<br />
| Source = regression_without_regressed_by.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Product::Component changed after the priority has been set <br />
| Purpose = Identify bugs where Product::Component changed after the priority has been set. The priority is probably no more up-to-date and so triage owner needs to set it.<br />
| Action = Reset the priority to "--" with a comment explaining why the bot is doing that.<br />
| Example = 1546366<br />
| Source = prod_comp_changed_with_priority.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Close intermittent test failure bugs <br />
| Purpose = Close intermittent test failure bugs which are P5s, not marked <code>leave-open</code>, and have not had a new failure in 21 days.<br />
| Action = RESOLVE bug as INCOMPLETE with a comment explaining why the bot is doing this.<br />
| Example = 1577895<br />
| Source = close_intermittents.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Ask for a beta uplift request <br />
| Purpose = Identify bugs where a patch fixed a bug in nightly and beta is marked as affected.<br />
| Action = Needinfo the assignee to ask it's worth making an uplift request.<br />
| Example = 1620434<br />
| Source = uplift_beta.py<br />
}}<br />
<br />
== Without autofix ==<br />
<br />
<br />
{{AutonagRule<br />
| Rule name = Feature vs regression<br />
| Purpose = Fix inconsistency in bugs with both the <code>regression</code> and <code>feature</code> keywords set <br />
| Source = feature_regression.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Inactive bugs with the <code>leave-open</code> keyword set<br />
| Purpose = Help identify dead/inactive bugs<br />
| Action = Needinfo the triage owner if a bug is inactive but has the <code>leave-open</code> keyword set<br />
| Example = 1367072<br />
| Source = leave_open_no_activity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Inactive Meta bugs<br />
| Purpose = Help identify dead/inactive bugs<br />
| Action = Needinfo the triage owner if a meta bug has no activity and no dependencies set <br />
| Source = meta_no_deps_no_activity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Low-severity bug but tracked by a release manager <br />
| Purpose = Identify mismatch in metadata, a tracked bug should not have a severity lower than ''normal''<br />
| Source = mismatch-priority-tracking.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Alert for lack of feedback in a bug<br />
| Purpose = Increase reaction time on bugs prioritized by upper management or release managers<br />
| Action = If a bug as an unanswered NeedInfo request from a release manager or a director, send a warning email<br />
| Source = ni_from_manager.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with no severity and no activity<br />
| Purpose = Triage owners need to process the backlog<br />
| Action = Needinfo the triage owner (only :Overholt for now)<br />
| Example = 1503461<br />
| Source = ni_triage_owner.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with only one or two words in the summary<br />
| Purpose = Make sure the bug is actually useful, a two-words summary often indicates a poor quality bug report<br />
| Example = 1512823<br />
| Source = one_two_word_summary.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remind developers about tracked bugs<br />
| Purpose = Make sure that bugs tracked for the next release are addressed<br />
| Source = query_creator.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Reporter not answering to Needinfo request<br />
| Purpose = identify bugs stalled because we need more information fron the reporter to reproduce it<br />
| Source = reporter_with_ni.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Top crashers vs ''normal'' severity<br />
| Purpose = Consistency and help getting traction on bugs<br />
| Example = 1471692<br />
| Source = topcrash_bad_severity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Identify tracked bugs with a NeedInfo request<br />
| Purpose = Make sure that bugs tracked for a release or nominated for tracking which also have a NeedInfo request do not get stuck<br />
| Action = Send an email<br />
| Source = tracked_needinfo.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Tracked bugs untouched for a week<br />
| Purpose = Identify important bugs for a release which are not being acted upon <br />
| Action = Send an email<br />
| Source = tracking.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Regressed in upcoming release<br />
| Purpose = Identify potential regression<br />
| Action = Send an email with the list of bugs marked as non affecting a release but affecting the next one<br />
| Source = unaffected_affected_no_reg.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Identify unlanded uplifts to Beta and ESR<br />
| Purpose = Make sure that we ship with the bugs that we need<br />
| Action = Send an email wih the list of bugs with uplift requests not landed on the affected branch<br />
| Example = 1509394<br />
| Source = unlanded.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with high severity in Firefox::Untriaged<br />
| Purpose = Identify potentially important issues left untriaged<br />
| Source = untriage_important_sev.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = <code>Version</code> set but not <code>status_firefox</code><br />
| Purpose = The <code>Version</code> value is set automatically by Bugzilla on landing a patch but not the <code>status_firefoxXX</code><br />
| Action = Send an email<br />
| Source = version_affected.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Check release dates on the Wiki<br />
| Purpose = Verify the consistency of our release dates on wiki.mozilla.org as we use them in automation <br />
| Action = Send an email<br />
| Source = ../next_release.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Information about bugs landed during Soft Code Freeze<br />
| Purpose = List fixed bug with patches which landed in mozilla-central during the soft freeze week. The listing includes patch statistics.<br />
| Action = Send an email<br />
| Source = code_freeze_week.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Hightlight Fixed bugs in nightly we may want to uplift<br />
| Purpose = Identify potentially upliftable bugs. <br />
| Action = Send an email with the recent fixes, the affected branches and metadata for prioritization<br />
| Source = missed_uplifts.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = New user with a Needinfo request<br />
| Purpose = Help identify potentially unactionnable bugs per lack of information<br />
| Action = Send an email<br />
| Source = newbie_with_ni.py<br />
}}<br />
[[category:Release_Management|Autonag]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BugBot&diff=1227151BugBot2020-05-14T00:55:08Z<p>Emceeaich: /* With autofix */ update triage report</p>
<hr />
<div>{{ DISPLAYTITLE:Autonag: Bugzilla triaging bot and alerting system }}<br />
<br />
<p style="font-size: larger; font-weight:bold;"><br />
This page lists all the actions done by the [https://github.com/mozilla/relman-auto-nag/ Autonag bot].</p><br />
<br />
= Introduction =<br />
Every day hundreds of tickets are opened in [https://bugzilla.mozilla.org Bugzilla] which track the tasks, defects and enhancements needed for the development of Firefox and other Mozilla projects. <br />
Triaging and priotirizing these bugs are an essential part of our development process and we automate part of this process so as to increase our development turn around and improve the quality of our bugs metadata. The set of scripts we use to improve the quality of our bugs, decrease our triaging time and help Release Management ship better quality software is called '''Autonag'''.<br />
<br />
Initially created as an alerting system (by email) to our triagers, Autonag rules now also make changes to our bugs metadata on Bugzilla so as to fix inconsistencies. <br />
<br />
Rules that change automatically some data in Bugzilla (change a priority, needinfo somebody, close a bug…) are called "Rules with Autofix" and those rules are applied once per hour. ''For now, security bugs aren't touched.''<br />
<br />
Rules that do not change data but have other results such as generate a report or send an email are called "Rules without Autofix". Rules without autofix are processed once a day (at 2PM CET).<br />
<br />
= Rules =<br />
== With autofix ==<br />
<br />
{{AutonagRule<br />
| Rule name = Bug assigned but marked as <code>UNCONFIRMED</code><br />
| Purpose = Mitigate an issue in Bugzilla (bugs reported by new users are not tagged as <code>NEW</code><br />
| Action = Change the status from <code>UNCONFIRMED</code> to <code>ASSIGNED</code> if there is an assignee<br />
| Example = 1495908<br />
| Source = assignee_but_unconfirmed.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Regression keyword is missing<br />
| Purpose = Regression keyword is important to differentiate an actual defect<br />
| Action = Sets the <code>regression</code> keyword on bugs with the <code>regression-range-wanted</code> keyword is set<br />
| Example = 1461034<br />
| Source = has_regression_range_no_keyword.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remove <code>leave-open</code> keyword on closed bug<br />
| Purpose = Clean up a mismatch in metadata<br />
| Action = If a bug is closed but the <code>leave-open</code> keyword is still set, remove it<br />
| Example = 1382185<br />
| Source = leave_open.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = [meta] in title but not in keywords<br />
| Purpose = Improve metedata quality<br />
| Action = Adds the <code>meta</code> keyword if the bug title starts by [META]<br />
| Example = 1435799 <br />
| Source = meta_summary_missing.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Update Firefox Status flags for bugs reopened during Nightly cycle<br />
| Purpose = Avoids potential issues for sheriffs and release managers<br />
| Action = Set <code>firefox-status</code> flag back from ''fixed'' to ''affected''<br />
| Example = 1495962<br />
| Source = nightly_reopened.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bug with no assignee but a patch landed<br />
| Purpose = Attribute unassigned bug to the developer that fixed it<br />
| Action = The ASSIGNEE field on the bug is changed from nobody@mozilla.org to the author of the patch that landed in mozilla-central<br />
| Example = 1514338<br />
| Source = no_assignee.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Close crash bugs with no crashes over 12 weeks<br />
| Purpose = Reduce the backlog of bugs to check for Release Managers <br />
| Action = Crash bugs without any crash reports for more than 12 weeks<br />
| Example = 1470864<br />
| Source = no_crashes.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remove <code>stalled</code> keyword on closed bugs<br />
| Purpose = Fix inconsistency between metadata and bug status<br />
| Action = If a bug is marked as <code>FIXED</code> and also has a <code>stalled</code> keyword set, the keyword is removed<br />
| Example = 1491624<br />
| Source = stalled.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Has meta keyword but not [meta] in the bug title<br />
| Purpose = Having [meta] in the bug title helps with quick search results<br />
| Action = If a bug has the meta keyword set, [meta] is added to the bug title<br />
| Example = 1257692<br />
| Source = summary_meta_missing.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Set a Firefox status flag for beta if there is one for nightly and release<br />
| Purpose = Fix inconsistency in Firefox status flags that can lead to a bug going undetected by Release Managers during the beta cycle<br />
| Action = If a status exists for Firefox N-1 and for Firefox N+1, guess a value for Firefox N <br />
| Example = 1500273<br />
| Source = missing_beta_status.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Increase priority of bugs tracked y Release Managers<br />
| Purpose = Priotitizes bugs needing an action for shipping quality software<br />
| Action = If a bug is tracked by a Release Manager, update the priority (P2 for nightly, P1 for the rest)<br />
| Example = 1515946,1508277,1512493<br />
| Source = mismatch_priority_tracking_release.py<br />
| Note = There are multiple files mismatch-priority-tracking-*.py, one per channel<br />
}}<br />
{{AutonagRule<br />
| Rule name = Add <code>regression</code> keywords to bugs (uses Machine Learning)<br />
| Purpose = Surface regressions not filed as such<br />
| Action = If a bug is tracked by a Release Manager, update the priority (P2 for nightly, P1 for the rest)<br />
| Example = 1529139<br />
| Source = regression.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Move untriaged bug into the correct component (uses machine learning) <br />
| Purpose = Decrease manual triage time<br />
| Action = Uses machine learning to mass move bugs in Firefox::Untriaged into a better component<br />
| Example = 1530316 <br />
| Source = component.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Copy crash signature from duplicate bugs to main bugs<br />
| Purpose = Crash bugs marked as duplicate of another one may have a different crash signature. We need to consolidate all signatures in the bug where a patch to fix them is being worked on, other wise we may not fix them all<br />
| Action = If a crash bug is marked as a duplicate, the signatures it referenced are added to the new bug<br />
| Example = 1517205<br />
| Source = copy_duplicate_info.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Increase severity of bugs tracked by Release Managers<br />
| Purpose = Fix inconsistency in metadata<br />
| Action = If a bug is tracked for an upcoming release but it's severity field is low, the severity is increased<br />
| Example = 1538966<br />
| Source = tracked_bad_severity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner to set priority on bugs<br />
| Purpose = Every defect should have a severity set. Also bugs with no severity set are harder to prioritize for Release Managers with regards to the release (see [https://firefox-source-docs.mozilla.org/bug-mgmt/policies/triage-bugzilla.html#what-do-you-triage what-do-you-triage])<br />
| Action = The triage owner is needinfoed in Bugzilla or nagged via email to set a priority on bugs<br />
| Example = 1527818<br />
| Source = workflow/no_severity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner on P1 bugs with no activity<br />
| Purpose = Since P1 means that the bug should be fixed for the next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), the bug needs to show any progress in its resolution (or maybe the priority should be decreased)<br />
| Action = The triage owner is nagged via email to have a reminder<br />
| Example = 1507251<br />
| Source = workflow/p1_no_activity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner to find an assignee for P1 bugs with no assignee and no activity<br />
| Purpose = Since P1 means that the bug should be fixed for the next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), the bug urgently needs to have an assignee (or the priority should be decreased)<br />
| Action = The triage owner is needinfoed in Bugzilla or nagged via email to find an assignee on bugs<br />
| Example = 1541291<br />
| Source = workflow/p1_no_assignee.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Change the priority from P2 to P1 on assigned bug the merge day<br />
| Purpose = Since P2 means that the bug should be fixed for the next next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), when we are the merge day then this bug automatically becomes a P1.<br />
| Action = Update the priority to P1 and add a comment to explain.<br />
| Example = <br />
| Source = workflow/p2_merge_day.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Patch not landed <br />
| Purpose = Identify bugs with an unlanded r+ patch. Maybe the patch is now obsolete or the bug needs to have a sheriff land the code with the <code>checkin-needed</code> keyword set.<br />
| Action = The bug assignee is needinfoed in Bugzilla to ask her/him to have look<br />
| Example = 1496844<br />
| Source = not_landed.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Regression without regressed_by and some bug dependencies <br />
| Purpose = Identify regressions which have dependencies (blocks or depends_on) and an empty regressed_by, probably people forgot to use the new field.<br />
| Action = The bug assignee or the person who added some dependencies or the reporter is needinfoed to ask to fill regressed_by when it's possible.<br />
| Example = 1545797<br />
| Source = regression_without_regressed_by.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Product::Component changed after the priority has been set <br />
| Purpose = Identify bugs where Product::Component changed after the priority has been set. The priority is probably no more up-to-date and so triage owner needs to set it.<br />
| Action = Reset the priority to "--" with a comment explaining why the bot is doing that.<br />
| Example = 1546366<br />
| Source = prod_comp_changed_with_priority.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Close intermittent test failure bugs <br />
| Purpose = Close intermittent test failure bugs which are P5s, not marked <code>leave-open</code>, and have not had a new failure in 21 days.<br />
| Action = RESOLVE bug as INCOMPLETE with a comment explaining why the bot is doing this.<br />
| Example = 1577895<br />
| Source = close_intermittents.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Ask for a beta uplift request <br />
| Purpose = Identify bugs where a patch fixed a bug in nightly and beta is marked as affected.<br />
| Action = Needinfo the assignee to ask it's worth making an uplift request.<br />
| Example = 1620434<br />
| Source = uplift_beta.py<br />
}}<br />
<br />
== Without autofix ==<br />
<br />
<br />
{{AutonagRule<br />
| Rule name = Feature vs regression<br />
| Purpose = Fix inconsistency in bugs with both the <code>regression</code> and <code>feature</code> keywords set <br />
| Source = feature_regression.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Inactive bugs with the <code>leave-open</code> keyword set<br />
| Purpose = Help identify dead/inactive bugs<br />
| Action = Needinfo the triage owner if a bug is inactive but has the <code>leave-open</code> keyword set<br />
| Example = 1367072<br />
| Source = leave_open_no_activity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Inactive Meta bugs<br />
| Purpose = Help identify dead/inactive bugs<br />
| Action = Needinfo the triage owner if a meta bug has no activity and no dependencies set <br />
| Source = meta_no_deps_no_activity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Low-severity bug but tracked by a release manager <br />
| Purpose = Idenitfy mismatch in metadata, a tracked bug should not have a priotity lower than ''normal''<br />
| Source = mismatch-priority-tracking.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Alert for lack of feedback in a bug<br />
| Purpose = Increase reaction time on bugs prioritized by upper management or release managers<br />
| Action = If a bug as an unanswered NeedInfo request from a release manager or a director, send a warning email<br />
| Source = ni_from_manager.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with no priority and no activity<br />
| Purpose = Triage owners need to process the backlog<br />
| Action = Needinfo the triage owner (only :Overholt for now)<br />
| Example = 1503461<br />
| Source = ni_triage_owner.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with only one or two words in the summary<br />
| Purpose = Make sure the bug is actually useful, a two-words summary often indicates a poor quality bug report<br />
| Example = 1512823<br />
| Source = one_two_word_summary.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remind developers about tracked bugs<br />
| Purpose = Make sure that bugs tracked for the next release are addressed<br />
| Source = query_creator.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Reporter not answering to Needinfo request<br />
| Purpose = identify bugs stalled because we need more information fron the reporter to reproduce it<br />
| Source = reporter_with_ni.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Top crashers vs ''normal'' severity<br />
| Purpose = Consistency and help getting traction on bugs<br />
| Example = 1471692<br />
| Source = topcrash_bad_severity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Identify tracked bugs with a NeedInfo request<br />
| Purpose = Make sure that bugs tracked for a release or nominated for tracking which also have a NeedInfo request do not get stuck<br />
| Action = Send an email<br />
| Source = tracked_needinfo.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Tracked bugs untouched for a week<br />
| Purpose = Identify important bugs for a release which are not being acted upon <br />
| Action = Send an email<br />
| Source = tracking.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Regressed in upcoming release<br />
| Purpose = Identify potential regression<br />
| Action = Send an email with the list of bugs marked as non affecting a release but affecting the next one<br />
| Source = unaffected_affected_no_reg.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Identify unlanded uplifts to Beta and ESR<br />
| Purpose = Make sure that we ship with the bugs that we need<br />
| Action = Send an email wih the list of bugs with uplift requests not landed on the affected branch<br />
| Example = 1509394<br />
| Source = unlanded.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with high severity in Firefox::Untriaged<br />
| Purpose = Identify potentially important issues left untriaged<br />
| Source = untriage_important_sev.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = <code>Version</code> set but not <code>status_firefox</code><br />
| Purpose = The <code>Version</code> value is set automatically by Bugzilla on landing a patch but not the <code>status_firefoxXX</code><br />
| Action = Send an email<br />
| Source = version_affected.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Check release dates on the Wiki<br />
| Purpose = Verify the consistency of our release dates on wiki.mozilla.org as we use them in automation <br />
| Action = Send an email<br />
| Source = ../next_release.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Information about bugs landed during Soft Code Freeze<br />
| Purpose = List fixed bug with patches which landed in mozilla-central during the soft freeze week. The listing includes patch statistics.<br />
| Action = Send an email<br />
| Source = code_freeze_week.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Hightlight Fixed bugs in nightly we may want to uplift<br />
| Purpose = Identify potentially upliftable bugs. <br />
| Action = Send an email with the recent fixes, the affected branches and metadata for prioritization<br />
| Source = missed_uplifts.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = New user with a Needinfo request<br />
| Purpose = Help identify potentially unactionnable bugs per lack of information<br />
| Action = Send an email<br />
| Source = newbie_with_ni.py<br />
}}<br />
[[category:Release_Management|Autonag]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BugBot&diff=1227150BugBot2020-05-14T00:52:34Z<p>Emceeaich: /* With autofix */ fix typo</p>
<hr />
<div>{{ DISPLAYTITLE:Autonag: Bugzilla triaging bot and alerting system }}<br />
<br />
<p style="font-size: larger; font-weight:bold;"><br />
This page lists all the actions done by the [https://github.com/mozilla/relman-auto-nag/ Autonag bot].</p><br />
<br />
= Introduction =<br />
Every day hundreds of tickets are opened in [https://bugzilla.mozilla.org Bugzilla] which track the tasks, defects and enhancements needed for the development of Firefox and other Mozilla projects. <br />
Triaging and priotirizing these bugs are an essential part of our development process and we automate part of this process so as to increase our development turn around and improve the quality of our bugs metadata. The set of scripts we use to improve the quality of our bugs, decrease our triaging time and help Release Management ship better quality software is called '''Autonag'''.<br />
<br />
Initially created as an alerting system (by email) to our triagers, Autonag rules now also make changes to our bugs metadata on Bugzilla so as to fix inconsistencies. <br />
<br />
Rules that change automatically some data in Bugzilla (change a priority, needinfo somebody, close a bug…) are called "Rules with Autofix" and those rules are applied once per hour. ''For now, security bugs aren't touched.''<br />
<br />
Rules that do not change data but have other results such as generate a report or send an email are called "Rules without Autofix". Rules without autofix are processed once a day (at 2PM CET).<br />
<br />
= Rules =<br />
== With autofix ==<br />
<br />
{{AutonagRule<br />
| Rule name = Bug assigned but marked as <code>UNCONFIRMED</code><br />
| Purpose = Mitigate an issue in Bugzilla (bugs reported by new users are not tagged as <code>NEW</code><br />
| Action = Change the status from <code>UNCONFIRMED</code> to <code>ASSIGNED</code> if there is an assignee<br />
| Example = 1495908<br />
| Source = assignee_but_unconfirmed.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Regression keyword is missing<br />
| Purpose = Regression keyword is important to differentiate an actual defect<br />
| Action = Sets the <code>regression</code> keyword on bugs with the <code>regression-range-wanted</code> keyword is set<br />
| Example = 1461034<br />
| Source = has_regression_range_no_keyword.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remove <code>leave-open</code> keyword on closed bug<br />
| Purpose = Clean up a mismatch in metadata<br />
| Action = If a bug is closed but the <code>leave-open</code> keyword is still set, remove it<br />
| Example = 1382185<br />
| Source = leave_open.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = [meta] in title but not in keywords<br />
| Purpose = Improve metedata quality<br />
| Action = Adds the <code>meta</code> keyword if the bug title starts by [META]<br />
| Example = 1435799 <br />
| Source = meta_summary_missing.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Update Firefox Status flags for bugs reopened during Nightly cycle<br />
| Purpose = Avoids potential issues for sheriffs and release managers<br />
| Action = Set <code>firefox-status</code> flag back from ''fixed'' to ''affected''<br />
| Example = 1495962<br />
| Source = nightly_reopened.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bug with no assignee but a patch landed<br />
| Purpose = Attribute unassigned bug to the developer that fixed it<br />
| Action = The ASSIGNEE field on the bug is changed from nobody@mozilla.org to the author of the patch that landed in mozilla-central<br />
| Example = 1514338<br />
| Source = no_assignee.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Close crash bugs with no crashes over 12 weeks<br />
| Purpose = Reduce the backlog of bugs to check for Release Managers <br />
| Action = Crash bugs without any crash reports for more than 12 weeks<br />
| Example = 1470864<br />
| Source = no_crashes.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remove <code>stalled</code> keyword on closed bugs<br />
| Purpose = Fix inconsistency between metadata and bug status<br />
| Action = If a bug is marked as <code>FIXED</code> and also has a <code>stalled</code> keyword set, the keyword is removed<br />
| Example = 1491624<br />
| Source = stalled.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Has meta keyword but not [meta] in the bug title<br />
| Purpose = Having [meta] in the bug title helps with quick search results<br />
| Action = If a bug has the meta keyword set, [meta] is added to the bug title<br />
| Example = 1257692<br />
| Source = summary_meta_missing.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Set a Firefox status flag for beta if there is one for nightly and release<br />
| Purpose = Fix inconsistency in Firefox status flags that can lead to a bug going undetected by Release Managers during the beta cycle<br />
| Action = If a status exists for Firefox N-1 and for Firefox N+1, guess a value for Firefox N <br />
| Example = 1500273<br />
| Source = missing_beta_status.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Increase priority of bugs tracked y Release Managers<br />
| Purpose = Priotitizes bugs needing an action for shipping quality software<br />
| Action = If a bug is tracked by a Release Manager, update the priority (P2 for nightly, P1 for the rest)<br />
| Example = 1515946,1508277,1512493<br />
| Source = mismatch_priority_tracking_release.py<br />
| Note = There are multiple files mismatch-priority-tracking-*.py, one per channel<br />
}}<br />
{{AutonagRule<br />
| Rule name = Add <code>regression</code> keywords to bugs (uses Machine Learning)<br />
| Purpose = Surface regressions not filed as such<br />
| Action = If a bug is tracked by a Release Manager, update the priority (P2 for nightly, P1 for the rest)<br />
| Example = 1529139<br />
| Source = regression.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Move untriaged bug into the correct component (uses machine learning) <br />
| Purpose = Decrease manual triage time<br />
| Action = Uses machine learning to mass move bugs in Firefox::Untriaged into a better component<br />
| Example = 1530316 <br />
| Source = component.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Copy crash signature from duplicate bugs to main bugs<br />
| Purpose = Crash bugs marked as duplicate of another one may have a different crash signature. We need to consolidate all signatures in the bug where a patch to fix them is being worked on, other wise we may not fix them all<br />
| Action = If a crash bug is marked as a duplicate, the signatures it referenced are added to the new bug<br />
| Example = 1517205<br />
| Source = copy_duplicate_info.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Increase severity of bugs tracked by Release Managers<br />
| Purpose = Fix inconsistency in metadata<br />
| Action = If a bug is tracked for an upcoming release but it's severity field is low, the severity is increased<br />
| Example = 1538966<br />
| Source = tracked_bad_severity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner to set priority on bugs<br />
| Purpose = Every defect should have a priority set. Also bugs with no priority set are harder to prioritize for Release Managers with regards to the release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage])<br />
| Action = The triage owner is needinfoed in Bugzilla or nagged via email to set a priority on bugs<br />
| Example = 1527818<br />
| Source = workflow/no_priority.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner on P1 bugs with no activity<br />
| Purpose = Since P1 means that the bug should be fixed for the next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), the bug needs to show any progress in its resolution (or maybe the priority should be decreased)<br />
| Action = The triage owner is nagged via email to have a reminder<br />
| Example = 1507251<br />
| Source = workflow/p1_no_activity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner to find an assignee for P1 bugs with no assignee and no activity<br />
| Purpose = Since P1 means that the bug should be fixed for the next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), the bug urgently needs to have an assignee (or the priority should be decreased)<br />
| Action = The triage owner is needinfoed in Bugzilla or nagged via email to find an assignee on bugs<br />
| Example = 1541291<br />
| Source = workflow/p1_no_assignee.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Change the priority from P2 to P1 on assigned bug the merge day<br />
| Purpose = Since P2 means that the bug should be fixed for the next next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), when we are the merge day then this bug automatically becomes a P1.<br />
| Action = Update the priority to P1 and add a comment to explain.<br />
| Example = <br />
| Source = workflow/p2_merge_day.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Patch not landed <br />
| Purpose = Identify bugs with an unlanded r+ patch. Maybe the patch is now obsolete or the bug needs to have a sheriff land the code with the <code>checkin-needed</code> keyword set.<br />
| Action = The bug assignee is needinfoed in Bugzilla to ask her/him to have look<br />
| Example = 1496844<br />
| Source = not_landed.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Regression without regressed_by and some bug dependencies <br />
| Purpose = Identify regressions which have dependencies (blocks or depends_on) and an empty regressed_by, probably people forgot to use the new field.<br />
| Action = The bug assignee or the person who added some dependencies or the reporter is needinfoed to ask to fill regressed_by when it's possible.<br />
| Example = 1545797<br />
| Source = regression_without_regressed_by.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Product::Component changed after the priority has been set <br />
| Purpose = Identify bugs where Product::Component changed after the priority has been set. The priority is probably no more up-to-date and so triage owner needs to set it.<br />
| Action = Reset the priority to "--" with a comment explaining why the bot is doing that.<br />
| Example = 1546366<br />
| Source = prod_comp_changed_with_priority.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Close intermittent test failure bugs <br />
| Purpose = Close intermittent test failure bugs which are P5s, not marked <code>leave-open</code>, and have not had a new failure in 21 days.<br />
| Action = RESOLVE bug as INCOMPLETE with a comment explaining why the bot is doing this.<br />
| Example = 1577895<br />
| Source = close_intermittents.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Ask for a beta uplift request <br />
| Purpose = Identify bugs where a patch fixed a bug in nightly and beta is marked as affected.<br />
| Action = Needinfo the assignee to ask it's worth making an uplift request.<br />
| Example = 1620434<br />
| Source = uplift_beta.py<br />
}}<br />
<br />
== Without autofix ==<br />
<br />
<br />
{{AutonagRule<br />
| Rule name = Feature vs regression<br />
| Purpose = Fix inconsistency in bugs with both the <code>regression</code> and <code>feature</code> keywords set <br />
| Source = feature_regression.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Inactive bugs with the <code>leave-open</code> keyword set<br />
| Purpose = Help identify dead/inactive bugs<br />
| Action = Needinfo the triage owner if a bug is inactive but has the <code>leave-open</code> keyword set<br />
| Example = 1367072<br />
| Source = leave_open_no_activity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Inactive Meta bugs<br />
| Purpose = Help identify dead/inactive bugs<br />
| Action = Needinfo the triage owner if a meta bug has no activity and no dependencies set <br />
| Source = meta_no_deps_no_activity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Low-severity bug but tracked by a release manager <br />
| Purpose = Idenitfy mismatch in metadata, a tracked bug should not have a priotity lower than ''normal''<br />
| Source = mismatch-priority-tracking.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Alert for lack of feedback in a bug<br />
| Purpose = Increase reaction time on bugs prioritized by upper management or release managers<br />
| Action = If a bug as an unanswered NeedInfo request from a release manager or a director, send a warning email<br />
| Source = ni_from_manager.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with no priority and no activity<br />
| Purpose = Triage owners need to process the backlog<br />
| Action = Needinfo the triage owner (only :Overholt for now)<br />
| Example = 1503461<br />
| Source = ni_triage_owner.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with only one or two words in the summary<br />
| Purpose = Make sure the bug is actually useful, a two-words summary often indicates a poor quality bug report<br />
| Example = 1512823<br />
| Source = one_two_word_summary.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remind developers about tracked bugs<br />
| Purpose = Make sure that bugs tracked for the next release are addressed<br />
| Source = query_creator.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Reporter not answering to Needinfo request<br />
| Purpose = identify bugs stalled because we need more information fron the reporter to reproduce it<br />
| Source = reporter_with_ni.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Top crashers vs ''normal'' severity<br />
| Purpose = Consistency and help getting traction on bugs<br />
| Example = 1471692<br />
| Source = topcrash_bad_severity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Identify tracked bugs with a NeedInfo request<br />
| Purpose = Make sure that bugs tracked for a release or nominated for tracking which also have a NeedInfo request do not get stuck<br />
| Action = Send an email<br />
| Source = tracked_needinfo.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Tracked bugs untouched for a week<br />
| Purpose = Identify important bugs for a release which are not being acted upon <br />
| Action = Send an email<br />
| Source = tracking.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Regressed in upcoming release<br />
| Purpose = Identify potential regression<br />
| Action = Send an email with the list of bugs marked as non affecting a release but affecting the next one<br />
| Source = unaffected_affected_no_reg.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Identify unlanded uplifts to Beta and ESR<br />
| Purpose = Make sure that we ship with the bugs that we need<br />
| Action = Send an email wih the list of bugs with uplift requests not landed on the affected branch<br />
| Example = 1509394<br />
| Source = unlanded.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with high severity in Firefox::Untriaged<br />
| Purpose = Identify potentially important issues left untriaged<br />
| Source = untriage_important_sev.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = <code>Version</code> set but not <code>status_firefox</code><br />
| Purpose = The <code>Version</code> value is set automatically by Bugzilla on landing a patch but not the <code>status_firefoxXX</code><br />
| Action = Send an email<br />
| Source = version_affected.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Check release dates on the Wiki<br />
| Purpose = Verify the consistency of our release dates on wiki.mozilla.org as we use them in automation <br />
| Action = Send an email<br />
| Source = ../next_release.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Information about bugs landed during Soft Code Freeze<br />
| Purpose = List fixed bug with patches which landed in mozilla-central during the soft freeze week. The listing includes patch statistics.<br />
| Action = Send an email<br />
| Source = code_freeze_week.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Hightlight Fixed bugs in nightly we may want to uplift<br />
| Purpose = Identify potentially upliftable bugs. <br />
| Action = Send an email with the recent fixes, the affected branches and metadata for prioritization<br />
| Source = missed_uplifts.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = New user with a Needinfo request<br />
| Purpose = Help identify potentially unactionnable bugs per lack of information<br />
| Action = Send an email<br />
| Source = newbie_with_ni.py<br />
}}<br />
[[category:Release_Management|Autonag]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide/BugStatuses&diff=1227149BMO/UserGuide/BugStatuses2020-05-14T00:47:50Z<p>Emceeaich: /* Resolutions */ Make 'must' be 'should' instead because see also field may not recognize all bug tracker URLs</p>
<hr />
<div>= Bug Statuses =<br />
<br />
; STATUS<br />
: The Status field indicates the current state of a bug. Only certain status transitions are allowed.<br />
; RESOLUTION<br />
: The Resolution field indicates what happened to this bug.<br />
<br />
== Open Bugs ==<br />
<br />
=== Statuses ===<br />
<br />
; UNCONFIRMED<br />
: This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the "canconfirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED. <br />
; NEW<br />
: This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED. <br />
; ASSIGNED<br />
: This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED. <br />
; REOPENED<br />
: This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED. <br />
<br />
== Closed Bugs == <br />
<br />
=== Statuses ===<br />
<br />
; RESOLVED<br />
: A resolution has been performed, and it is awaiting verification by QA. From here bugs are either reopened and given some open status, or are verified by QA and marked VERIFIED. <br />
; VERIFIED<br />
: QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED. <br />
<br />
=== Resolutions ===<br />
<br />
; FIXED<br />
: A fix for this bug is checked into the tree and tested. <br />
; INVALID<br />
: The problem described is not a bug. <br />
; WONTFIX<br />
: The problem described is a bug which will never be fixed. <br />
; MOVED<br />
: The problem is now being worked on another issue tracker. The [https://wiki.mozilla.org/BMO/UserGuide/BugFields#see_also See Also field] should contain the URL of the bug on the other tracker.<br />
; DUPLICATE<br />
: The problem is a duplicate of an existing bug (the problems must be exactly the same). Marking a bug duplicate requires the bug# of the duplicating bug and will at least put that bug number in the description field. If a bug has the same root cause as another one but the two bugs are finally different, then they should have a dependency such as [https://wiki.mozilla.org/BMO/UserGuide/BugFields#dependson depends_on].<br />
; WORKSFORME<br />
: a) all attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur; or<br />
: b) the bug was present once, but is now not reproducible (and so was probably fixed in another bug.)<br />
; INCOMPLETE<br />
: The problem is vaguely described with no steps to reproduce, or is a support request. The reporter should be directed to the product's support page for help diagnosing the issue. If there are only a few comments in the bug, it may be reopened only if the original reporter provides more info, or confirms someone else's steps to reproduce. If the bug is long, when enough info is provided a new bug should be filed and the original bug marked as a duplicate of it.</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide/BugStatuses&diff=1227148BMO/UserGuide/BugStatuses2020-05-14T00:46:38Z<p>Emceeaich: /* Resolutions */ update WORKSFORME https://bugzilla.mozilla.org/show_bug.cgi?id=1637674</p>
<hr />
<div>= Bug Statuses =<br />
<br />
; STATUS<br />
: The Status field indicates the current state of a bug. Only certain status transitions are allowed.<br />
; RESOLUTION<br />
: The Resolution field indicates what happened to this bug.<br />
<br />
== Open Bugs ==<br />
<br />
=== Statuses ===<br />
<br />
; UNCONFIRMED<br />
: This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the "canconfirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED. <br />
; NEW<br />
: This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED. <br />
; ASSIGNED<br />
: This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED. <br />
; REOPENED<br />
: This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED. <br />
<br />
== Closed Bugs == <br />
<br />
=== Statuses ===<br />
<br />
; RESOLVED<br />
: A resolution has been performed, and it is awaiting verification by QA. From here bugs are either reopened and given some open status, or are verified by QA and marked VERIFIED. <br />
; VERIFIED<br />
: QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED. <br />
<br />
=== Resolutions ===<br />
<br />
; FIXED<br />
: A fix for this bug is checked into the tree and tested. <br />
; INVALID<br />
: The problem described is not a bug. <br />
; WONTFIX<br />
: The problem described is a bug which will never be fixed. <br />
; MOVED<br />
: The problem is now being worked on another issue tracker. The [https://wiki.mozilla.org/BMO/UserGuide/BugFields#see_also See Also field] must contain the URL of the bug on the other tracker.<br />
; DUPLICATE<br />
: The problem is a duplicate of an existing bug (the problems must be exactly the same). Marking a bug duplicate requires the bug# of the duplicating bug and will at least put that bug number in the description field. If a bug has the same root cause as another one but the two bugs are finally different, then they should have a dependency such as [https://wiki.mozilla.org/BMO/UserGuide/BugFields#dependson depends_on].<br />
; WORKSFORME<br />
: a) all attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur; or<br />
: b) the bug was present once, but is now not reproducible (and so was probably fixed in another bug.)<br />
; INCOMPLETE<br />
: The problem is vaguely described with no steps to reproduce, or is a support request. The reporter should be directed to the product's support page for help diagnosing the issue. If there are only a few comments in the bug, it may be reopened only if the original reporter provides more info, or confirms someone else's steps to reproduce. If the bug is long, when enough info is provided a new bug should be filed and the original bug marked as a duplicate of it.</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide/BugFields&diff=1226746BMO/UserGuide/BugFields2020-05-03T19:52:45Z<p>Emceeaich: /* Bugzilla Field Descriptions */ update severity values and definitions</p>
<hr />
<div>== Bugzilla Field Descriptions ==<br />
<br />
{{anchor|alias}}<br />
; Alias<br />
: A short, unique name assigned to a bug in order to assist with looking it up and referring to it in other places in Bugzilla.<br />
{{anchor|assigned_to}}<br />
; Assignee<br />
: This is the person in charge of resolving the bug. Every time this field changes, the status changes to NEW to make it easy to see which new bugs have appeared on a person's list.<br />
{{anchor|blocks}}<br />
; Blocks<br />
: This bug must be resolved before the bugs listed in this field can be resolved.<br />
{{anchor|bug_id}}<br />
; Bug ID<br />
: The numeric id of a bug, unique within this entire installation of Bugzilla.<br />
{{anchor|cc}}<br />
; CC<br />
: Users who may not have a direct role to play on this bug, but who are interested in its progress.<br />
{{anchor|delta_ts}}<br />
; Changed<br />
: When this bug was last updated.<br />
{{anchor|classification}}<br />
; Classification<br />
: Bugs are categorised into Classifications, Products and Components. classifications is the top-level categorization.<br />
{{anchor|comment}}<br />
; Comment<br />
: Bugs have comments added to them by Bugzilla users. You can search for some text in those comments.<br />
{{anchor|comment_tag}}<br />
; Comment Tag<br />
: Comments can have arbitrary tags added to them to help with filtering as well as mark comments as spam or abusive. <br />
{{anchor|component}}<br />
; Component<br />
: Components are second-level categories; each belongs to a particular Product. Select a Product to narrow down this list.<br />
{{anchor|creation_ts}}<br />
; Creation date<br />
: When the bug was filed.<br />
{{anchor|dependson}}<br />
; Depends on<br />
: The bugs listed here must be resolved before this bug can be resolved.<br />
{{anchor|duplicates}}<br />
; Duplicates<br />
: List of bugs that have been marked a duplicate of the bug currently being viewed.<br />
{{anchor|rep_platform}}<br />
; Hardware<br />
: This is the hardware platform against which the bug was reported.<br />
{{anchor|importance}}<br />
; Importance<br />
: The importance of a bug is described as the combination of its Priority and Severity.<br />
{{anchor|keywords}}<br />
; Keywords<br />
: Keywords are a controlled vocabulary for characterizing bugs across Products and Components. Examples of this field are <code>regression</code>, <code>sec-high</code>, and <code>topcrash</code>. Bugzilla administrators manage [https://bugzilla.mozilla.org/describekeywords.cgi the list of keywords]. If you believe you need a new keyword, [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration please contact the administrators to discuss]. <br />
{{anchor|bug_mentor}}<br />
; Mentors<br />
: Mentors are users who have offered to help the bug owner with such tasks as setting up a development environment, finding relevant information to fixing the bug, how to submit a patch for review, and finally how to get the fix committed.<br />
{{anchor|needinfo}}<br />
; Needinfo<br />
: More information has been requested from specific individuals, or anyone, to move the bug forward to completion.<br />
{{anchor|op_sys}}<br />
; OS<br />
: This is the operating system against which the bug was reported.=<br />
{{anchor|priority}}<br />
; Priority<br />
: This field describes the importance and order in which a bug should be fixed compared to other bugs. This field is utilized by the programmers/engineers/release managers/managers to prioritize the work to be done. See [https://mozilla.github.io/bug-handling/triage-bugzilla the Firefox triage documentation] or for the main Bugzilla project, [[Bugzilla:Priority_System]].<br />
{{anchor|product}}<br />
; Product<br />
: Bugs are categorised into Products and Components. Select a Classification to narrow down this list.<br />
{{anchor|qa_contact}}<br />
; QA Contact<br />
: The person responsible for confirming this bug if it is unconfirmed, and for verifying the fix once the bug has been resolved.<br />
{{anchor|rank}}<br />
; Rank<br />
: Used by some groups to provide finer-grained ordering for working on bugs than afforded by the Priority field. Use of this field is restricted to the `rank-setters` group.<br />
{{anchor|regressed_by}}<br />
; Regressed by<br />
: This bug has been introduced by the bugs listed here.<br />
{{anchor|regresses}}<br />
; Regressions<br />
: This bug has introduced the bugs listed here.<br />
{{anchor|reporter}}<br />
; Reporter<br />
: The person who filed this bug.<br />
{{anchor|see_also}}<br />
; See Also<br />
: This allows you to refer to bugs in other bug tracker installations. You can enter a URL to a bug in the 'Add Bug URLs' field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma. You should normally use this field to refer to bugs in other bug tracker installations, or bugs which are related to, but not known to be duplicates of the bug. Bugs which are regressions should be listed in the Regressed by field (above)<br />
{{anchor|bug_severity}}<br />
; Severity<br />
: This field describes the impact of a bug.<br />
{| class="wikitable"<br />
|'''--'''<br />
|Default value for new bugs; bug triagers for components are expected to update the bug's severity from this value<br />
|- <br />
|'''S1'''<br />
|(Catastrophic) Blocks development/testing, may impact more than 25% of users, causes data loss, potential chemspill, and no workaround available<br />
|-<br />
|'''S2'''<br />
|(Serious) Major functionality/product severely impaired and a satisfactory workaround does not exist<br />
|-<br />
|'''S3'''<br />
|(Normal) Blocks non-critical functionality and a work around exists<br />
|-<br />
|'''S4'''<br />
|(Small/Trivial) minor significance, cosmetic issues, low or no impact to users<br />
|-<br />
|'''N/A'''<br />
|(Not Applicable) The above definitions do not apply to this bug; this value is reserved for bugs of type Task or Enhancement<br />
|} <br />
{{anchor|short_desc}}<br />
; Summary<br />
: The bug summary is a short sentence which succinctly describes what the bug is about.<br />
{{anchor|target_milestone}}<br />
; Target Milestone<br />
: For Firefox-related bugs, when a change set (patch) lands in Mozilla-Central, the [[Sheriffing|sheriffs]] will set this field to the corresponding release value for the current Nightly.<br />
: Release status and tracking flags are used to mark intentions for when a fix or other patch should land. <br />
: If you need to track a bug against a set of milestones other than upcoming versions of Firefox, please tell the Bugzilla team, you may want a custom status flag. <br />
{{anchor|triage_owner}}<br />
; Triage Owner<br />
: User that is responsible [https://mozilla.github.io/bug-handling/triage-bugzilla for triaging bugs in a specific component].<br />
{{anchor|bug_type}}<br />
; Type<br />
: This field describes the [https://mozilla.github.io/bug-handling/bug-types type of a bug].<br />
{| class="wikitable"<br />
|-<br />
|'''defect'''<br />
|regression, crash, hang, security vulnerability and any other general issue.<br />
|-<br />
|'''enhancement'''<br />
|new feature, improvement in UI, performance, etc. and any other request for user-facing changes and enhancements in the product; not engineering changes<br />
|-<br />
|'''task'''<br />
|refactoring, removal, replacement, enabling or disabling of functionality and any other engineering task<br />
|} <br />
{{anchor|bug_file_loc}}<br />
; URL<br />
: Bugs can have a URL associated with them - for example, a pointer to a web site where the problem is seen.<br />
{{anchor|version}}<br />
; Version<br />
: The version field defines the version of the software the bug was found in.<br />
{{anchor|votes}}<br />
; Votes<br />
: Some bugs can be voted for, and you can limit your search to bugs with more than a certain number of votes. Votes are not used by Mozilla developers to set priorities.<br />
{{anchor|status_whiteboard}}<br />
; Whiteboard<br />
: Each bug has a free-form single line text entry box for adding tags and status information</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2020-04-06&diff=1225947WeeklyUpdates/2020-04-062020-04-06T17:37:39Z<p>Emceeaich: /* Friends of Mozilla Friends of Mozilla */ add bmo contributions</p>
<hr />
<div><br />
{{WeeklyUpdateNav}}<br />
* Every Monday @ 11:00am Pacific Time (19:00 UTC) <br />
* Watch at http://mzl.la/project-meeting-2020-04-06 or anonymously at https://air.mozilla.org. Watch live in the Hubs 3D space (in browser) at https://hubs.mozilla.com/1rNht23/hubs-commons/. You can also watch on the Mozilla YouTube channel at https://www.youtube.com/watch?v=u2NWbn8riTs.<br />
* join #project-call on irc.mozilla.org or Slack for backchannel discussion<br />
* If you plan on presenting, please join the Zoom video chat 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.<br />
* '''Presenters only:''' Zoom Meeting ID: 828 817 988 [https://mozilla.zoom.us/j/828817988 https://mozilla.zoom.us/j/828817988.] Do '''not''' use this room if you're not planning to speak. <br />
* One-tap mobile<br />
** +16465588656,,828817988# US (New York)<br />
** +17207072699,,828817988# US<br />
* Dial-in by your location<br />
** +1 646 558 8656 US (New York)<br />
** +1 720 707 2699 US<br />
** 877 853 5257 US Toll-free<br />
** +61 2 8015 2088 Australia<br />
** +61 8 7150 1149 Australia<br />
** 1800 893 423 Australia Toll-free<br />
** +1 647 558 0588 Canada<br />
** +33 1 8288 0188 France<br />
** +33 7 5678 4048 France<br />
** 0 805 082 588 France Toll-free<br />
** +49 30 5679 5800 Germany<br />
** +49 69 8088 3899 Germany<br />
** +49 30 3080 6188 Germany<br />
** 800 724 3138 Germany Toll-free<br />
** +852 5808 6088 Hong Kong, China<br />
** +44 203 695 0088 United Kingdom<br />
** +44 203 966 3809 United Kingdom<br />
** +44 203 051 2874 United Kingdom<br />
** 0 800 031 5717 United Kingdom Toll-free<br />
<br />
__TOC__<br />
<br />
= Weekly Project Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live status meeting.<br />
<br />
== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==<br />
* Huge thanks to Outreachy contributors Alaa Emad, Mahak Bansal, Anjali Jha, undef1nd and Sonakshi Saxena for fixing dozens of Networking bugs in the past few weeks.<br />
* Thanks to Outreachy contributors Manya Agarwal, and Lisset Cuevas for their fixes for Bugzilla.<br />
* Thank you to the [https://blog.mozilla.org/community/2020/04/06/firefox-75-new-contributors/ 40 people] who contributed their first code change to Firefox for the upcoming Firefox 75 release.<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===<br />
<br />
=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
=== Later Events and Available Tickets ===<br />
<br />
<big>'''Below is a list of events Mozilla is supporting (with their start dates), with current status updates. Some are being postponed, some cancelled and some undecided at present. The DevRel Team will continue to update as the situation changes. For more details about each event please visit our '''[https://developer.mozilla.com/events/ Developer Portal]'''<br />
<br />
'''</big><br />
<br />
Current list of Mozilla sponsored developer events around the globe (DevRel Events team will update) -<br />
<br />
<br />
JS Kongress Munich | 04/15-16/20 | Munich, Germany ''POSTPONED''<br />
<br />
Mozilla x Bit Web of Things Workshop | 04/23/20 | Davis, CA ''POSTPONED''<br />
<br />
beyond tellerrand // DÜSSELDORF | 04/27-29/20 | Dusseldorf ''POSTPONED''<br />
<br />
Write the Docs, Portland 2020 | 05/03-05/20 | Portland, US ''POSTPONED''<br />
<br />
200 OK | 5/15/20 | Tulsa, OK, USA ''CANCELLED''<br />
<br />
Tech Interior 2020 | 05/23/20| Jaboticabal, São Paulo, Brazil<br />
<br />
Rustfest, Utrecht | 06/06-07/20 | Utrecht, The Netherlands ''POSTPONED''<br />
<br />
Smashing Conference, Austin 2020 | 06/9-10/20 | Austin<br />
<br />
CSS Day | 06/11-12/20 | Amsterdam, Netherlands ''CANCELLED''<br />
<br />
[https://2020.indieweb.org/summit ⛰ IndieWeb Summit 2020] | 06/27/20 - 06/28/20 | Portland, Oregon, USA ''ON HOLD UNTIL POSTPONEMENT FIGURED OUT''<br />
<br />
Halfstack | 07/03/20 | Newquay, UK<br />
<br />
Game Devs of Color Expo | 07/10-11/20 | New York, US<br />
<br />
REFACTR.TECH 2020 | 08/12-14/20 | Atlanta<br />
<br />
Halfstack | 08/14/20 | New York, US<br />
<br />
Smashing Conference, Freiburg 2020 | 09/7-8/20 | Freiburg, Germany<br />
<br />
beyond tellerrand // BERLIN | 09/7-10/20 | Berlin<br />
<br />
Halfstack | 09/18/20 | Vienna, Austria<br />
<br />
Halfstack | 10/19/20 | Tel Aviv, Israel<br />
<br />
Smashing Conference, New York 2020 | 10/20-21/20 | Freiburg, Germany<br />
<br />
beyond tellerrand // MUNICH | 11/2-4/20 | Munich<br />
<br />
Smashing Conference, San Francisco 2020 | 11/10-11/20 | San Francisco<br />
<br />
Halfstack | 11/20/20 | London, UK<br />
<br />
Halfstack | 12/11/20 | Charlotte, US<br />
<br />
<br />
'''Mozilla DevRel Complimentary Tickets'''<br />
<br />
Current list of Mozilla sponsored developer events (with their start dates) around the globe (DevRel Events team will update):<br />
<br />
Our DevRel Sponsorship team sometimes receives complimentary tickets to share with Mozillians interested in attending the following events. Please fill out this form [https://airtable.com/shrRFuIEm7j2a0Gtu Ticket RequestForm ]. <br />
If you have questions, reach out to the DevSponsorship Team at devsponsorship@mozilla.com for more details. <br />
<br />
<br />
'''[https://beyondtellerrand.com/events/dusseldorf-2020/ beyond tellerrand // DÜSSELDORF]''' Dusseldorf | ''POSTPONED''<br />
<br />
'''[https://www.writethedocs.org/conf/portland/2020/ Write the Docs, Portland]''' Portland | 2020-05 03-05 - ''POSTPONED''<br />
<br />
'''[https://smashingconf.com/austin-2020/ Smashing Conference, Austin]''' Austin | 2020-06-09<br />
<br />
'''[https://www.writethedocs.org/conf/portland/2020/ Write the Docs, Prague]''' Prague | 2020-08 9-11<br />
<br />
'''[https://refactr.tech/index.html/ REFACTR.TECH 2020]''' Atlanta, GA | 2020-08 12-14<br />
<br />
'''[https://beyondtellerrand.com/events/berlin-2020/ beyond tellerrand // BERLIN]''' Berlin | 2020-09-07<br />
<br />
'''[https://smashingconf.com/freiburg-2020/ Smashing Conference, Freiburg]''' Freiburg | 2020-09-07<br />
<br />
'''[https://www.writethedocs.org/conf/prague/2020/ Write the Docs, Prague]''' Prague | 2020-09 15-17<br />
<br />
'''[https://smashingconf.com/ny-2020/ Smashing Conference, New York]''' New York | 2020-10-20<br />
<br />
'''[https://beyondtellerrand.com/events/munich-2020/ beyond tellerrand // MUNICH]''' Munich | 2020-11-02<br />
<br />
'''[https://smashingconf.com/sf-2020/ Smashing Conference, San Francisco]''' San Francisco | 2020-11 10-11<br />
<br />
== Speakers ==<br />
<br />
The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! [https://mozillians.org/u/USERNAME Presenter]<br />
! Title<br />
! Topic<br />
! Location<br />
! Sharing<br />
! Media<br />
! More Details<br />
|-<br />
| Who Are You?<br />
| What Do You Do?<br />
| What are you going to talk about?<br />
| Where are you presenting from? (Moz Space, your house, space)<br />
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
| Nathan Egge<br />
| Senior Research Engineering Manager<br />
| Emerging Technologies update<br />
| Remote (Virginia)<br />
| no<br />
| n/a<br />
| [https://wiki.mozilla.org/WeeklyUpdates/EmergingTechnology#April_6th.2C_2020 ET headlines]<br />
|-<br />
| Jared Wein<br />
| Team Firefox<br />
| Firefox Weekly Update<br />
| remote (Michigan)<br />
| no<br />
| n/a<br />
| [https://wiki.mozilla.org/Firefox/Roadmap/Updates#2020-04-06 2020-04-06]<br />
|-<br />
| Andy Kochendorfer<br />
| Streaming Solutions Architect <br />
| Weekly MinIT <br />
| Remote<br />
| no<br />
| n/a <br />
| <br />
|-<br />
|}<br />
<br />
= Welcome! =<br />
<br />
Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! ''Who is being introduced?''<br />
! ''Who are you? (the introducer)''<br />
! ''Where are you doing the introduction?''<br />
! ''Where are they from?''<br />
! ''How will they be part of Mozilla?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| Their Name<br />
| Your Name<br />
| Intro location<br />
| Their Location<br />
| Their Role<br />
|-<br />
| Carolin Rother<br />
| Porfirio Landeros<br />
| SFO/Remote ([https://drive.google.com/open?id=1YdtOg2g3H2XssEi4eBz4nFOiC5L74Mq4 Video Link])<br />
| Berlin/Remote<br />
| Sr. Product Marketing Manager, Firefox/EU<br />
|-<br />
|}<br />
<br />
<br />
[[Category:Weekly Updates]]<br />
[[Category:Meeting Notes]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO&diff=1223927BMO2020-02-18T22:39:12Z<p>Emceeaich: /* Current Projects */ update descriptions</p>
<hr />
<div>This is the main public page for all things related to https://bugzilla.mozilla.org, aka BMO, Mozilla's customized version of [http://www.bugzilla.org Bugzilla]. <br />
<br />
BMO is a core piece of infrastructure at Mozilla. It is used to track not only bugs and feature requests but also many other tasks across various teams.<br />
<br />
The BMO source is a slightly modified fork of Bugzilla with many custom extensions. It is currently based on Bugzilla 4.2 but with many features backported from 4.4 and master. All the BMO devs are also involved in the Bugzilla project, and we contribute features and fixes upstream where they are generally applicable, that is, not too specific to Mozilla's particular needs.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent_Changes|Recent Changes]] page.<br />
<br />
= B-Team =<br />
<br />
The team that works on BMO is called the B-Team, because of past affiliation with the defunct Automation and Tools team (A-Team).<br />
<br />
* dkl: Dave Lawrence (Owner/Engineer)<br />
* emceeaich: Emma Humphries, (Bugmaster)<br />
* kmoir: Kim Moir, (Manager)<br />
<br />
The Low-level, security, and quality tools team contributes tooling, and development:<br />
<br />
* calixte: Calixte Denizet, (AutoNag)<br />
* marco: Marco Castelluccio, (BugBug)<br />
<br />
We also also have some volunteers, that we consider to be part of the B-Team as well:<br />
<br />
* seban: Sebastin Santy (long-term volunteer, past GSoC student)<br />
* atoll: Richard Solderberg (Reviewer-at-Large, slightly borrowed from Mozilla IT)<br />
* kohei: Kohei Yoshino, (UX Designer)<br />
* ''... and you can be one too!''<br />
<br />
There are also some people that still have some involvement with BMO,<br />
but their day-to-day attention is directed to other parts of Mozilla.<br />
<br />
* glob: Byron Jones<br />
* zeid: Zeid Zabaneh (Engineer)<br />
* mhentges: Mitchell Hentges (Engineer)<br />
<br />
Past contributors include:<br />
* mary: Mary Umoh (Intern, Summer 2017)<br />
* gerv: Gervase Markham<br />
* mcote: Mark C&ocirc;t&eacute;<br />
* dylan: Dylan Hardison<br />
* imadueme: Israel Madueme (Engineer)<br />
* justdave: Dave Miller<br />
<br />
= New Users =<br />
<br />
Getting used to Bugzilla can be a bit daunting. We have a short [https://gerv.makes.org/popcorn/1bn6 introductory video] available that is as gentle as possible. You may also be interested in the [[https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla MDN section about Bugzilla]], which contains information more suitable as an introduction to a general audience. Of special interest is the MDN article, [https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla What to do and what not to do in Bugzilla], which contains instructions on getting elevated privileges.<br />
<br />
= New Bots =<br />
<br />
If you have a bot that uses BMO, be sure to add it to the [[BMO/Bot Registry]]<br />
so we know who to contact about it!<br />
<br />
= User Guide =<br />
<br />
We're putting together a [[BMO/UserGuide|user guide]] with helpful information on various aspects of Bugzilla. New and experienced users alike should benefit from it. There's a lot to go through, so please feel free to contribute!<br />
<br />
= Road Map =<br />
<br />
We keep a yearly [[BMO/Road Map|road map]] with our medium-term plans (1-2 years), at a high level. Also see our [[BMO#Current_Projects|current projects]] for some of the big items we are working on in the current quarter.<br />
<br />
= Browser Support For BMO =<br />
<br />
Full Support includes: The current versions of Firefox, Chrome, Chromium, Safari, WebKit, and Edge; and the latest Firefox ESR.<br />
<br />
Limited Support includes: The previous versions of Firefox, Chrome, Chromium, Safari, WebKit, Edge, and Firefox ESR; and Firefox Nightly.<br />
<br />
Internet Explorer is no longer supported, though some features may still work with IE 11.<br />
<br />
See {{bug|1359310}} and {{bug|1422435}}.<br />
<br />
== JavaScript and Analytics ==<br />
<br />
JavaScript is required to use bugzilla.mozilla.org. <br />
<br />
The <code>Do Not Track</code> header sent by your browser is honored.<br />
<br />
= Third-Party Applications =<br />
<br />
Lots and lots of web apps and general tools have been written to interface with BMO. We have started [[BMO/ThirdPartyApps|cataloguing them]]. If you're looking for different ways to interface with BMO, check it out; similarly, if you are thinking about writing an app, check the catalogue to see if something similar exists that you could use, contribute to, or fork before setting out on your own.<br />
<br />
There's one in particular that is particularly important: [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Phabricator], Mozilla's new and growing code-review tool.<br />
<br />
= More Information about BMO =<br />
<br />
Our discussion forum is mozilla.tools.bmo [[https://lists.mozilla.org/listinfo/tools-bmo mailing list]] [[https://groups.google.com/forum/#!forum/mozilla.tools.bmo Google Group]] [[news://news.mozilla.org:119/mozilla.tools.bmo USENET]].<br />
<br />
We also have answers to [[BMO/FAQ|Frequently Asked Questions]] and a slightly-but-not-too-out-of-date [http://people.mozilla.org/~justdave/BugzillaPhysicalDiagram-rev110504.png hardware diagram].<br />
<br />
If you're building an application or tool that interfaces with BMO, you may be interested in the following:<br />
<br />
* [[BMO/Integration_Best_Practice|Best practices and etiquette]] for integrating external apps with BMO<br />
* Info and plans on Bugzilla's [[Bugzilla:REST_API|REST API]], and the older, deprecated [[Bugzilla:BzAPI|BzAPI]].<br />
<br />
Looking for another way to access Bugzilla's raw data? Try the [[BMO/ElasticSearch|ElasticSearch cluster]].<br />
<br />
= Contributing to BMO =<br />
<br />
If you'd like to help out with BMO specifically (as opposed to the general upstream [[Bugzilla|Bugzilla project]]), you can find us in [irc://irc.mozilla.org/bmo #bmo] on irc.mozilla.org. If you plan on contributing patches, see the documentation in the [https://github.com/mozilla-bteam/bmo/blob/master/README.rst README.rst]. You can file bugs under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org bugzilla.mozilla.org product]. Don't file them under the Bugzilla product unless you are sure it's a bug in the general Bugzilla product. In particular, all administrative changes should be filed under bugzilla.mozilla.org (see below for more).<br />
<br />
= Policies and Procedures =<br />
<br />
<br />
== Code Updates ==<br />
<br />
Code updates are normally deployed to bugzilla.mozilla.org late Monday/early Tuesday, US/Pacific time, at no specific time, if changes need to be pushed out. Security fixes or other fatal type errors will always go out as soon as possible.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent Changes]] page. <br />
<br />
== Administrative Changes ==<br />
<br />
If you need changes to BMO's configuration to support your team, project, etc., please consult this page before filing bugs:<br />
<br />
* [[BMO/Requesting Changes|General information on requesting Changes to BMO]]<br />
<br />
== BMO Administrative Processes ==<br />
<br />
* [[BMO/new-product|Adding a new product]]<br />
* [[BMO/new-version|Adding a new "rapid release" version]]<br />
* [[BMO/new-security-group|Adding a new BMO security group]]<br />
* [[BMO/RetiringComponents|Retiring Products and Components]]: moving things to the Graveyard classification.<br />
* [[BMO/RestoringDisabledAccounts|Restoring Disabled Accounts]]<br />
* [[BMO/MergingAccounts|Merging Accounts]]<br />
* [[BMO/DisablingAccounts|Disabling Accounts]]<br />
<br />
See also [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=45845955 BMO on Mana] (requires LDAP).<br />
<br />
== BMO Development and Other Processes ==<br />
<br />
* [[BMO/Development Processes|Overall Development Processes]]<br />
<br />
* [[BMO/OutagePlanning|Planning a BMO outage]]<br />
* [[BMO/ResetDevelopmentBranch|Reset the development branch to master]]<br />
* [[BMO/Perl Dependencies|Maintaining Perl Dependencies for BMO]]<br />
<br />
== Custom Bug Entry Forms ==<br />
<br />
In the past, BMO developers supported writing custom bug entry forms specific for the needs of different projects and groups within Mozilla. In order to focus more on other important features, we will no longer be providing that support going forward. For more information on why this change was made, see [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/tp4dSwUfKSA here].<br />
<br />
There is a new [https://github.com/mozilla-bteam/custom-form-example custom form framework] being developed by an outside contributor named Sebastin Santy. It is still in the early stages but it eventually will be very useful for users who want to create a customized bug entry form that can be used to submit bugs to BMO.<br />
<br />
= Current Projects =<br />
<br />
This table lists the bugs representing the current quarterly goals (and, near the end of the quarter, sometimes next quarter's goals). Those that were set at the beginning of the quarter are tagged with the keyword "bmo-goal". The BMO team also regularly gets requests for high-priority work items throughout the quarter; some of which will take more than a day or two in total, thus potentially jeopardizing other goals. The other daily tasks are also generally tracked in Bugzilla but not represented in the table below.<br />
<br />
P1 indicates a critical project. P2 indicates an important but deferrable item. P3 is as P2 but more deferrable. Note that all items are important, and it is presumed that lower-priority items will increase in priority over time as high-priority tasks are completed, i.e., we don't plan to defer any of these tasks indefinitely.<br />
<br />
== Goals ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-goal",<br />
"keywords_type": "anywords",<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2018-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== High-Priority ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"product": "bugzilla.mozilla.org",<br />
"keywords": "bmo-on-deck, bmo-goal",<br />
"keywords_type": "nowords",<br />
"priority": ["P1"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"status": ["ASSIGNED"],<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== Upcoming ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck",<br />
"keywords_type": "anywords",<br />
"priority": ["--","P1","P2","P3","P4","P5"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
Further documentation about goals above and other projects follows:<br />
<br />
* [[BMO/UserRoles|User Roles]]<br />
** Generate different user roles based on what tasks a user is trying to complete when using the BMO system.<br />
<br />
== Past Projects ==<br />
<br />
Some of these will have on-going maintenance and improvements, but the initial deployment has been accomplished. Others have been abandoned or rejected due to various factors, noted below.<br />
<br />
* [[BMO/ChangeNotificationSystem|Change Notification System]]<br />
* [[BMO/40Upgrade|4.0 Upgrade]]<br />
* [[BMO/42Upgrade|4.2 Upgrade]] (Completed March 5th, 2013)<br />
* [[BMO/UserProfiles|User Profiles]]<br />
* [[BMO/TrackingFlags|Tracking Flags]]<br />
* [[Bugzilla:REST_API|Native REST API]]<br />
* [[BMO/Pulse|Pulse Integration]]<br />
** This was completed and deployed, but it generated a lot of traffic and is of questionable utility since it must access Bugzilla as an anonymous user. A simpler, more general system is the [[BMO/ChangeNotificationSystem|Change Notification System]].<br />
* [[Bugzilla:Migrating_to_git|Migrating Bugzilla and BMO code from bzr to git]]<br />
** Completed 2014/03/11.<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO&diff=1223926BMO2020-02-18T22:37:24Z<p>Emceeaich: /* High-Priority */</p>
<hr />
<div>This is the main public page for all things related to https://bugzilla.mozilla.org, aka BMO, Mozilla's customized version of [http://www.bugzilla.org Bugzilla]. <br />
<br />
BMO is a core piece of infrastructure at Mozilla. It is used to track not only bugs and feature requests but also many other tasks across various teams.<br />
<br />
The BMO source is a slightly modified fork of Bugzilla with many custom extensions. It is currently based on Bugzilla 4.2 but with many features backported from 4.4 and master. All the BMO devs are also involved in the Bugzilla project, and we contribute features and fixes upstream where they are generally applicable, that is, not too specific to Mozilla's particular needs.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent_Changes|Recent Changes]] page.<br />
<br />
= B-Team =<br />
<br />
The team that works on BMO is called the B-Team, because of past affiliation with the defunct Automation and Tools team (A-Team).<br />
<br />
* dkl: Dave Lawrence (Owner/Engineer)<br />
* emceeaich: Emma Humphries, (Bugmaster)<br />
* kmoir: Kim Moir, (Manager)<br />
<br />
The Low-level, security, and quality tools team contributes tooling, and development:<br />
<br />
* calixte: Calixte Denizet, (AutoNag)<br />
* marco: Marco Castelluccio, (BugBug)<br />
<br />
We also also have some volunteers, that we consider to be part of the B-Team as well:<br />
<br />
* seban: Sebastin Santy (long-term volunteer, past GSoC student)<br />
* atoll: Richard Solderberg (Reviewer-at-Large, slightly borrowed from Mozilla IT)<br />
* kohei: Kohei Yoshino, (UX Designer)<br />
* ''... and you can be one too!''<br />
<br />
There are also some people that still have some involvement with BMO,<br />
but their day-to-day attention is directed to other parts of Mozilla.<br />
<br />
* glob: Byron Jones<br />
* zeid: Zeid Zabaneh (Engineer)<br />
* mhentges: Mitchell Hentges (Engineer)<br />
<br />
Past contributors include:<br />
* mary: Mary Umoh (Intern, Summer 2017)<br />
* gerv: Gervase Markham<br />
* mcote: Mark C&ocirc;t&eacute;<br />
* dylan: Dylan Hardison<br />
* imadueme: Israel Madueme (Engineer)<br />
* justdave: Dave Miller<br />
<br />
= New Users =<br />
<br />
Getting used to Bugzilla can be a bit daunting. We have a short [https://gerv.makes.org/popcorn/1bn6 introductory video] available that is as gentle as possible. You may also be interested in the [[https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla MDN section about Bugzilla]], which contains information more suitable as an introduction to a general audience. Of special interest is the MDN article, [https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla What to do and what not to do in Bugzilla], which contains instructions on getting elevated privileges.<br />
<br />
= New Bots =<br />
<br />
If you have a bot that uses BMO, be sure to add it to the [[BMO/Bot Registry]]<br />
so we know who to contact about it!<br />
<br />
= User Guide =<br />
<br />
We're putting together a [[BMO/UserGuide|user guide]] with helpful information on various aspects of Bugzilla. New and experienced users alike should benefit from it. There's a lot to go through, so please feel free to contribute!<br />
<br />
= Road Map =<br />
<br />
We keep a yearly [[BMO/Road Map|road map]] with our medium-term plans (1-2 years), at a high level. Also see our [[BMO#Current_Projects|current projects]] for some of the big items we are working on in the current quarter.<br />
<br />
= Browser Support For BMO =<br />
<br />
Full Support includes: The current versions of Firefox, Chrome, Chromium, Safari, WebKit, and Edge; and the latest Firefox ESR.<br />
<br />
Limited Support includes: The previous versions of Firefox, Chrome, Chromium, Safari, WebKit, Edge, and Firefox ESR; and Firefox Nightly.<br />
<br />
Internet Explorer is no longer supported, though some features may still work with IE 11.<br />
<br />
See {{bug|1359310}} and {{bug|1422435}}.<br />
<br />
== JavaScript and Analytics ==<br />
<br />
JavaScript is required to use bugzilla.mozilla.org. <br />
<br />
The <code>Do Not Track</code> header sent by your browser is honored.<br />
<br />
= Third-Party Applications =<br />
<br />
Lots and lots of web apps and general tools have been written to interface with BMO. We have started [[BMO/ThirdPartyApps|cataloguing them]]. If you're looking for different ways to interface with BMO, check it out; similarly, if you are thinking about writing an app, check the catalogue to see if something similar exists that you could use, contribute to, or fork before setting out on your own.<br />
<br />
There's one in particular that is particularly important: [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Phabricator], Mozilla's new and growing code-review tool.<br />
<br />
= More Information about BMO =<br />
<br />
Our discussion forum is mozilla.tools.bmo [[https://lists.mozilla.org/listinfo/tools-bmo mailing list]] [[https://groups.google.com/forum/#!forum/mozilla.tools.bmo Google Group]] [[news://news.mozilla.org:119/mozilla.tools.bmo USENET]].<br />
<br />
We also have answers to [[BMO/FAQ|Frequently Asked Questions]] and a slightly-but-not-too-out-of-date [http://people.mozilla.org/~justdave/BugzillaPhysicalDiagram-rev110504.png hardware diagram].<br />
<br />
If you're building an application or tool that interfaces with BMO, you may be interested in the following:<br />
<br />
* [[BMO/Integration_Best_Practice|Best practices and etiquette]] for integrating external apps with BMO<br />
* Info and plans on Bugzilla's [[Bugzilla:REST_API|REST API]], and the older, deprecated [[Bugzilla:BzAPI|BzAPI]].<br />
<br />
Looking for another way to access Bugzilla's raw data? Try the [[BMO/ElasticSearch|ElasticSearch cluster]].<br />
<br />
= Contributing to BMO =<br />
<br />
If you'd like to help out with BMO specifically (as opposed to the general upstream [[Bugzilla|Bugzilla project]]), you can find us in [irc://irc.mozilla.org/bmo #bmo] on irc.mozilla.org. If you plan on contributing patches, see the documentation in the [https://github.com/mozilla-bteam/bmo/blob/master/README.rst README.rst]. You can file bugs under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org bugzilla.mozilla.org product]. Don't file them under the Bugzilla product unless you are sure it's a bug in the general Bugzilla product. In particular, all administrative changes should be filed under bugzilla.mozilla.org (see below for more).<br />
<br />
= Policies and Procedures =<br />
<br />
<br />
== Code Updates ==<br />
<br />
Code updates are normally deployed to bugzilla.mozilla.org late Monday/early Tuesday, US/Pacific time, at no specific time, if changes need to be pushed out. Security fixes or other fatal type errors will always go out as soon as possible.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent Changes]] page. <br />
<br />
== Administrative Changes ==<br />
<br />
If you need changes to BMO's configuration to support your team, project, etc., please consult this page before filing bugs:<br />
<br />
* [[BMO/Requesting Changes|General information on requesting Changes to BMO]]<br />
<br />
== BMO Administrative Processes ==<br />
<br />
* [[BMO/new-product|Adding a new product]]<br />
* [[BMO/new-version|Adding a new "rapid release" version]]<br />
* [[BMO/new-security-group|Adding a new BMO security group]]<br />
* [[BMO/RetiringComponents|Retiring Products and Components]]: moving things to the Graveyard classification.<br />
* [[BMO/RestoringDisabledAccounts|Restoring Disabled Accounts]]<br />
* [[BMO/MergingAccounts|Merging Accounts]]<br />
* [[BMO/DisablingAccounts|Disabling Accounts]]<br />
<br />
See also [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=45845955 BMO on Mana] (requires LDAP).<br />
<br />
== BMO Development and Other Processes ==<br />
<br />
* [[BMO/Development Processes|Overall Development Processes]]<br />
<br />
* [[BMO/OutagePlanning|Planning a BMO outage]]<br />
* [[BMO/ResetDevelopmentBranch|Reset the development branch to master]]<br />
* [[BMO/Perl Dependencies|Maintaining Perl Dependencies for BMO]]<br />
<br />
== Custom Bug Entry Forms ==<br />
<br />
In the past, BMO developers supported writing custom bug entry forms specific for the needs of different projects and groups within Mozilla. In order to focus more on other important features, we will no longer be providing that support going forward. For more information on why this change was made, see [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/tp4dSwUfKSA here].<br />
<br />
There is a new [https://github.com/mozilla-bteam/custom-form-example custom form framework] being developed by an outside contributor named Sebastin Santy. It is still in the early stages but it eventually will be very useful for users who want to create a customized bug entry form that can be used to submit bugs to BMO.<br />
<br />
= Current Projects =<br />
<br />
This table lists the bugs representing the current quarterly goals (and, near the end of the quarter, sometimes next quarter's goals). Those that were set at the beginning of the quarter are tagged with the keyword "bmo-goal". The BMO team also regularly gets requests for high-priority work items throughout the quarter; those that will take more than a day or two in total, thus potentially jeopardizing other goals, are included below, tagged with "bmo-big". The daily smaller tasks are also generally tracked in Bugzilla but not represented in the table below.<br />
<br />
P1 indicates a critical project. P2 indicates an important but deferrable item. P3 is as P2 but more deferrable. Note that all items are important, and it is presumed that lower-priority items will increase in priority over time as high-priority tasks are completed, i.e., we don't plan to defer any of these tasks indefinitely.<br />
<br />
== Goals ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-goal",<br />
"keywords_type": "anywords",<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2018-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== High-Priority ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"product": "bugzilla.mozilla.org",<br />
"keywords": "bmo-on-deck, bmo-goal",<br />
"keywords_type": "nowords",<br />
"priority": ["P1"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"status": ["ASSIGNED"],<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== Upcoming ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck",<br />
"keywords_type": "anywords",<br />
"priority": ["--","P1","P2","P3","P4","P5"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
Further documentation about goals above and other projects follows:<br />
<br />
* [[BMO/UserRoles|User Roles]]<br />
** Generate different user roles based on what tasks a user is trying to complete when using the BMO system.<br />
<br />
== Past Projects ==<br />
<br />
Some of these will have on-going maintenance and improvements, but the initial deployment has been accomplished. Others have been abandoned or rejected due to various factors, noted below.<br />
<br />
* [[BMO/ChangeNotificationSystem|Change Notification System]]<br />
* [[BMO/40Upgrade|4.0 Upgrade]]<br />
* [[BMO/42Upgrade|4.2 Upgrade]] (Completed March 5th, 2013)<br />
* [[BMO/UserProfiles|User Profiles]]<br />
* [[BMO/TrackingFlags|Tracking Flags]]<br />
* [[Bugzilla:REST_API|Native REST API]]<br />
* [[BMO/Pulse|Pulse Integration]]<br />
** This was completed and deployed, but it generated a lot of traffic and is of questionable utility since it must access Bugzilla as an anonymous user. A simpler, more general system is the [[BMO/ChangeNotificationSystem|Change Notification System]].<br />
* [[Bugzilla:Migrating_to_git|Migrating Bugzilla and BMO code from bzr to git]]<br />
** Completed 2014/03/11.<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO&diff=1223925BMO2020-02-18T22:36:38Z<p>Emceeaich: /* High-Priority */</p>
<hr />
<div>This is the main public page for all things related to https://bugzilla.mozilla.org, aka BMO, Mozilla's customized version of [http://www.bugzilla.org Bugzilla]. <br />
<br />
BMO is a core piece of infrastructure at Mozilla. It is used to track not only bugs and feature requests but also many other tasks across various teams.<br />
<br />
The BMO source is a slightly modified fork of Bugzilla with many custom extensions. It is currently based on Bugzilla 4.2 but with many features backported from 4.4 and master. All the BMO devs are also involved in the Bugzilla project, and we contribute features and fixes upstream where they are generally applicable, that is, not too specific to Mozilla's particular needs.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent_Changes|Recent Changes]] page.<br />
<br />
= B-Team =<br />
<br />
The team that works on BMO is called the B-Team, because of past affiliation with the defunct Automation and Tools team (A-Team).<br />
<br />
* dkl: Dave Lawrence (Owner/Engineer)<br />
* emceeaich: Emma Humphries, (Bugmaster)<br />
* kmoir: Kim Moir, (Manager)<br />
<br />
The Low-level, security, and quality tools team contributes tooling, and development:<br />
<br />
* calixte: Calixte Denizet, (AutoNag)<br />
* marco: Marco Castelluccio, (BugBug)<br />
<br />
We also also have some volunteers, that we consider to be part of the B-Team as well:<br />
<br />
* seban: Sebastin Santy (long-term volunteer, past GSoC student)<br />
* atoll: Richard Solderberg (Reviewer-at-Large, slightly borrowed from Mozilla IT)<br />
* kohei: Kohei Yoshino, (UX Designer)<br />
* ''... and you can be one too!''<br />
<br />
There are also some people that still have some involvement with BMO,<br />
but their day-to-day attention is directed to other parts of Mozilla.<br />
<br />
* glob: Byron Jones<br />
* zeid: Zeid Zabaneh (Engineer)<br />
* mhentges: Mitchell Hentges (Engineer)<br />
<br />
Past contributors include:<br />
* mary: Mary Umoh (Intern, Summer 2017)<br />
* gerv: Gervase Markham<br />
* mcote: Mark C&ocirc;t&eacute;<br />
* dylan: Dylan Hardison<br />
* imadueme: Israel Madueme (Engineer)<br />
* justdave: Dave Miller<br />
<br />
= New Users =<br />
<br />
Getting used to Bugzilla can be a bit daunting. We have a short [https://gerv.makes.org/popcorn/1bn6 introductory video] available that is as gentle as possible. You may also be interested in the [[https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla MDN section about Bugzilla]], which contains information more suitable as an introduction to a general audience. Of special interest is the MDN article, [https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla What to do and what not to do in Bugzilla], which contains instructions on getting elevated privileges.<br />
<br />
= New Bots =<br />
<br />
If you have a bot that uses BMO, be sure to add it to the [[BMO/Bot Registry]]<br />
so we know who to contact about it!<br />
<br />
= User Guide =<br />
<br />
We're putting together a [[BMO/UserGuide|user guide]] with helpful information on various aspects of Bugzilla. New and experienced users alike should benefit from it. There's a lot to go through, so please feel free to contribute!<br />
<br />
= Road Map =<br />
<br />
We keep a yearly [[BMO/Road Map|road map]] with our medium-term plans (1-2 years), at a high level. Also see our [[BMO#Current_Projects|current projects]] for some of the big items we are working on in the current quarter.<br />
<br />
= Browser Support For BMO =<br />
<br />
Full Support includes: The current versions of Firefox, Chrome, Chromium, Safari, WebKit, and Edge; and the latest Firefox ESR.<br />
<br />
Limited Support includes: The previous versions of Firefox, Chrome, Chromium, Safari, WebKit, Edge, and Firefox ESR; and Firefox Nightly.<br />
<br />
Internet Explorer is no longer supported, though some features may still work with IE 11.<br />
<br />
See {{bug|1359310}} and {{bug|1422435}}.<br />
<br />
== JavaScript and Analytics ==<br />
<br />
JavaScript is required to use bugzilla.mozilla.org. <br />
<br />
The <code>Do Not Track</code> header sent by your browser is honored.<br />
<br />
= Third-Party Applications =<br />
<br />
Lots and lots of web apps and general tools have been written to interface with BMO. We have started [[BMO/ThirdPartyApps|cataloguing them]]. If you're looking for different ways to interface with BMO, check it out; similarly, if you are thinking about writing an app, check the catalogue to see if something similar exists that you could use, contribute to, or fork before setting out on your own.<br />
<br />
There's one in particular that is particularly important: [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Phabricator], Mozilla's new and growing code-review tool.<br />
<br />
= More Information about BMO =<br />
<br />
Our discussion forum is mozilla.tools.bmo [[https://lists.mozilla.org/listinfo/tools-bmo mailing list]] [[https://groups.google.com/forum/#!forum/mozilla.tools.bmo Google Group]] [[news://news.mozilla.org:119/mozilla.tools.bmo USENET]].<br />
<br />
We also have answers to [[BMO/FAQ|Frequently Asked Questions]] and a slightly-but-not-too-out-of-date [http://people.mozilla.org/~justdave/BugzillaPhysicalDiagram-rev110504.png hardware diagram].<br />
<br />
If you're building an application or tool that interfaces with BMO, you may be interested in the following:<br />
<br />
* [[BMO/Integration_Best_Practice|Best practices and etiquette]] for integrating external apps with BMO<br />
* Info and plans on Bugzilla's [[Bugzilla:REST_API|REST API]], and the older, deprecated [[Bugzilla:BzAPI|BzAPI]].<br />
<br />
Looking for another way to access Bugzilla's raw data? Try the [[BMO/ElasticSearch|ElasticSearch cluster]].<br />
<br />
= Contributing to BMO =<br />
<br />
If you'd like to help out with BMO specifically (as opposed to the general upstream [[Bugzilla|Bugzilla project]]), you can find us in [irc://irc.mozilla.org/bmo #bmo] on irc.mozilla.org. If you plan on contributing patches, see the documentation in the [https://github.com/mozilla-bteam/bmo/blob/master/README.rst README.rst]. You can file bugs under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org bugzilla.mozilla.org product]. Don't file them under the Bugzilla product unless you are sure it's a bug in the general Bugzilla product. In particular, all administrative changes should be filed under bugzilla.mozilla.org (see below for more).<br />
<br />
= Policies and Procedures =<br />
<br />
<br />
== Code Updates ==<br />
<br />
Code updates are normally deployed to bugzilla.mozilla.org late Monday/early Tuesday, US/Pacific time, at no specific time, if changes need to be pushed out. Security fixes or other fatal type errors will always go out as soon as possible.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent Changes]] page. <br />
<br />
== Administrative Changes ==<br />
<br />
If you need changes to BMO's configuration to support your team, project, etc., please consult this page before filing bugs:<br />
<br />
* [[BMO/Requesting Changes|General information on requesting Changes to BMO]]<br />
<br />
== BMO Administrative Processes ==<br />
<br />
* [[BMO/new-product|Adding a new product]]<br />
* [[BMO/new-version|Adding a new "rapid release" version]]<br />
* [[BMO/new-security-group|Adding a new BMO security group]]<br />
* [[BMO/RetiringComponents|Retiring Products and Components]]: moving things to the Graveyard classification.<br />
* [[BMO/RestoringDisabledAccounts|Restoring Disabled Accounts]]<br />
* [[BMO/MergingAccounts|Merging Accounts]]<br />
* [[BMO/DisablingAccounts|Disabling Accounts]]<br />
<br />
See also [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=45845955 BMO on Mana] (requires LDAP).<br />
<br />
== BMO Development and Other Processes ==<br />
<br />
* [[BMO/Development Processes|Overall Development Processes]]<br />
<br />
* [[BMO/OutagePlanning|Planning a BMO outage]]<br />
* [[BMO/ResetDevelopmentBranch|Reset the development branch to master]]<br />
* [[BMO/Perl Dependencies|Maintaining Perl Dependencies for BMO]]<br />
<br />
== Custom Bug Entry Forms ==<br />
<br />
In the past, BMO developers supported writing custom bug entry forms specific for the needs of different projects and groups within Mozilla. In order to focus more on other important features, we will no longer be providing that support going forward. For more information on why this change was made, see [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/tp4dSwUfKSA here].<br />
<br />
There is a new [https://github.com/mozilla-bteam/custom-form-example custom form framework] being developed by an outside contributor named Sebastin Santy. It is still in the early stages but it eventually will be very useful for users who want to create a customized bug entry form that can be used to submit bugs to BMO.<br />
<br />
= Current Projects =<br />
<br />
This table lists the bugs representing the current quarterly goals (and, near the end of the quarter, sometimes next quarter's goals). Those that were set at the beginning of the quarter are tagged with the keyword "bmo-goal". The BMO team also regularly gets requests for high-priority work items throughout the quarter; those that will take more than a day or two in total, thus potentially jeopardizing other goals, are included below, tagged with "bmo-big". The daily smaller tasks are also generally tracked in Bugzilla but not represented in the table below.<br />
<br />
P1 indicates a critical project. P2 indicates an important but deferrable item. P3 is as P2 but more deferrable. Note that all items are important, and it is presumed that lower-priority items will increase in priority over time as high-priority tasks are completed, i.e., we don't plan to defer any of these tasks indefinitely.<br />
<br />
== Goals ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-goal",<br />
"keywords_type": "anywords",<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2018-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== High-Priority ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck, bmo-goal",<br />
"keywords_type": "nowords",<br />
"priority": ["P1"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"status": ["ASSIGNED"],<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== Upcoming ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck",<br />
"keywords_type": "anywords",<br />
"priority": ["--","P1","P2","P3","P4","P5"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
Further documentation about goals above and other projects follows:<br />
<br />
* [[BMO/UserRoles|User Roles]]<br />
** Generate different user roles based on what tasks a user is trying to complete when using the BMO system.<br />
<br />
== Past Projects ==<br />
<br />
Some of these will have on-going maintenance and improvements, but the initial deployment has been accomplished. Others have been abandoned or rejected due to various factors, noted below.<br />
<br />
* [[BMO/ChangeNotificationSystem|Change Notification System]]<br />
* [[BMO/40Upgrade|4.0 Upgrade]]<br />
* [[BMO/42Upgrade|4.2 Upgrade]] (Completed March 5th, 2013)<br />
* [[BMO/UserProfiles|User Profiles]]<br />
* [[BMO/TrackingFlags|Tracking Flags]]<br />
* [[Bugzilla:REST_API|Native REST API]]<br />
* [[BMO/Pulse|Pulse Integration]]<br />
** This was completed and deployed, but it generated a lot of traffic and is of questionable utility since it must access Bugzilla as an anonymous user. A simpler, more general system is the [[BMO/ChangeNotificationSystem|Change Notification System]].<br />
* [[Bugzilla:Migrating_to_git|Migrating Bugzilla and BMO code from bzr to git]]<br />
** Completed 2014/03/11.<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO&diff=1223923BMO2020-02-18T22:36:09Z<p>Emceeaich: /* High-Priority */ assigned P1s only</p>
<hr />
<div>This is the main public page for all things related to https://bugzilla.mozilla.org, aka BMO, Mozilla's customized version of [http://www.bugzilla.org Bugzilla]. <br />
<br />
BMO is a core piece of infrastructure at Mozilla. It is used to track not only bugs and feature requests but also many other tasks across various teams.<br />
<br />
The BMO source is a slightly modified fork of Bugzilla with many custom extensions. It is currently based on Bugzilla 4.2 but with many features backported from 4.4 and master. All the BMO devs are also involved in the Bugzilla project, and we contribute features and fixes upstream where they are generally applicable, that is, not too specific to Mozilla's particular needs.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent_Changes|Recent Changes]] page.<br />
<br />
= B-Team =<br />
<br />
The team that works on BMO is called the B-Team, because of past affiliation with the defunct Automation and Tools team (A-Team).<br />
<br />
* dkl: Dave Lawrence (Owner/Engineer)<br />
* emceeaich: Emma Humphries, (Bugmaster)<br />
* kmoir: Kim Moir, (Manager)<br />
<br />
The Low-level, security, and quality tools team contributes tooling, and development:<br />
<br />
* calixte: Calixte Denizet, (AutoNag)<br />
* marco: Marco Castelluccio, (BugBug)<br />
<br />
We also also have some volunteers, that we consider to be part of the B-Team as well:<br />
<br />
* seban: Sebastin Santy (long-term volunteer, past GSoC student)<br />
* atoll: Richard Solderberg (Reviewer-at-Large, slightly borrowed from Mozilla IT)<br />
* kohei: Kohei Yoshino, (UX Designer)<br />
* ''... and you can be one too!''<br />
<br />
There are also some people that still have some involvement with BMO,<br />
but their day-to-day attention is directed to other parts of Mozilla.<br />
<br />
* glob: Byron Jones<br />
* zeid: Zeid Zabaneh (Engineer)<br />
* mhentges: Mitchell Hentges (Engineer)<br />
<br />
Past contributors include:<br />
* mary: Mary Umoh (Intern, Summer 2017)<br />
* gerv: Gervase Markham<br />
* mcote: Mark C&ocirc;t&eacute;<br />
* dylan: Dylan Hardison<br />
* imadueme: Israel Madueme (Engineer)<br />
* justdave: Dave Miller<br />
<br />
= New Users =<br />
<br />
Getting used to Bugzilla can be a bit daunting. We have a short [https://gerv.makes.org/popcorn/1bn6 introductory video] available that is as gentle as possible. You may also be interested in the [[https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla MDN section about Bugzilla]], which contains information more suitable as an introduction to a general audience. Of special interest is the MDN article, [https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla What to do and what not to do in Bugzilla], which contains instructions on getting elevated privileges.<br />
<br />
= New Bots =<br />
<br />
If you have a bot that uses BMO, be sure to add it to the [[BMO/Bot Registry]]<br />
so we know who to contact about it!<br />
<br />
= User Guide =<br />
<br />
We're putting together a [[BMO/UserGuide|user guide]] with helpful information on various aspects of Bugzilla. New and experienced users alike should benefit from it. There's a lot to go through, so please feel free to contribute!<br />
<br />
= Road Map =<br />
<br />
We keep a yearly [[BMO/Road Map|road map]] with our medium-term plans (1-2 years), at a high level. Also see our [[BMO#Current_Projects|current projects]] for some of the big items we are working on in the current quarter.<br />
<br />
= Browser Support For BMO =<br />
<br />
Full Support includes: The current versions of Firefox, Chrome, Chromium, Safari, WebKit, and Edge; and the latest Firefox ESR.<br />
<br />
Limited Support includes: The previous versions of Firefox, Chrome, Chromium, Safari, WebKit, Edge, and Firefox ESR; and Firefox Nightly.<br />
<br />
Internet Explorer is no longer supported, though some features may still work with IE 11.<br />
<br />
See {{bug|1359310}} and {{bug|1422435}}.<br />
<br />
== JavaScript and Analytics ==<br />
<br />
JavaScript is required to use bugzilla.mozilla.org. <br />
<br />
The <code>Do Not Track</code> header sent by your browser is honored.<br />
<br />
= Third-Party Applications =<br />
<br />
Lots and lots of web apps and general tools have been written to interface with BMO. We have started [[BMO/ThirdPartyApps|cataloguing them]]. If you're looking for different ways to interface with BMO, check it out; similarly, if you are thinking about writing an app, check the catalogue to see if something similar exists that you could use, contribute to, or fork before setting out on your own.<br />
<br />
There's one in particular that is particularly important: [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Phabricator], Mozilla's new and growing code-review tool.<br />
<br />
= More Information about BMO =<br />
<br />
Our discussion forum is mozilla.tools.bmo [[https://lists.mozilla.org/listinfo/tools-bmo mailing list]] [[https://groups.google.com/forum/#!forum/mozilla.tools.bmo Google Group]] [[news://news.mozilla.org:119/mozilla.tools.bmo USENET]].<br />
<br />
We also have answers to [[BMO/FAQ|Frequently Asked Questions]] and a slightly-but-not-too-out-of-date [http://people.mozilla.org/~justdave/BugzillaPhysicalDiagram-rev110504.png hardware diagram].<br />
<br />
If you're building an application or tool that interfaces with BMO, you may be interested in the following:<br />
<br />
* [[BMO/Integration_Best_Practice|Best practices and etiquette]] for integrating external apps with BMO<br />
* Info and plans on Bugzilla's [[Bugzilla:REST_API|REST API]], and the older, deprecated [[Bugzilla:BzAPI|BzAPI]].<br />
<br />
Looking for another way to access Bugzilla's raw data? Try the [[BMO/ElasticSearch|ElasticSearch cluster]].<br />
<br />
= Contributing to BMO =<br />
<br />
If you'd like to help out with BMO specifically (as opposed to the general upstream [[Bugzilla|Bugzilla project]]), you can find us in [irc://irc.mozilla.org/bmo #bmo] on irc.mozilla.org. If you plan on contributing patches, see the documentation in the [https://github.com/mozilla-bteam/bmo/blob/master/README.rst README.rst]. You can file bugs under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org bugzilla.mozilla.org product]. Don't file them under the Bugzilla product unless you are sure it's a bug in the general Bugzilla product. In particular, all administrative changes should be filed under bugzilla.mozilla.org (see below for more).<br />
<br />
= Policies and Procedures =<br />
<br />
<br />
== Code Updates ==<br />
<br />
Code updates are normally deployed to bugzilla.mozilla.org late Monday/early Tuesday, US/Pacific time, at no specific time, if changes need to be pushed out. Security fixes or other fatal type errors will always go out as soon as possible.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent Changes]] page. <br />
<br />
== Administrative Changes ==<br />
<br />
If you need changes to BMO's configuration to support your team, project, etc., please consult this page before filing bugs:<br />
<br />
* [[BMO/Requesting Changes|General information on requesting Changes to BMO]]<br />
<br />
== BMO Administrative Processes ==<br />
<br />
* [[BMO/new-product|Adding a new product]]<br />
* [[BMO/new-version|Adding a new "rapid release" version]]<br />
* [[BMO/new-security-group|Adding a new BMO security group]]<br />
* [[BMO/RetiringComponents|Retiring Products and Components]]: moving things to the Graveyard classification.<br />
* [[BMO/RestoringDisabledAccounts|Restoring Disabled Accounts]]<br />
* [[BMO/MergingAccounts|Merging Accounts]]<br />
* [[BMO/DisablingAccounts|Disabling Accounts]]<br />
<br />
See also [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=45845955 BMO on Mana] (requires LDAP).<br />
<br />
== BMO Development and Other Processes ==<br />
<br />
* [[BMO/Development Processes|Overall Development Processes]]<br />
<br />
* [[BMO/OutagePlanning|Planning a BMO outage]]<br />
* [[BMO/ResetDevelopmentBranch|Reset the development branch to master]]<br />
* [[BMO/Perl Dependencies|Maintaining Perl Dependencies for BMO]]<br />
<br />
== Custom Bug Entry Forms ==<br />
<br />
In the past, BMO developers supported writing custom bug entry forms specific for the needs of different projects and groups within Mozilla. In order to focus more on other important features, we will no longer be providing that support going forward. For more information on why this change was made, see [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/tp4dSwUfKSA here].<br />
<br />
There is a new [https://github.com/mozilla-bteam/custom-form-example custom form framework] being developed by an outside contributor named Sebastin Santy. It is still in the early stages but it eventually will be very useful for users who want to create a customized bug entry form that can be used to submit bugs to BMO.<br />
<br />
= Current Projects =<br />
<br />
This table lists the bugs representing the current quarterly goals (and, near the end of the quarter, sometimes next quarter's goals). Those that were set at the beginning of the quarter are tagged with the keyword "bmo-goal". The BMO team also regularly gets requests for high-priority work items throughout the quarter; those that will take more than a day or two in total, thus potentially jeopardizing other goals, are included below, tagged with "bmo-big". The daily smaller tasks are also generally tracked in Bugzilla but not represented in the table below.<br />
<br />
P1 indicates a critical project. P2 indicates an important but deferrable item. P3 is as P2 but more deferrable. Note that all items are important, and it is presumed that lower-priority items will increase in priority over time as high-priority tasks are completed, i.e., we don't plan to defer any of these tasks indefinitely.<br />
<br />
== Goals ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-goal",<br />
"keywords_type": "anywords",<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2018-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== High-Priority ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck, bmo-goal",<br />
"keywords_type": "nowords",<br />
"priority": ["P1"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"status": "ASSIGNED"<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== Upcoming ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck",<br />
"keywords_type": "anywords",<br />
"priority": ["--","P1","P2","P3","P4","P5"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
Further documentation about goals above and other projects follows:<br />
<br />
* [[BMO/UserRoles|User Roles]]<br />
** Generate different user roles based on what tasks a user is trying to complete when using the BMO system.<br />
<br />
== Past Projects ==<br />
<br />
Some of these will have on-going maintenance and improvements, but the initial deployment has been accomplished. Others have been abandoned or rejected due to various factors, noted below.<br />
<br />
* [[BMO/ChangeNotificationSystem|Change Notification System]]<br />
* [[BMO/40Upgrade|4.0 Upgrade]]<br />
* [[BMO/42Upgrade|4.2 Upgrade]] (Completed March 5th, 2013)<br />
* [[BMO/UserProfiles|User Profiles]]<br />
* [[BMO/TrackingFlags|Tracking Flags]]<br />
* [[Bugzilla:REST_API|Native REST API]]<br />
* [[BMO/Pulse|Pulse Integration]]<br />
** This was completed and deployed, but it generated a lot of traffic and is of questionable utility since it must access Bugzilla as an anonymous user. A simpler, more general system is the [[BMO/ChangeNotificationSystem|Change Notification System]].<br />
* [[Bugzilla:Migrating_to_git|Migrating Bugzilla and BMO code from bzr to git]]<br />
** Completed 2014/03/11.<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO&diff=1223922BMO2020-02-18T22:34:37Z<p>Emceeaich: /* High-Priority */ more updates to query</p>
<hr />
<div>This is the main public page for all things related to https://bugzilla.mozilla.org, aka BMO, Mozilla's customized version of [http://www.bugzilla.org Bugzilla]. <br />
<br />
BMO is a core piece of infrastructure at Mozilla. It is used to track not only bugs and feature requests but also many other tasks across various teams.<br />
<br />
The BMO source is a slightly modified fork of Bugzilla with many custom extensions. It is currently based on Bugzilla 4.2 but with many features backported from 4.4 and master. All the BMO devs are also involved in the Bugzilla project, and we contribute features and fixes upstream where they are generally applicable, that is, not too specific to Mozilla's particular needs.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent_Changes|Recent Changes]] page.<br />
<br />
= B-Team =<br />
<br />
The team that works on BMO is called the B-Team, because of past affiliation with the defunct Automation and Tools team (A-Team).<br />
<br />
* dkl: Dave Lawrence (Owner/Engineer)<br />
* emceeaich: Emma Humphries, (Bugmaster)<br />
* kmoir: Kim Moir, (Manager)<br />
<br />
The Low-level, security, and quality tools team contributes tooling, and development:<br />
<br />
* calixte: Calixte Denizet, (AutoNag)<br />
* marco: Marco Castelluccio, (BugBug)<br />
<br />
We also also have some volunteers, that we consider to be part of the B-Team as well:<br />
<br />
* seban: Sebastin Santy (long-term volunteer, past GSoC student)<br />
* atoll: Richard Solderberg (Reviewer-at-Large, slightly borrowed from Mozilla IT)<br />
* kohei: Kohei Yoshino, (UX Designer)<br />
* ''... and you can be one too!''<br />
<br />
There are also some people that still have some involvement with BMO,<br />
but their day-to-day attention is directed to other parts of Mozilla.<br />
<br />
* glob: Byron Jones<br />
* zeid: Zeid Zabaneh (Engineer)<br />
* mhentges: Mitchell Hentges (Engineer)<br />
<br />
Past contributors include:<br />
* mary: Mary Umoh (Intern, Summer 2017)<br />
* gerv: Gervase Markham<br />
* mcote: Mark C&ocirc;t&eacute;<br />
* dylan: Dylan Hardison<br />
* imadueme: Israel Madueme (Engineer)<br />
* justdave: Dave Miller<br />
<br />
= New Users =<br />
<br />
Getting used to Bugzilla can be a bit daunting. We have a short [https://gerv.makes.org/popcorn/1bn6 introductory video] available that is as gentle as possible. You may also be interested in the [[https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla MDN section about Bugzilla]], which contains information more suitable as an introduction to a general audience. Of special interest is the MDN article, [https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla What to do and what not to do in Bugzilla], which contains instructions on getting elevated privileges.<br />
<br />
= New Bots =<br />
<br />
If you have a bot that uses BMO, be sure to add it to the [[BMO/Bot Registry]]<br />
so we know who to contact about it!<br />
<br />
= User Guide =<br />
<br />
We're putting together a [[BMO/UserGuide|user guide]] with helpful information on various aspects of Bugzilla. New and experienced users alike should benefit from it. There's a lot to go through, so please feel free to contribute!<br />
<br />
= Road Map =<br />
<br />
We keep a yearly [[BMO/Road Map|road map]] with our medium-term plans (1-2 years), at a high level. Also see our [[BMO#Current_Projects|current projects]] for some of the big items we are working on in the current quarter.<br />
<br />
= Browser Support For BMO =<br />
<br />
Full Support includes: The current versions of Firefox, Chrome, Chromium, Safari, WebKit, and Edge; and the latest Firefox ESR.<br />
<br />
Limited Support includes: The previous versions of Firefox, Chrome, Chromium, Safari, WebKit, Edge, and Firefox ESR; and Firefox Nightly.<br />
<br />
Internet Explorer is no longer supported, though some features may still work with IE 11.<br />
<br />
See {{bug|1359310}} and {{bug|1422435}}.<br />
<br />
== JavaScript and Analytics ==<br />
<br />
JavaScript is required to use bugzilla.mozilla.org. <br />
<br />
The <code>Do Not Track</code> header sent by your browser is honored.<br />
<br />
= Third-Party Applications =<br />
<br />
Lots and lots of web apps and general tools have been written to interface with BMO. We have started [[BMO/ThirdPartyApps|cataloguing them]]. If you're looking for different ways to interface with BMO, check it out; similarly, if you are thinking about writing an app, check the catalogue to see if something similar exists that you could use, contribute to, or fork before setting out on your own.<br />
<br />
There's one in particular that is particularly important: [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Phabricator], Mozilla's new and growing code-review tool.<br />
<br />
= More Information about BMO =<br />
<br />
Our discussion forum is mozilla.tools.bmo [[https://lists.mozilla.org/listinfo/tools-bmo mailing list]] [[https://groups.google.com/forum/#!forum/mozilla.tools.bmo Google Group]] [[news://news.mozilla.org:119/mozilla.tools.bmo USENET]].<br />
<br />
We also have answers to [[BMO/FAQ|Frequently Asked Questions]] and a slightly-but-not-too-out-of-date [http://people.mozilla.org/~justdave/BugzillaPhysicalDiagram-rev110504.png hardware diagram].<br />
<br />
If you're building an application or tool that interfaces with BMO, you may be interested in the following:<br />
<br />
* [[BMO/Integration_Best_Practice|Best practices and etiquette]] for integrating external apps with BMO<br />
* Info and plans on Bugzilla's [[Bugzilla:REST_API|REST API]], and the older, deprecated [[Bugzilla:BzAPI|BzAPI]].<br />
<br />
Looking for another way to access Bugzilla's raw data? Try the [[BMO/ElasticSearch|ElasticSearch cluster]].<br />
<br />
= Contributing to BMO =<br />
<br />
If you'd like to help out with BMO specifically (as opposed to the general upstream [[Bugzilla|Bugzilla project]]), you can find us in [irc://irc.mozilla.org/bmo #bmo] on irc.mozilla.org. If you plan on contributing patches, see the documentation in the [https://github.com/mozilla-bteam/bmo/blob/master/README.rst README.rst]. You can file bugs under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org bugzilla.mozilla.org product]. Don't file them under the Bugzilla product unless you are sure it's a bug in the general Bugzilla product. In particular, all administrative changes should be filed under bugzilla.mozilla.org (see below for more).<br />
<br />
= Policies and Procedures =<br />
<br />
<br />
== Code Updates ==<br />
<br />
Code updates are normally deployed to bugzilla.mozilla.org late Monday/early Tuesday, US/Pacific time, at no specific time, if changes need to be pushed out. Security fixes or other fatal type errors will always go out as soon as possible.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent Changes]] page. <br />
<br />
== Administrative Changes ==<br />
<br />
If you need changes to BMO's configuration to support your team, project, etc., please consult this page before filing bugs:<br />
<br />
* [[BMO/Requesting Changes|General information on requesting Changes to BMO]]<br />
<br />
== BMO Administrative Processes ==<br />
<br />
* [[BMO/new-product|Adding a new product]]<br />
* [[BMO/new-version|Adding a new "rapid release" version]]<br />
* [[BMO/new-security-group|Adding a new BMO security group]]<br />
* [[BMO/RetiringComponents|Retiring Products and Components]]: moving things to the Graveyard classification.<br />
* [[BMO/RestoringDisabledAccounts|Restoring Disabled Accounts]]<br />
* [[BMO/MergingAccounts|Merging Accounts]]<br />
* [[BMO/DisablingAccounts|Disabling Accounts]]<br />
<br />
See also [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=45845955 BMO on Mana] (requires LDAP).<br />
<br />
== BMO Development and Other Processes ==<br />
<br />
* [[BMO/Development Processes|Overall Development Processes]]<br />
<br />
* [[BMO/OutagePlanning|Planning a BMO outage]]<br />
* [[BMO/ResetDevelopmentBranch|Reset the development branch to master]]<br />
* [[BMO/Perl Dependencies|Maintaining Perl Dependencies for BMO]]<br />
<br />
== Custom Bug Entry Forms ==<br />
<br />
In the past, BMO developers supported writing custom bug entry forms specific for the needs of different projects and groups within Mozilla. In order to focus more on other important features, we will no longer be providing that support going forward. For more information on why this change was made, see [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/tp4dSwUfKSA here].<br />
<br />
There is a new [https://github.com/mozilla-bteam/custom-form-example custom form framework] being developed by an outside contributor named Sebastin Santy. It is still in the early stages but it eventually will be very useful for users who want to create a customized bug entry form that can be used to submit bugs to BMO.<br />
<br />
= Current Projects =<br />
<br />
This table lists the bugs representing the current quarterly goals (and, near the end of the quarter, sometimes next quarter's goals). Those that were set at the beginning of the quarter are tagged with the keyword "bmo-goal". The BMO team also regularly gets requests for high-priority work items throughout the quarter; those that will take more than a day or two in total, thus potentially jeopardizing other goals, are included below, tagged with "bmo-big". The daily smaller tasks are also generally tracked in Bugzilla but not represented in the table below.<br />
<br />
P1 indicates a critical project. P2 indicates an important but deferrable item. P3 is as P2 but more deferrable. Note that all items are important, and it is presumed that lower-priority items will increase in priority over time as high-priority tasks are completed, i.e., we don't plan to defer any of these tasks indefinitely.<br />
<br />
== Goals ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-goal",<br />
"keywords_type": "anywords",<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2018-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== High-Priority ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck, bmo-goal",<br />
"keywords_type": "nowords",<br />
"priority": ["P1"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== Upcoming ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck",<br />
"keywords_type": "anywords",<br />
"priority": ["--","P1","P2","P3","P4","P5"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
Further documentation about goals above and other projects follows:<br />
<br />
* [[BMO/UserRoles|User Roles]]<br />
** Generate different user roles based on what tasks a user is trying to complete when using the BMO system.<br />
<br />
== Past Projects ==<br />
<br />
Some of these will have on-going maintenance and improvements, but the initial deployment has been accomplished. Others have been abandoned or rejected due to various factors, noted below.<br />
<br />
* [[BMO/ChangeNotificationSystem|Change Notification System]]<br />
* [[BMO/40Upgrade|4.0 Upgrade]]<br />
* [[BMO/42Upgrade|4.2 Upgrade]] (Completed March 5th, 2013)<br />
* [[BMO/UserProfiles|User Profiles]]<br />
* [[BMO/TrackingFlags|Tracking Flags]]<br />
* [[Bugzilla:REST_API|Native REST API]]<br />
* [[BMO/Pulse|Pulse Integration]]<br />
** This was completed and deployed, but it generated a lot of traffic and is of questionable utility since it must access Bugzilla as an anonymous user. A simpler, more general system is the [[BMO/ChangeNotificationSystem|Change Notification System]].<br />
* [[Bugzilla:Migrating_to_git|Migrating Bugzilla and BMO code from bzr to git]]<br />
** Completed 2014/03/11.<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO&diff=1223921BMO2020-02-18T22:33:26Z<p>Emceeaich: /* High-Priority */ update query</p>
<hr />
<div>This is the main public page for all things related to https://bugzilla.mozilla.org, aka BMO, Mozilla's customized version of [http://www.bugzilla.org Bugzilla]. <br />
<br />
BMO is a core piece of infrastructure at Mozilla. It is used to track not only bugs and feature requests but also many other tasks across various teams.<br />
<br />
The BMO source is a slightly modified fork of Bugzilla with many custom extensions. It is currently based on Bugzilla 4.2 but with many features backported from 4.4 and master. All the BMO devs are also involved in the Bugzilla project, and we contribute features and fixes upstream where they are generally applicable, that is, not too specific to Mozilla's particular needs.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent_Changes|Recent Changes]] page.<br />
<br />
= B-Team =<br />
<br />
The team that works on BMO is called the B-Team, because of past affiliation with the defunct Automation and Tools team (A-Team).<br />
<br />
* dkl: Dave Lawrence (Owner/Engineer)<br />
* emceeaich: Emma Humphries, (Bugmaster)<br />
* kmoir: Kim Moir, (Manager)<br />
<br />
The Low-level, security, and quality tools team contributes tooling, and development:<br />
<br />
* calixte: Calixte Denizet, (AutoNag)<br />
* marco: Marco Castelluccio, (BugBug)<br />
<br />
We also also have some volunteers, that we consider to be part of the B-Team as well:<br />
<br />
* seban: Sebastin Santy (long-term volunteer, past GSoC student)<br />
* atoll: Richard Solderberg (Reviewer-at-Large, slightly borrowed from Mozilla IT)<br />
* kohei: Kohei Yoshino, (UX Designer)<br />
* ''... and you can be one too!''<br />
<br />
There are also some people that still have some involvement with BMO,<br />
but their day-to-day attention is directed to other parts of Mozilla.<br />
<br />
* glob: Byron Jones<br />
* zeid: Zeid Zabaneh (Engineer)<br />
* mhentges: Mitchell Hentges (Engineer)<br />
<br />
Past contributors include:<br />
* mary: Mary Umoh (Intern, Summer 2017)<br />
* gerv: Gervase Markham<br />
* mcote: Mark C&ocirc;t&eacute;<br />
* dylan: Dylan Hardison<br />
* imadueme: Israel Madueme (Engineer)<br />
* justdave: Dave Miller<br />
<br />
= New Users =<br />
<br />
Getting used to Bugzilla can be a bit daunting. We have a short [https://gerv.makes.org/popcorn/1bn6 introductory video] available that is as gentle as possible. You may also be interested in the [[https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla MDN section about Bugzilla]], which contains information more suitable as an introduction to a general audience. Of special interest is the MDN article, [https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla What to do and what not to do in Bugzilla], which contains instructions on getting elevated privileges.<br />
<br />
= New Bots =<br />
<br />
If you have a bot that uses BMO, be sure to add it to the [[BMO/Bot Registry]]<br />
so we know who to contact about it!<br />
<br />
= User Guide =<br />
<br />
We're putting together a [[BMO/UserGuide|user guide]] with helpful information on various aspects of Bugzilla. New and experienced users alike should benefit from it. There's a lot to go through, so please feel free to contribute!<br />
<br />
= Road Map =<br />
<br />
We keep a yearly [[BMO/Road Map|road map]] with our medium-term plans (1-2 years), at a high level. Also see our [[BMO#Current_Projects|current projects]] for some of the big items we are working on in the current quarter.<br />
<br />
= Browser Support For BMO =<br />
<br />
Full Support includes: The current versions of Firefox, Chrome, Chromium, Safari, WebKit, and Edge; and the latest Firefox ESR.<br />
<br />
Limited Support includes: The previous versions of Firefox, Chrome, Chromium, Safari, WebKit, Edge, and Firefox ESR; and Firefox Nightly.<br />
<br />
Internet Explorer is no longer supported, though some features may still work with IE 11.<br />
<br />
See {{bug|1359310}} and {{bug|1422435}}.<br />
<br />
== JavaScript and Analytics ==<br />
<br />
JavaScript is required to use bugzilla.mozilla.org. <br />
<br />
The <code>Do Not Track</code> header sent by your browser is honored.<br />
<br />
= Third-Party Applications =<br />
<br />
Lots and lots of web apps and general tools have been written to interface with BMO. We have started [[BMO/ThirdPartyApps|cataloguing them]]. If you're looking for different ways to interface with BMO, check it out; similarly, if you are thinking about writing an app, check the catalogue to see if something similar exists that you could use, contribute to, or fork before setting out on your own.<br />
<br />
There's one in particular that is particularly important: [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Phabricator], Mozilla's new and growing code-review tool.<br />
<br />
= More Information about BMO =<br />
<br />
Our discussion forum is mozilla.tools.bmo [[https://lists.mozilla.org/listinfo/tools-bmo mailing list]] [[https://groups.google.com/forum/#!forum/mozilla.tools.bmo Google Group]] [[news://news.mozilla.org:119/mozilla.tools.bmo USENET]].<br />
<br />
We also have answers to [[BMO/FAQ|Frequently Asked Questions]] and a slightly-but-not-too-out-of-date [http://people.mozilla.org/~justdave/BugzillaPhysicalDiagram-rev110504.png hardware diagram].<br />
<br />
If you're building an application or tool that interfaces with BMO, you may be interested in the following:<br />
<br />
* [[BMO/Integration_Best_Practice|Best practices and etiquette]] for integrating external apps with BMO<br />
* Info and plans on Bugzilla's [[Bugzilla:REST_API|REST API]], and the older, deprecated [[Bugzilla:BzAPI|BzAPI]].<br />
<br />
Looking for another way to access Bugzilla's raw data? Try the [[BMO/ElasticSearch|ElasticSearch cluster]].<br />
<br />
= Contributing to BMO =<br />
<br />
If you'd like to help out with BMO specifically (as opposed to the general upstream [[Bugzilla|Bugzilla project]]), you can find us in [irc://irc.mozilla.org/bmo #bmo] on irc.mozilla.org. If you plan on contributing patches, see the documentation in the [https://github.com/mozilla-bteam/bmo/blob/master/README.rst README.rst]. You can file bugs under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org bugzilla.mozilla.org product]. Don't file them under the Bugzilla product unless you are sure it's a bug in the general Bugzilla product. In particular, all administrative changes should be filed under bugzilla.mozilla.org (see below for more).<br />
<br />
= Policies and Procedures =<br />
<br />
<br />
== Code Updates ==<br />
<br />
Code updates are normally deployed to bugzilla.mozilla.org late Monday/early Tuesday, US/Pacific time, at no specific time, if changes need to be pushed out. Security fixes or other fatal type errors will always go out as soon as possible.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent Changes]] page. <br />
<br />
== Administrative Changes ==<br />
<br />
If you need changes to BMO's configuration to support your team, project, etc., please consult this page before filing bugs:<br />
<br />
* [[BMO/Requesting Changes|General information on requesting Changes to BMO]]<br />
<br />
== BMO Administrative Processes ==<br />
<br />
* [[BMO/new-product|Adding a new product]]<br />
* [[BMO/new-version|Adding a new "rapid release" version]]<br />
* [[BMO/new-security-group|Adding a new BMO security group]]<br />
* [[BMO/RetiringComponents|Retiring Products and Components]]: moving things to the Graveyard classification.<br />
* [[BMO/RestoringDisabledAccounts|Restoring Disabled Accounts]]<br />
* [[BMO/MergingAccounts|Merging Accounts]]<br />
* [[BMO/DisablingAccounts|Disabling Accounts]]<br />
<br />
See also [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=45845955 BMO on Mana] (requires LDAP).<br />
<br />
== BMO Development and Other Processes ==<br />
<br />
* [[BMO/Development Processes|Overall Development Processes]]<br />
<br />
* [[BMO/OutagePlanning|Planning a BMO outage]]<br />
* [[BMO/ResetDevelopmentBranch|Reset the development branch to master]]<br />
* [[BMO/Perl Dependencies|Maintaining Perl Dependencies for BMO]]<br />
<br />
== Custom Bug Entry Forms ==<br />
<br />
In the past, BMO developers supported writing custom bug entry forms specific for the needs of different projects and groups within Mozilla. In order to focus more on other important features, we will no longer be providing that support going forward. For more information on why this change was made, see [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/tp4dSwUfKSA here].<br />
<br />
There is a new [https://github.com/mozilla-bteam/custom-form-example custom form framework] being developed by an outside contributor named Sebastin Santy. It is still in the early stages but it eventually will be very useful for users who want to create a customized bug entry form that can be used to submit bugs to BMO.<br />
<br />
= Current Projects =<br />
<br />
This table lists the bugs representing the current quarterly goals (and, near the end of the quarter, sometimes next quarter's goals). Those that were set at the beginning of the quarter are tagged with the keyword "bmo-goal". The BMO team also regularly gets requests for high-priority work items throughout the quarter; those that will take more than a day or two in total, thus potentially jeopardizing other goals, are included below, tagged with "bmo-big". The daily smaller tasks are also generally tracked in Bugzilla but not represented in the table below.<br />
<br />
P1 indicates a critical project. P2 indicates an important but deferrable item. P3 is as P2 but more deferrable. Note that all items are important, and it is presumed that lower-priority items will increase in priority over time as high-priority tasks are completed, i.e., we don't plan to defer any of these tasks indefinitely.<br />
<br />
== Goals ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-goal",<br />
"keywords_type": "anywords",<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2018-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== High-Priority ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck",<br />
"keywords_type": "nowords",<br />
"priority": ["P1"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== Upcoming ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck",<br />
"keywords_type": "anywords",<br />
"priority": ["--","P1","P2","P3","P4","P5"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
Further documentation about goals above and other projects follows:<br />
<br />
* [[BMO/UserRoles|User Roles]]<br />
** Generate different user roles based on what tasks a user is trying to complete when using the BMO system.<br />
<br />
== Past Projects ==<br />
<br />
Some of these will have on-going maintenance and improvements, but the initial deployment has been accomplished. Others have been abandoned or rejected due to various factors, noted below.<br />
<br />
* [[BMO/ChangeNotificationSystem|Change Notification System]]<br />
* [[BMO/40Upgrade|4.0 Upgrade]]<br />
* [[BMO/42Upgrade|4.2 Upgrade]] (Completed March 5th, 2013)<br />
* [[BMO/UserProfiles|User Profiles]]<br />
* [[BMO/TrackingFlags|Tracking Flags]]<br />
* [[Bugzilla:REST_API|Native REST API]]<br />
* [[BMO/Pulse|Pulse Integration]]<br />
** This was completed and deployed, but it generated a lot of traffic and is of questionable utility since it must access Bugzilla as an anonymous user. A simpler, more general system is the [[BMO/ChangeNotificationSystem|Change Notification System]].<br />
* [[Bugzilla:Migrating_to_git|Migrating Bugzilla and BMO code from bzr to git]]<br />
** Completed 2014/03/11.<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO&diff=1223920BMO2020-02-18T22:22:55Z<p>Emceeaich: /* B-Team */ update contributor list</p>
<hr />
<div>This is the main public page for all things related to https://bugzilla.mozilla.org, aka BMO, Mozilla's customized version of [http://www.bugzilla.org Bugzilla]. <br />
<br />
BMO is a core piece of infrastructure at Mozilla. It is used to track not only bugs and feature requests but also many other tasks across various teams.<br />
<br />
The BMO source is a slightly modified fork of Bugzilla with many custom extensions. It is currently based on Bugzilla 4.2 but with many features backported from 4.4 and master. All the BMO devs are also involved in the Bugzilla project, and we contribute features and fixes upstream where they are generally applicable, that is, not too specific to Mozilla's particular needs.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent_Changes|Recent Changes]] page.<br />
<br />
= B-Team =<br />
<br />
The team that works on BMO is called the B-Team, because of past affiliation with the defunct Automation and Tools team (A-Team).<br />
<br />
* dkl: Dave Lawrence (Owner/Engineer)<br />
* emceeaich: Emma Humphries, (Bugmaster)<br />
* kmoir: Kim Moir, (Manager)<br />
<br />
The Low-level, security, and quality tools team contributes tooling, and development:<br />
<br />
* calixte: Calixte Denizet, (AutoNag)<br />
* marco: Marco Castelluccio, (BugBug)<br />
<br />
We also also have some volunteers, that we consider to be part of the B-Team as well:<br />
<br />
* seban: Sebastin Santy (long-term volunteer, past GSoC student)<br />
* atoll: Richard Solderberg (Reviewer-at-Large, slightly borrowed from Mozilla IT)<br />
* kohei: Kohei Yoshino, (UX Designer)<br />
* ''... and you can be one too!''<br />
<br />
There are also some people that still have some involvement with BMO,<br />
but their day-to-day attention is directed to other parts of Mozilla.<br />
<br />
* glob: Byron Jones<br />
* zeid: Zeid Zabaneh (Engineer)<br />
* mhentges: Mitchell Hentges (Engineer)<br />
<br />
Past contributors include:<br />
* mary: Mary Umoh (Intern, Summer 2017)<br />
* gerv: Gervase Markham<br />
* mcote: Mark C&ocirc;t&eacute;<br />
* dylan: Dylan Hardison<br />
* imadueme: Israel Madueme (Engineer)<br />
* justdave: Dave Miller<br />
<br />
= New Users =<br />
<br />
Getting used to Bugzilla can be a bit daunting. We have a short [https://gerv.makes.org/popcorn/1bn6 introductory video] available that is as gentle as possible. You may also be interested in the [[https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla MDN section about Bugzilla]], which contains information more suitable as an introduction to a general audience. Of special interest is the MDN article, [https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla What to do and what not to do in Bugzilla], which contains instructions on getting elevated privileges.<br />
<br />
= New Bots =<br />
<br />
If you have a bot that uses BMO, be sure to add it to the [[BMO/Bot Registry]]<br />
so we know who to contact about it!<br />
<br />
= User Guide =<br />
<br />
We're putting together a [[BMO/UserGuide|user guide]] with helpful information on various aspects of Bugzilla. New and experienced users alike should benefit from it. There's a lot to go through, so please feel free to contribute!<br />
<br />
= Road Map =<br />
<br />
We keep a yearly [[BMO/Road Map|road map]] with our medium-term plans (1-2 years), at a high level. Also see our [[BMO#Current_Projects|current projects]] for some of the big items we are working on in the current quarter.<br />
<br />
= Browser Support For BMO =<br />
<br />
Full Support includes: The current versions of Firefox, Chrome, Chromium, Safari, WebKit, and Edge; and the latest Firefox ESR.<br />
<br />
Limited Support includes: The previous versions of Firefox, Chrome, Chromium, Safari, WebKit, Edge, and Firefox ESR; and Firefox Nightly.<br />
<br />
Internet Explorer is no longer supported, though some features may still work with IE 11.<br />
<br />
See {{bug|1359310}} and {{bug|1422435}}.<br />
<br />
== JavaScript and Analytics ==<br />
<br />
JavaScript is required to use bugzilla.mozilla.org. <br />
<br />
The <code>Do Not Track</code> header sent by your browser is honored.<br />
<br />
= Third-Party Applications =<br />
<br />
Lots and lots of web apps and general tools have been written to interface with BMO. We have started [[BMO/ThirdPartyApps|cataloguing them]]. If you're looking for different ways to interface with BMO, check it out; similarly, if you are thinking about writing an app, check the catalogue to see if something similar exists that you could use, contribute to, or fork before setting out on your own.<br />
<br />
There's one in particular that is particularly important: [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Phabricator], Mozilla's new and growing code-review tool.<br />
<br />
= More Information about BMO =<br />
<br />
Our discussion forum is mozilla.tools.bmo [[https://lists.mozilla.org/listinfo/tools-bmo mailing list]] [[https://groups.google.com/forum/#!forum/mozilla.tools.bmo Google Group]] [[news://news.mozilla.org:119/mozilla.tools.bmo USENET]].<br />
<br />
We also have answers to [[BMO/FAQ|Frequently Asked Questions]] and a slightly-but-not-too-out-of-date [http://people.mozilla.org/~justdave/BugzillaPhysicalDiagram-rev110504.png hardware diagram].<br />
<br />
If you're building an application or tool that interfaces with BMO, you may be interested in the following:<br />
<br />
* [[BMO/Integration_Best_Practice|Best practices and etiquette]] for integrating external apps with BMO<br />
* Info and plans on Bugzilla's [[Bugzilla:REST_API|REST API]], and the older, deprecated [[Bugzilla:BzAPI|BzAPI]].<br />
<br />
Looking for another way to access Bugzilla's raw data? Try the [[BMO/ElasticSearch|ElasticSearch cluster]].<br />
<br />
= Contributing to BMO =<br />
<br />
If you'd like to help out with BMO specifically (as opposed to the general upstream [[Bugzilla|Bugzilla project]]), you can find us in [irc://irc.mozilla.org/bmo #bmo] on irc.mozilla.org. If you plan on contributing patches, see the documentation in the [https://github.com/mozilla-bteam/bmo/blob/master/README.rst README.rst]. You can file bugs under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org bugzilla.mozilla.org product]. Don't file them under the Bugzilla product unless you are sure it's a bug in the general Bugzilla product. In particular, all administrative changes should be filed under bugzilla.mozilla.org (see below for more).<br />
<br />
= Policies and Procedures =<br />
<br />
<br />
== Code Updates ==<br />
<br />
Code updates are normally deployed to bugzilla.mozilla.org late Monday/early Tuesday, US/Pacific time, at no specific time, if changes need to be pushed out. Security fixes or other fatal type errors will always go out as soon as possible.<br />
<br />
Updates are usually deployed on a weekly basis and are listed on the [[BMO/Recent Changes]] page. <br />
<br />
== Administrative Changes ==<br />
<br />
If you need changes to BMO's configuration to support your team, project, etc., please consult this page before filing bugs:<br />
<br />
* [[BMO/Requesting Changes|General information on requesting Changes to BMO]]<br />
<br />
== BMO Administrative Processes ==<br />
<br />
* [[BMO/new-product|Adding a new product]]<br />
* [[BMO/new-version|Adding a new "rapid release" version]]<br />
* [[BMO/new-security-group|Adding a new BMO security group]]<br />
* [[BMO/RetiringComponents|Retiring Products and Components]]: moving things to the Graveyard classification.<br />
* [[BMO/RestoringDisabledAccounts|Restoring Disabled Accounts]]<br />
* [[BMO/MergingAccounts|Merging Accounts]]<br />
* [[BMO/DisablingAccounts|Disabling Accounts]]<br />
<br />
See also [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=45845955 BMO on Mana] (requires LDAP).<br />
<br />
== BMO Development and Other Processes ==<br />
<br />
* [[BMO/Development Processes|Overall Development Processes]]<br />
<br />
* [[BMO/OutagePlanning|Planning a BMO outage]]<br />
* [[BMO/ResetDevelopmentBranch|Reset the development branch to master]]<br />
* [[BMO/Perl Dependencies|Maintaining Perl Dependencies for BMO]]<br />
<br />
== Custom Bug Entry Forms ==<br />
<br />
In the past, BMO developers supported writing custom bug entry forms specific for the needs of different projects and groups within Mozilla. In order to focus more on other important features, we will no longer be providing that support going forward. For more information on why this change was made, see [https://groups.google.com/forum/#!topic/mozilla.tools.bmo/tp4dSwUfKSA here].<br />
<br />
There is a new [https://github.com/mozilla-bteam/custom-form-example custom form framework] being developed by an outside contributor named Sebastin Santy. It is still in the early stages but it eventually will be very useful for users who want to create a customized bug entry form that can be used to submit bugs to BMO.<br />
<br />
= Current Projects =<br />
<br />
This table lists the bugs representing the current quarterly goals (and, near the end of the quarter, sometimes next quarter's goals). Those that were set at the beginning of the quarter are tagged with the keyword "bmo-goal". The BMO team also regularly gets requests for high-priority work items throughout the quarter; those that will take more than a day or two in total, thus potentially jeopardizing other goals, are included below, tagged with "bmo-big". The daily smaller tasks are also generally tracked in Bugzilla but not represented in the table below.<br />
<br />
P1 indicates a critical project. P2 indicates an important but deferrable item. P3 is as P2 but more deferrable. Note that all items are important, and it is presumed that lower-priority items will increase in priority over time as high-priority tasks are completed, i.e., we don't plan to defer any of these tasks indefinitely.<br />
<br />
== Goals ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-goal",<br />
"keywords_type": "anywords",<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2018-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== High-Priority ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-big",<br />
"keywords_type": "anywords",<br />
"priority": ["P1","P2","P3","P4","P5"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
== Upcoming ==<br />
<br />
<div><br />
<bugzilla><br />
{<br />
"keywords": "bmo-on-deck",<br />
"keywords_type": "anywords",<br />
"priority": ["--","P1","P2","P3","P4","P5"],<br />
"include_fields": "id, priority, summary, status, resolution, assigned_to",<br />
"field0-0-0": "status",<br />
"type0-0-0": "equals",<br />
"value0-0-0": "NEW",<br />
"field0-0-1": "status",<br />
"type0-0-1": "equals",<br />
"value0-0-1": "ASSIGNED",<br />
"field0-0-2": "status",<br />
"type0-0-2": "changed_after",<br />
"value0-0-2": "2017-01-01"<br />
}<br />
</bugzilla><br />
</div><br />
<br />
Further documentation about goals above and other projects follows:<br />
<br />
* [[BMO/UserRoles|User Roles]]<br />
** Generate different user roles based on what tasks a user is trying to complete when using the BMO system.<br />
<br />
== Past Projects ==<br />
<br />
Some of these will have on-going maintenance and improvements, but the initial deployment has been accomplished. Others have been abandoned or rejected due to various factors, noted below.<br />
<br />
* [[BMO/ChangeNotificationSystem|Change Notification System]]<br />
* [[BMO/40Upgrade|4.0 Upgrade]]<br />
* [[BMO/42Upgrade|4.2 Upgrade]] (Completed March 5th, 2013)<br />
* [[BMO/UserProfiles|User Profiles]]<br />
* [[BMO/TrackingFlags|Tracking Flags]]<br />
* [[Bugzilla:REST_API|Native REST API]]<br />
* [[BMO/Pulse|Pulse Integration]]<br />
** This was completed and deployed, but it generated a lot of traffic and is of questionable utility since it must access Bugzilla as an anonymous user. A simpler, more general system is the [[BMO/ChangeNotificationSystem|Change Notification System]].<br />
* [[Bugzilla:Migrating_to_git|Migrating Bugzilla and BMO code from bzr to git]]<br />
** Completed 2014/03/11.<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/Bot_Registry&diff=1223829BMO/Bot Registry2020-02-14T20:30:25Z<p>Emceeaich: /* Bot List */ update hlundberg</p>
<hr />
<div>Some times you want a BMO account that is not a real person.<br />
That's okay -- in fact it is a good security measure!<br />
<br />
However this comes with some problems -- if we (the bmo admins) can't tell who owns a bot,<br />
and we have to make a decision that might break we have no way of informing the owner except<br />
to break it and wait to hear back. This list below is by no means mandatory, but if you fill it out,<br />
we can help avoid future breakages!<br />
<br />
If you include a link to the repo, things can be even smoother.<br />
<br />
If your bot misbehaves, we can tell you about it rather than just blocking it. <br />
<br />
== Bot Requirements ==<br />
<br />
All bot and automation users:<br />
<br />
* '''must''' have a `bots.tld` bugmail by 2020-06-30<br />
* '''must''' use the REST api by 2020-06-30<br />
* if they have elevated privileges must use a API key by 2020-06-30<br />
* '''should''' be listed in this registry ''unless'' there is a business reason not to list them publicly<br />
* when they modify bugs, they '''should''' leave a comment that the bug has been modified by a bot unless it does not make sense to<br />
<br />
== Bot List ==<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Bot Bugmail !! Owner Bugmail !! API (xmlrpc, jsonrpc, bzapi, or rest) !! Token or API Key!! Repo<br />
|-<br />
| pulsebot@bots.tld || mh+mozilla@glandium.org || rest || api-key || https://github.com/glandium/pulsebot/<br />
|-<br />
| treeherderbugbot@gmail.com || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || xmlrpc || Username/password || [https://github.com/github/github-services/blob/master/lib/services/bugzilla.rb GitHub's Bugzilla integration]<br />
|-<br />
| intermittent-bug-filer@mozilla.bugs || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || rest || api-key || https://github.com/mozilla/treeherder<br />
|-<br />
| orangefactor@bots.tld || auto-tools@moco || rest || api-key || https://hg.mozilla.org/automation/orangefactor/<br />
|-<br />
| webops-kanban@mozilla.bugs || atoll || Unknown || Token || <br />
|-<br />
| mozilla+bugcloser@davedash.com || Unknown || Unknown || Token (github) || Unknown<br />
|-<br />
| release-mgmt-account-bot@mozilla.tld || cdenizet@mozilla.com || rest || api-key || https://github.com/mozilla/relman-auto-nag/<br />
|-<br />
| slaveapi@mozilla.releng.tld || release@mozilla.com || Unknown || Unknown || https://github.com/mozilla/build-slaveapi<br />
|-<br />
| flow2bugs@netops.bugs || unknown || Unknown || Unknown || Unknown<br />
|- <br />
| webcompat-bugs@mozilla.bugs || miket@mozilla.com || rest || api-key || TBD<br />
|-<br />
| pulgasaur@mozilla.bugs || peterbe@mozilla.com || rest || api-key || https://github.com/mozilla/github-bugzilla-pr-linker<br />
|-<br />
| moc-queue-bot@mozilla.bugs || moc@mozilla.com || rest || api-key || git-internal/puppet/modules/moc_bug_queuemon<br />
|-<br />
| omphalos@mozilla.bugs || mgoodwin@mozilla.com || rest || api-key || https://github.com/mozilla/OneCRL-Tools<br />
|-<br />
| bug-husbandry-bot@mozilla.bugs || ehumphries@moco || rest || api-key || [[Bugmasters/Projects/Bug_Handling/Bug_Husbandry]]<br />
|-<br />
| reviewbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/code-review<br />
|-<br />
| upliftbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/release-services/tree/master/src/uplift/bot<br />
|-<br />
| wptsync@mozilla.bugs || jgraham@mozilla.com || rest || api-key || https://github.com/mozilla/wpt-sync<br />
|-<br />
| release+phabricator@mozilla.com || sfraser@mozilla.com || rest || api-key || Unknown / Phabricator use<br />
|-<br />
| foxsec-pytest@mozilla.com || abahnken@mozilla.com || rest; xmlrpc || api-key || https://github.com/mozilla-services/pytest-services<br />
|-<br />
| experimenter@mozilla.com || jbuckley@mozilla.com || rest || api-key || https://github.com/mozilla/experimenter<br />
|-<br />
| bugmail@firebot.glob.uno || glob@mozilla.com || rest || anon || https://github.com/globau/firebot<br />
|-<br />
| bteam-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard<br />
|-<br />
| conduit-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard/tree/conduit<br />
|- <br />
| jitbugs@mozilla.bugs || mgaudet@mozilla.com || n/a || n/a || Watchable Account for JavaScript JIT Bug Reviews<br />
|-<br />
| relops-bug-generator@mozilla.com || jwatkins@mozilla.com || n/a || n/a || Automated Bug Generation for RelOps<br />
|-<br />
| mozilla-apprentice@mcc.id.au || cam@mcc.id.au || rest || api-key || https://github.com/heycam/wg-tracker<br />
|-<br />
| security-baseline@bots.tld || sbennetts@mozilla.com || rest || api-key || https://github.com/mozilla-services/foxsec<br />
|-<br />
| hlundberg@bots.tld || sstruble@moco || rest || api-key || n/a<br />
|}</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/Bot_Registry&diff=1223828BMO/Bot Registry2020-02-14T20:29:35Z<p>Emceeaich: Add requirements section</p>
<hr />
<div>Some times you want a BMO account that is not a real person.<br />
That's okay -- in fact it is a good security measure!<br />
<br />
However this comes with some problems -- if we (the bmo admins) can't tell who owns a bot,<br />
and we have to make a decision that might break we have no way of informing the owner except<br />
to break it and wait to hear back. This list below is by no means mandatory, but if you fill it out,<br />
we can help avoid future breakages!<br />
<br />
If you include a link to the repo, things can be even smoother.<br />
<br />
If your bot misbehaves, we can tell you about it rather than just blocking it. <br />
<br />
== Bot Requirements ==<br />
<br />
All bot and automation users:<br />
<br />
* '''must''' have a `bots.tld` bugmail by 2020-06-30<br />
* '''must''' use the REST api by 2020-06-30<br />
* if they have elevated privileges must use a API key by 2020-06-30<br />
* '''should''' be listed in this registry ''unless'' there is a business reason not to list them publicly<br />
* when they modify bugs, they '''should''' leave a comment that the bug has been modified by a bot unless it does not make sense to<br />
<br />
== Bot List ==<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Bot Bugmail !! Owner Bugmail !! API (xmlrpc, jsonrpc, bzapi, or rest) !! Token or API Key!! Repo<br />
|-<br />
| pulsebot@bots.tld || mh+mozilla@glandium.org || rest || api-key || https://github.com/glandium/pulsebot/<br />
|-<br />
| treeherderbugbot@gmail.com || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || xmlrpc || Username/password || [https://github.com/github/github-services/blob/master/lib/services/bugzilla.rb GitHub's Bugzilla integration]<br />
|-<br />
| intermittent-bug-filer@mozilla.bugs || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || rest || api-key || https://github.com/mozilla/treeherder<br />
|-<br />
| orangefactor@bots.tld || auto-tools@moco || rest || api-key || https://hg.mozilla.org/automation/orangefactor/<br />
|-<br />
| webops-kanban@mozilla.bugs || atoll || Unknown || Token || <br />
|-<br />
| mozilla+bugcloser@davedash.com || Unknown || Unknown || Token (github) || Unknown<br />
|-<br />
| release-mgmt-account-bot@mozilla.tld || cdenizet@mozilla.com || rest || api-key || https://github.com/mozilla/relman-auto-nag/<br />
|-<br />
| slaveapi@mozilla.releng.tld || release@mozilla.com || Unknown || Unknown || https://github.com/mozilla/build-slaveapi<br />
|-<br />
| flow2bugs@netops.bugs || unknown || Unknown || Unknown || Unknown<br />
|- <br />
| webcompat-bugs@mozilla.bugs || miket@mozilla.com || rest || api-key || TBD<br />
|-<br />
| pulgasaur@mozilla.bugs || peterbe@mozilla.com || rest || api-key || https://github.com/mozilla/github-bugzilla-pr-linker<br />
|-<br />
| moc-queue-bot@mozilla.bugs || moc@mozilla.com || rest || api-key || git-internal/puppet/modules/moc_bug_queuemon<br />
|-<br />
| omphalos@mozilla.bugs || mgoodwin@mozilla.com || rest || api-key || https://github.com/mozilla/OneCRL-Tools<br />
|-<br />
| bug-husbandry-bot@mozilla.bugs || ehumphries@moco || rest || api-key || [[Bugmasters/Projects/Bug_Handling/Bug_Husbandry]]<br />
|-<br />
| reviewbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/code-review<br />
|-<br />
| upliftbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/release-services/tree/master/src/uplift/bot<br />
|-<br />
| wptsync@mozilla.bugs || jgraham@mozilla.com || rest || api-key || https://github.com/mozilla/wpt-sync<br />
|-<br />
| release+phabricator@mozilla.com || sfraser@mozilla.com || rest || api-key || Unknown / Phabricator use<br />
|-<br />
| foxsec-pytest@mozilla.com || abahnken@mozilla.com || rest; xmlrpc || api-key || https://github.com/mozilla-services/pytest-services<br />
|-<br />
| experimenter@mozilla.com || jbuckley@mozilla.com || rest || api-key || https://github.com/mozilla/experimenter<br />
|-<br />
| bugmail@firebot.glob.uno || glob@mozilla.com || rest || anon || https://github.com/globau/firebot<br />
|-<br />
| bteam-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard<br />
|-<br />
| conduit-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard/tree/conduit<br />
|- <br />
| jitbugs@mozilla.bugs || mgaudet@mozilla.com || n/a || n/a || Watchable Account for JavaScript JIT Bug Reviews<br />
|-<br />
| relops-bug-generator@mozilla.com || jwatkins@mozilla.com || n/a || n/a || Automated Bug Generation for RelOps<br />
|-<br />
| mozilla-apprentice@mcc.id.au || cam@mcc.id.au || rest || api-key || https://github.com/heycam/wg-tracker<br />
|-<br />
| security-baseline@bots.tld || sbennetts@mozilla.com || rest || api-key || https://github.com/mozilla-services/foxsec<br />
|-<br />
| hlundberg@bots.tld || sstruble@moco || rest || n/a || n/a<br />
|}</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/Bot_Registry&diff=1223758BMO/Bot Registry2020-02-13T17:33:27Z<p>Emceeaich: Add Haavard Lundberg research account</p>
<hr />
<div>Some times you want a BMO account that is not a real person.<br />
That's okay -- in fact it is a good security measure!<br />
<br />
However this comes with some problems -- if we (the bmo admins) can't tell who owns a bot,<br />
and we have to make a decision that might break we have no way of informing the owner except<br />
to break it and wait to hear back. This list below is by no means mandatory, but if you fill it out,<br />
we can help avoid future breakages!<br />
<br />
If you include a link to the repo, things can be even smoother.<br />
<br />
Additionally, if your bot misbehaves, we can tell you about it rather than just blocking it. <br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Bot Bugmail !! Owner Bugmail !! API (xmlrpc, jsonrpc, bzapi, or rest) !! Token or API Key!! Repo<br />
|-<br />
| pulsebot@bots.tld || mh+mozilla@glandium.org || rest || api-key || https://github.com/glandium/pulsebot/<br />
|-<br />
| treeherderbugbot@gmail.com || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || xmlrpc || Username/password || [https://github.com/github/github-services/blob/master/lib/services/bugzilla.rb GitHub's Bugzilla integration]<br />
|-<br />
| intermittent-bug-filer@mozilla.bugs || [https://lists.mozilla.org/listinfo/tools-treeherder tools-treeherder] || rest || api-key || https://github.com/mozilla/treeherder<br />
|-<br />
| orangefactor@bots.tld || auto-tools@moco || rest || api-key || https://hg.mozilla.org/automation/orangefactor/<br />
|-<br />
| webops-kanban@mozilla.bugs || atoll || Unknown || Token || <br />
|-<br />
| mozilla+bugcloser@davedash.com || Unknown || Unknown || Token (github) || Unknown<br />
|-<br />
| release-mgmt-account-bot@mozilla.tld || cdenizet@mozilla.com || rest || api-key || https://github.com/mozilla/relman-auto-nag/<br />
|-<br />
| slaveapi@mozilla.releng.tld || release@mozilla.com || Unknown || Unknown || https://github.com/mozilla/build-slaveapi<br />
|-<br />
| flow2bugs@netops.bugs || unknown || Unknown || Unknown || Unknown<br />
|- <br />
| webcompat-bugs@mozilla.bugs || miket@mozilla.com || rest || api-key || TBD<br />
|-<br />
| pulgasaur@mozilla.bugs || peterbe@mozilla.com || rest || api-key || https://github.com/mozilla/github-bugzilla-pr-linker<br />
|-<br />
| moc-queue-bot@mozilla.bugs || moc@mozilla.com || rest || api-key || git-internal/puppet/modules/moc_bug_queuemon<br />
|-<br />
| omphalos@mozilla.bugs || mgoodwin@mozilla.com || rest || api-key || https://github.com/mozilla/OneCRL-Tools<br />
|-<br />
| bug-husbandry-bot@mozilla.bugs || ehumphries@moco || rest || api-key || [[Bugmasters/Projects/Bug_Handling/Bug_Husbandry]]<br />
|-<br />
| reviewbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/code-review<br />
|-<br />
| upliftbot@mozilla.com || babadie@mozilla.com || rest || api-key; phabricator-token || https://github.com/mozilla/release-services/tree/master/src/uplift/bot<br />
|-<br />
| wptsync@mozilla.bugs || jgraham@mozilla.com || rest || api-key || https://github.com/mozilla/wpt-sync<br />
|-<br />
| release+phabricator@mozilla.com || sfraser@mozilla.com || rest || api-key || Unknown / Phabricator use<br />
|-<br />
| foxsec-pytest@mozilla.com || abahnken@mozilla.com || rest; xmlrpc || api-key || https://github.com/mozilla-services/pytest-services<br />
|-<br />
| experimenter@mozilla.com || jbuckley@mozilla.com || rest || api-key || https://github.com/mozilla/experimenter<br />
|-<br />
| bugmail@firebot.glob.uno || glob@mozilla.com || rest || anon || https://github.com/globau/firebot<br />
|-<br />
| bteam-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard<br />
|-<br />
| conduit-dashboard@bmo.tld || glob@mozilla.com || rest || api-key || https://github.com/globau/bteam-dashboard/tree/conduit<br />
|- <br />
| jitbugs@mozilla.bugs || mgaudet@mozilla.com || n/a || n/a || Watchable Account for JavaScript JIT Bug Reviews<br />
|-<br />
| relops-bug-generator@mozilla.com || jwatkins@mozilla.com || n/a || n/a || Automated Bug Generation for RelOps<br />
|-<br />
| mozilla-apprentice@mcc.id.au || cam@mcc.id.au || rest || api-key || https://github.com/heycam/wg-tracker<br />
|-<br />
| security-baseline@bots.tld || sbennetts@mozilla.com || rest || api-key || https://github.com/mozilla-services/foxsec<br />
|-<br />
| hlundberg@bots.tld || sstruble@moco || rest || n/a || n/a<br />
|}</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide&diff=1220339BMO/UserGuide2019-11-15T23:40:12Z<p>Emceeaich: /* Comment Tagging */ add comment editing, link tagging</p>
<hr />
<div>[[File:Bmo-introduction-video.png|thumb|Understanding Mozilla: Bugzilla|link=https://gerv.makes.org/popcorn/1bn6]]<br />
<br />
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.<br />
<br />
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!<br />
<br />
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!<br />
<br />
= BMO vs Bugzilla =<br />
<br />
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.<br />
<br />
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]].<br />
<br />
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].<br />
<br />
=Creating a Bugzilla Account=<br />
<br />
To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.<br />
<br />
==Create a Local Account==<br />
<br />
From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.<br />
<br />
==Log in With GitHub==<br />
<br />
If you have a GitHub account you can use it to log in and create an account.<br />
<br />
* First click "Log in".<br />
* Then click the Octocat/GitHub logo. <br />
* If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.<br />
* If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.<br />
* You'll be identified by the email address you use on GitHub.<br />
<br />
'''Note:''' If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.<br />
<br />
= Searching =<br />
''Omg, so many ways to search; why do we have so many, and how do they work?''<br />
<br />
== Quick Search ==<br />
''Quick Search rocks! You should use it.''<br />
<br />
== Advanced Search, Pronouns ==<br />
''Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.''<br />
<br />
== Other Searches (Instant, Simple, Google) ==<br />
''In case you were looking for more ways to search.''<br />
<br />
= Bugmail =<br />
<br />
''Bugmail'' is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.<br />
<br />
== Filtering ==<br />
''Too much bugmail? Filter on BMO itself and/or via x-headers!''<br />
<br />
=== Filtering with GMail ===<br />
GMail's ability to filter on headers is somewhat limited. We've got a separate, complete [[/Filtering Bugzilla Email in GMail|guide]] on advanced bugmail filtering with GMail.<br />
<br />
= Users =<br />
<br />
Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.<br />
<br />
== User Profiles ==<br />
<br />
By selecting [https://bugzilla.mozilla.org/user_profile My Profile] from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.<br />
<br />
There's a [[BMO/UserProfiles|project page]] about User Profiles which has brief description of the fields.<br />
<br />
== "New to Bugzilla" ==<br />
<br />
A user's comments will be tagged as "New to Bugzilla" under the following conditions:<br />
* The user does ''not'' have editbugs access.<br />
* The user has made 25 comments or less '''OR''' the account is less than 60 days old.<br />
<br />
The "New to Bugzilla" indicator doesn't mean ''this account was created recently'', it's an indicator that ''this user hasn't used Bugzilla much, please tailor your responses accordingly''.<br />
<br />
This is only displayed to people with canconfirm or editbugs access.<br />
<br />
= Understanding, Editing, and Filing Bugs =<br />
<br />
== Standard Bug Fields ==<br />
Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described [[BMO/UserGuide/BugFields|here]].<br />
<br />
== Comment Tagging ==<br />
Want to convey some out-of-band information on a comment? Tag it. <br />
Want to auto-collapse a spammy, abusive, or obsolete comment? [[BMO/Comment_Tagging|Tag it]].<br />
<br />
== Comment Editing == <br />
<br />
Some users can edit comments made on bugs, if you do so, please follow [[BMO/Editing_Comments|our guidelines]].<br />
<br />
== Keywords and the Whiteboard ==<br />
''What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?''<br />
<br />
'''Keywords''':<br />
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.<br />
<br />
'''Whiteboard''':<br />
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.<br />
<br />
== Tracking Flags ==<br />
''Who's doing the tracking? Should i even set these flags?''<br />
<br />
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.<br />
<br />
[[File:Tracking-flag-example.png|thumb]]<br />
<br />
Tracking flags have the values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value !! Meaning<br />
|-<br />
| --- || Default/Not nominated<br />
|-<br />
| ? || Bug is nominated for this release<br />
|-<br />
| + || Bug is tracked for this release<br />
|-<br />
| - || Bug will not be tracked for this release<br />
|-<br />
| blocking || Bug is considered a blocker for this release<br />
|}<br />
<br />
Most users will only be able to [[Release_Management/Release_Process#All_about_Flags|nominate a bug for tracking]] by setting the tracking flag for a release to ''?''. The Release Drivers group (which includes Release Management) will respond to the request for tracking.<br />
<br />
For example, a [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_beta&o1=equals&v1=%2B search for tracking Firefox Beta and "+"] would list the bugs which release managers decided to track for the Beta release of Firefox. <br />
<br />
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.<br />
<br />
== Status Flags ==<br />
<br />
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]. <br />
<br />
[[File:Status-flag-example.png|Thumb]]<br />
<br />
== Project Flags == <br />
<br />
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.<br />
<br />
== Needinfo Flag ==<br />
''It's good and you should use it.''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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].<br />
<br />
= Other Ways to use BMO and its Data =<br />
<br />
== Whining ==<br />
''Bugzilla can automatically send you buglists (requires canconfirm).''<br />
<br />
BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to [https://bugzilla.mozilla.org/editwhines.cgi create whines].<br />
<br />
== APIs ==<br />
''I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.''<br />
<br />
BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found [http://bmo.readthedocs.io/en/latest/api/index.html here].<br />
<br />
== Dashboards ==<br />
''Trying to answer the "what should i do today" question? Go no further than the dashboards.''<br />
<br />
[https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard] has some nice options for viewing lists of bugs that may be of interest to you.<br />
<br />
=Permissions and Groups=<br />
<br />
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org. <br />
<br />
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive. <br />
<br />
==How to apply for upgraded permissions==<br />
<br />
If you want '''canconfirm''', you can add it yourself using [https://bugzilla.mozilla.org/page.cgi?id=triage_request.html triage request form].<br />
<br />
If you want '''editbugs''', [https://mzl.la/2izLT4J file a new bug, including]:<br />
<br />
* The URLs of two bugs to which you have attached patches or testcases.<br />
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.<br />
<br />
'''Note:''' '''editbugs''' implies '''canconfirm''' there's no need to apply for both.<br />
<br />
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group '''everyone'''. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.<br />
<br />
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/Editing_Comments&diff=1220337BMO/Editing Comments2019-11-15T23:34:22Z<p>Emceeaich: Emceeaich moved page Bmo/Editing Comments to BMO/Editing Comments: Typo</p>
<hr />
<div>== Editing Bugzilla comments: a guide ==<br />
<br />
=== Summary ===<br />
<br />
In 2019 we enabled comment editing on Bugzilla. <br />
<br />
If you are a member of the <code>editbugs</code> group, or a staff member, you’re able to edit your own comments. <br />
<br />
[[File:Comment-editing.png|frame|left|The location of the edit comment button on the comment tool bar (first on the left)]]<br />
<br />
There are a few Mozillians: the Bugzilla admins, security team members, and community managers who can edit any comment. That ability is there so that we can respond to comments that affect the safety, security, and privacy of others.<br />
<br />
With this ability, we expect you to use it considerately and wisely, regardless of if you can only edit your own comments or those of others.<br />
<br />
=== Guidelines ===<br />
<br />
'''''Do edit your own comments to fix typos and spelling'''''<br />
<br />
This is the main purpose of the comment editing feature.<br />
<br />
'''''Do not edit a comment to change its interpretation'''''<br />
<br />
Editing your own comment to change how a reader would interpret it, especially after another person added a comment is unacceptable and would be reviewed under our community participation guidelines (CPG.)<br />
<br />
Similarly, editing someone else’s comment to change how someone would react to it is also wrong and would prompt CPG review.<br />
<br />
Editing for clarification, or removing your own personally identifiable information or passwords and access keys is fine.<br />
<br />
'''''Do not edit to reverse your position or cover up mistakes'''''<br />
<br />
We are an organization that works in the open, covering up mistakes undermines the work of all Mozillians.<br />
<br />
'''''Do not edit other peoples’ typos and spelling'''''<br />
<br />
It’s weird and intrusive. If they have the ability to edit their own comments, let them fix it.<br />
<br />
=== Threats, abuse, and harmful content === <br />
<br />
If a comment contains something that would endanger the privacy, or security of another user, and if you can edit other peoples’ comments, do edit the comment (making sure hide edit history is enabled.)<br />
<br />
Example of this would be personally identifiable information (passwords, street addresses, government ID numbers, health insurance IDs, and so forth.)<br />
<br />
Don’t edit comments containing threats, abuse, or other violations of our [https://www.mozilla.org/about/governance/policies/participation/ Community Participation Guidelines], [[BMO/comment_tagging|tag them]].<br />
<br />
Tag the comment <code>abuse</code>. <br />
<br />
It will be hidden from other users and someone from the Bugzilla moderation team will respond.</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=Bmo/Editing_Comments&diff=1220338Bmo/Editing Comments2019-11-15T23:34:22Z<p>Emceeaich: Emceeaich moved page Bmo/Editing Comments to BMO/Editing Comments: Typo</p>
<hr />
<div>#REDIRECT [[BMO/Editing Comments]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/Editing_Comments&diff=1220336BMO/Editing Comments2019-11-15T23:16:52Z<p>Emceeaich: /* Summary */ add image of comment toolbar</p>
<hr />
<div>== Editing Bugzilla comments: a guide ==<br />
<br />
=== Summary ===<br />
<br />
In 2019 we enabled comment editing on Bugzilla. <br />
<br />
If you are a member of the <code>editbugs</code> group, or a staff member, you’re able to edit your own comments. <br />
<br />
[[File:Comment-editing.png|frame|left|The location of the edit comment button on the comment tool bar (first on the left)]]<br />
<br />
There are a few Mozillians: the Bugzilla admins, security team members, and community managers who can edit any comment. That ability is there so that we can respond to comments that affect the safety, security, and privacy of others.<br />
<br />
With this ability, we expect you to use it considerately and wisely, regardless of if you can only edit your own comments or those of others.<br />
<br />
=== Guidelines ===<br />
<br />
'''''Do edit your own comments to fix typos and spelling'''''<br />
<br />
This is the main purpose of the comment editing feature.<br />
<br />
'''''Do not edit a comment to change its interpretation'''''<br />
<br />
Editing your own comment to change how a reader would interpret it, especially after another person added a comment is unacceptable and would be reviewed under our community participation guidelines (CPG.)<br />
<br />
Similarly, editing someone else’s comment to change how someone would react to it is also wrong and would prompt CPG review.<br />
<br />
Editing for clarification, or removing your own personally identifiable information or passwords and access keys is fine.<br />
<br />
'''''Do not edit to reverse your position or cover up mistakes'''''<br />
<br />
We are an organization that works in the open, covering up mistakes undermines the work of all Mozillians.<br />
<br />
'''''Do not edit other peoples’ typos and spelling'''''<br />
<br />
It’s weird and intrusive. If they have the ability to edit their own comments, let them fix it.<br />
<br />
=== Threats, abuse, and harmful content === <br />
<br />
If a comment contains something that would endanger the privacy, or security of another user, and if you can edit other peoples’ comments, do edit the comment (making sure hide edit history is enabled.)<br />
<br />
Example of this would be personally identifiable information (passwords, street addresses, government ID numbers, health insurance IDs, and so forth.)<br />
<br />
Don’t edit comments containing threats, abuse, or other violations of our [https://www.mozilla.org/about/governance/policies/participation/ Community Participation Guidelines], [[BMO/comment_tagging|tag them]].<br />
<br />
Tag the comment <code>abuse</code>. <br />
<br />
It will be hidden from other users and someone from the Bugzilla moderation team will respond.</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=File:Comment-editing.png&diff=1220335File:Comment-editing.png2019-11-15T23:15:56Z<p>Emceeaich: </p>
<hr />
<div>Screenshot of comment toolbar in bugzilla: the first icon on the left is for editing a comment</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/Editing_Comments&diff=1220334BMO/Editing Comments2019-11-15T23:13:59Z<p>Emceeaich: /* Guidelines */ make section for threats and abuse</p>
<hr />
<div>== Editing Bugzilla comments: a guide ==<br />
<br />
=== Summary ===<br />
<br />
In 2019 we enabled comment editing on Bugzilla. <br />
<br />
If you are a member of the <code>editbugs</code> group, or a staff member, you’re able to edit your own comments. <br />
<br />
There are a few Mozillians: the Bugzilla admins, security team members, and community managers who can edit any comment. That ability is there so that we can respond to comments that affect the safety, security, and privacy of others.<br />
<br />
With this ability, we expect you to use it considerately and wisely, regardless of if you can only edit your own comments or those of others. <br />
<br />
=== Guidelines ===<br />
<br />
'''''Do edit your own comments to fix typos and spelling'''''<br />
<br />
This is the main purpose of the comment editing feature.<br />
<br />
'''''Do not edit a comment to change its interpretation'''''<br />
<br />
Editing your own comment to change how a reader would interpret it, especially after another person added a comment is unacceptable and would be reviewed under our community participation guidelines (CPG.)<br />
<br />
Similarly, editing someone else’s comment to change how someone would react to it is also wrong and would prompt CPG review.<br />
<br />
Editing for clarification, or removing your own personally identifiable information or passwords and access keys is fine.<br />
<br />
'''''Do not edit to reverse your position or cover up mistakes'''''<br />
<br />
We are an organization that works in the open, covering up mistakes undermines the work of all Mozillians.<br />
<br />
'''''Do not edit other peoples’ typos and spelling'''''<br />
<br />
It’s weird and intrusive. If they have the ability to edit their own comments, let them fix it.<br />
<br />
=== Threats, abuse, and harmful content === <br />
<br />
If a comment contains something that would endanger the privacy, or security of another user, and if you can edit other peoples’ comments, do edit the comment (making sure hide edit history is enabled.)<br />
<br />
Example of this would be personally identifiable information (passwords, street addresses, government ID numbers, health insurance IDs, and so forth.)<br />
<br />
Don’t edit comments containing threats, abuse, or other violations of our [https://www.mozilla.org/about/governance/policies/participation/ Community Participation Guidelines], [[BMO/comment_tagging|tag them]].<br />
<br />
Tag the comment <code>abuse</code>. <br />
<br />
It will be hidden from other users and someone from the Bugzilla moderation team will respond.</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/Editing_Comments&diff=1220333BMO/Editing Comments2019-11-15T23:11:52Z<p>Emceeaich: Initial page</p>
<hr />
<div>== Editing Bugzilla comments: a guide ==<br />
<br />
=== Summary ===<br />
<br />
In 2019 we enabled comment editing on Bugzilla. <br />
<br />
If you are a member of the <code>editbugs</code> group, or a staff member, you’re able to edit your own comments. <br />
<br />
There are a few Mozillians: the Bugzilla admins, security team members, and community managers who can edit any comment. That ability is there so that we can respond to comments that affect the safety, security, and privacy of others.<br />
<br />
With this ability, we expect you to use it considerately and wisely, regardless of if you can only edit your own comments or those of others. <br />
<br />
=== Guidelines ===<br />
<br />
'''''Do edit your own comments to fix typos and spelling'''''<br />
<br />
This is the main purpose of the comment editing feature.<br />
<br />
'''''Do not edit a comment to change its interpretation'''''<br />
<br />
Editing your own comment to change how a reader would interpret it, especially after another person added a comment is unacceptable and would be reviewed under our community participation guidelines (CPG.)<br />
<br />
Similarly, editing someone else’s comment to change how someone would react to it is also wrong and would prompt CPG review.<br />
<br />
Editing for clarification, or removing your own personally identifiable information or passwords and access keys is fine.<br />
<br />
'''''Do not edit to reverse your position or cover up mistakes'''''<br />
<br />
We are an organization that works in the open, covering up mistakes undermines the work of all Mozillians.<br />
<br />
'''''Do not edit other peoples’ typos and spelling'''''<br />
<br />
It’s weird and intrusive. If they have the ability to edit their own comments, let them fix it.<br />
<br />
If a comment contains something that would endanger the privacy, or security of another user, and if you can edit other peoples’ comments, do edit the comment (making sure hide edit history is enabled.)<br />
<br />
Example of this would be personally identifiable information (passwords, street addresses, government ID numbers, health insurance IDs, and so forth.)<br />
<br />
Don’t edit comments containing threats, abuse, or other violations of our [https://www.mozilla.org/about/governance/policies/participation/ Community Participation Guidelines], [[BMO/comment_tagging|tag them]].<br />
<br />
Tag the comment <code>abuse</code>. <br />
<br />
It will be hidden from other users and someone from the Bugzilla moderation team will respond.</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1219508Phabricator/FAQ2019-10-27T04:26:32Z<p>Emceeaich: /* Lando */ Remove disabled `checkin-needed` flag</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
The documentation is available on how to use it in the readthedocs Mozilla instance:<br />
https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html<br />
<br />
See https://wiki.mozilla.org/Phabricator/Bugzilla_Equivalents for how to perform common Bugzilla tasks in Phabricator.<br />
<br />
== Phabricator ==<br />
<br />
=== Why is my Phabricator revision showing up as "secure" or "in draft"? ===<br />
<br />
All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
There may be a short delay after submission before the revision is visible to other users.<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes. Only people who can see the Bugzilla bug will be able to see your revision.<br />
<br />
The visibility of the Phabricator revision is kept in sync with visibility changes to the bug. For example CC'ing someone to the bug will allow them to view the revision in Phabricator.<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in MozPhab or Arcanist:<br />
<code>Bug 123456 - Example commit description; r=someone!</code><br />
<br />
With MozPhab you can alternatively use the <code>--blocker</code> switch:<br />
<code>moz-phab submit --blocker someone</code><br />
<br />
To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use <code>arc amend</code> to update the commit message with the current state.<br />
<br />
Note using <code>moz-phab</code> instead of <code>arc</code> to submit changesets to Phabricator will avoid this issue.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to submit more updates for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box at the bottom of the page and make sure you hit "Submit".<br />
<br />
[[File:Closed revision actions.png|320px|Closed revision actions]]<br />
<br />
Note that you will need to run <code>arc diff</code> again to update the patch even if you don't need to change it (e.g. the bustage was in an earlier commit). This is because Phabricator updates the revision after it lands but does not provide the necessary metadata that Lando needs. See {{bug|1489126}}.<br />
<br />
See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I keep the original commit author when commandeering someone else's revision? ===<br />
<br />
Use <code>hg commit --amend --user "Other Person <person@mozilla.com>"</code> or <code>git commit --amend --author="Other Person <person@mozilla.com>"</code> when amending the original commit.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the <code>moz-phab patch</code> command to download an apply a diff (recommended)<br />
<br />
* Use the <code>arc patch</code> command to download and apply a diff<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
'''TIP''': Like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== Why don't we mirror review flags to Bugzilla? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard and can be misleading. There are no direct equivalents between Differential's review actions and state and Bugzilla's flags. Furthermore, the full state of a review is not exposed by Phabricator's Conduit API. See [https://groups.google.com/d/msg/mozilla.dev.platform/Aku1WPL5190/rBcGX3rkBwAJ this dev.platform post] for more information.<br />
<br />
We will be including some revision metadata in associated bugs at some point; see {{bug|1489706}}.<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
You can use [https://phabricator.services.mozilla.com/calendar/ Phabricator's calendar feature] to set your availability. This will result in a warning at submission time.<br />
<br />
=== Can I filter Phabricator mails in gmail? ===<br />
<br />
Yes, if you enable stamps in e-mail bodies. There's some examples in the [https://secure.phabricator.com/book/phabricator/article/mail_rules/#stamps-and-gmail upstream documentation].<br />
<br />
=== Why does logging into Phabricator require 2FA/MFA? ===<br />
<br />
Anyone using Phabricator is authoring patches, reviewing patches, and/or accessing confidential patches.<br />
<br />
MFA is a reasonable burden for these people given the importance of maintaining secure processes in the development of Firefox and other Mozilla applications. Given that Bugzilla is coupled to Phabricator, and a lot of important discussion around bugs and solutions also happens in Bugzilla, including confidential discussions, anyone involved in the above activities on Phabricator should also have equal protections when accessing Bugzilla.<br />
<br />
Users who use GitHub to log into Bugzilla will need to switch their login method to username+password by logging out, then following the "Forgot Password" workflow.<br />
<br />
=== My patch is too large for Phabricator; what are my options? ===<br />
<br />
Phabricator has a limit of 32MB on patches. If your patch exceed this size you should ''seriously'' consider splitting the patch into multiple commits (e.g. bumping versions of vendored rust crates one at a time rather an in a single commit). Your reviewers will thank you for this - massive patches are harder to review. Note if you use Lando to land your stack, each commit will land as part of the same push - you won't end up in a partially landed stack.<br />
<br />
If your patch makes small changes to multiple files, try submitting with the <code>--less-context</code> switch. Phabricator works by submitting the complete contents of each file modified; when touching many files it can be easy to exceed the 32MB limit. Note <code>--less-context</code> disables the ability to show more context when viewing a patch on Phabricator.<br />
<br />
=== How do I change my Phabricator email address? ===<br />
<br />
Instructions are [https://mana.mozilla.org/wiki/pages/viewpage.action?spaceKey=EW&title=Phabricator+-+Changing+your+email+address here].<br />
<br />
== Command-line tools: moz-phab and arc ==<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the <code>--allow-untracked</code> option to arc diff.<br />
<br />
=== How do I fetch and apply changes to a local repository? ===<br />
<br />
==== Using moz-phab (recommended) ====<br />
<br />
Use <code>moz-phab patch ''D<NNNNN>''</code> command to download and apply stacks of Phabricator revisions.<br />
<br />
Execute <code>moz-phab patch --help</code> for information on how to change patch's behaviour.<br />
<br />
==== Using arc ====<br />
<br />
Provided all dependent revisions have been submitted to Phabricator and not<br />
replaced with updated diffs, the "Related Revisions" have been set up<br />
correctly, and the first revision in the related revision chain has a parent<br />
commit hash corresponding to a base revision existing in the local mercurial<br />
repository, <code>arc patch --revision ''D<NNNNN>''</code> should apply the series to the<br />
appropriate base revision.<br />
<br />
The process is more complicated for retrieving any diffs from revisions that<br />
now have more recent diffs in the related revision chain:<br />
<br />
# The "History" tab for a revision has a list of diff IDs. Identify the diff ID for the diff that is wanted. The creation date may be useful.<br />
# Look through the history of the revision to find changes to the parent revision and guess which was the parent revision at the time the diff was generated from a commit. Changes to parent revisions are manual and so may happen before or after the commit was pushed (if they were accurate at any stage).<br />
# Repeat the process to find a diff ID in the parent revision, and continue until there are no parent revisions. When viewing a particular diff ID, the "Commits" tab will have a commit hash and parent commit hash, if the diff was submitted from moz-phab at least. These may be useful in identifying parent revisions and diffs.<br />
# <code>arc patch --diff ''<NNNNN>''</code> may be used to create a commit for the first diff in the series.<br />
# For each subsequent diff use <code>arc patch --skip-dependencies --diff ''<NNNNN>''</code>. <code>--skip-dependencies</code> prevents more recent diffs for parent revisions or diffs for wrong parent revisions being fetched and prevents attempts to apply the specified diff on these incorrect diffs ([https://bugzilla.mozilla.org/show_bug.cgi?id=1485849 Tracked in bug 1485849])<br />
<br />
=== How do I get "arc patch" to apply changes to local tip instead of branching an earlier commit? ===<br />
<br />
Use <code>arc patch --nobranch [rest of command]</code>. The changes will be applied to the appropriate earlier commit, if known, and rebased.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== arc dies when I do [X]! How do I get debug information out of arc? ===<br />
<br />
Run <code>arc --trace [rest of command]</code>. You will get a lot of diagnostic information.<br />
<br />
If you've found a bug you can file it under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=Phabricator Phabricator component] in BMO.<br />
<br />
=== moz-phab fails on Windows: WindowsError: [Error 193] %1 is not a valid Win32 application ===<br />
<br />
This can happen if you copy your moz-phab configuration from another platform.<br />
<br />
Edit your ~/moz-phab config file and change "arc_command" to "arc.bat".<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== What does the "contains arc fields" error mean? ===<br />
<br />
The "contains arc fields" error means that revision was previously pushed to Phabricator with arc directly.<br />
<br />
moz-phab doesn't support all the fields that arc itself does, including the "test plan" field. If moz-phab were to rewrite the commit description that information would be lost. Currently moz-phab takes a conservative approach and will stop with the "contains arc fields" error message.<br />
<br />
You can work around that by rewriting the commit description yourself to only include the description and the 'Differential Revision:' line.<br />
<br />
There are plans to both support the "test plan" field and parse an arc formatted commit description with moz-phab.<br />
<br />
=== Does <code>arc</code> or <code>moz-phab</code> work with <code>mq</code> (Mercurial Queues) ===<br />
<br />
No. mq was deprecated 5+ years ago; please use '''evolve''' instead.<br />
<br />
See https://gregoryszorc.com/blog/2014/06/23/please-stop-using-mq/ and https://www.mercurial-scm.org/doc/evolution/from-mq.html<br />
<br />
=== Why <code>moz-phab</code> is submiting stack in reverse order? ===<br />
<br />
You might be using the '''bookbinder''' extension.<br />
Please run <code>moz-phab</code> in a safe mode, by using <code>--safe-mode</code> option.<br />
See https://bugzilla.mozilla.org/show_bug.cgi?id=1539412 for more detailed explanation and a different solution.<br />
<br />
=== moz-phab is not working after self-update ===<br />
<br />
Some shells cache called executables location. The last Python2 release removes itself after a successful installation of the package from PyPI. Since the original file has been removed a non-existing location might be called.<br />
In <code>bash</code> one rebuilds the cache by calling <code>hash -r</code>.<br />
<br />
It might also happen that <code>moz-phab</code> script was installed into a directory which is not mentioned in `PATH` variable. To check the directory run <code>pip3 show MozPhab -f</code><br />
<br />
== Lando ==<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
If you don't have Level 3, follow the guidelines for the repository you're trying to land code in.<br />
<br />
If you have Level 3 and are still getting this error, try:<br />
* logging out of auth0 and logging in again<br />
* ssh to hg.mozilla.org and verify that '''scm_level_3''' is reported there<br />
* log into https://sso.mozilla.com/info and check that '''active_scm_level_3''' is listed under '''<nowiki>https://sso.mozilla.com/claim/groups</nowiki>'''<br />
<br />
If you used to be a volunteer and are now an employee, you likely have two LDAP accounts, and you may not have your commit access associated with the account you used to log into Lando. See the next FAQ entry.<br />
<br />
Otherwise, contact Service Desk, as it indicates a misconfiguration with your account.<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I see an author on Phabricator. What's wrong? ===<br />
<br />
There are a few reasons this could happen:<br />
<br />
* '''The revision was created via the Phabricator Web UI or via an unsupported client.'''<br />
** Use arcanist or moz-phab to submit the patch instead; see the [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Mozilla Phabricator User Guide] for help.<br />
<br />
* '''The revision was created via arcanist or moz-phab, but the error still appears.'''<br />
** This can happen if you have not set an author email in your <code>.hgrc</code> file (or [https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup git config]). Set your author email in your <code>.hgrc</code> to your username, <code>Firstname Lastname <yourldapemail@mozilla.com></code>. Update your commit so it contains the new author data. Re-run <code>moz-phab submit</code> or <code>arc diff</code> so that the new commit+data is uploaded to Phabricator.<br />
<br />
* '''You are attempting to re-land a revision but [https://bugzilla.mozilla.org/show_bug.cgi?id=1489126 Bug 1489126] happens'''<br />
** This is an unfortunate bug that will be fixed in time, but for now you can get around this by reopening the revision on Phabricator and then resubmitting the revisions on your client. Follow the bug to see status updates.<br />
<br />
=== What are these red dots to the left of my commits? ===<br />
<br />
These show the shape of the commit stack, which is important when commits are non-linear:<br />
<br />
[[File:Lando-stack-shape.png|320px]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2019-10-07&diff=1218665WeeklyUpdates/2019-10-072019-10-07T17:18:11Z<p>Emceeaich: /* Welcome! */ add TW ELs</p>
<hr />
<div><br />
{{WeeklyUpdateNav}}<br />
* Every Monday @ 11:00am Pacific Time (19:00 UTC) <br />
* Watch at https://mzl.la/project-meeting-2019-10-07 or anonymously at https://air.mozilla.org. You can also watch on the Mozilla YouTube channel at https://www.youtube.com/watch?v=f0I7X-HmW6U.<br />
* join #weekly-project-call on irc.mozilla.org or Slack for backchannel discussion<br />
* If you plan on presenting, please join the Zoom video chat 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.<br />
* '''Presenters only:''' Zoom Meeting ID: 828 817 988 [https://mozilla.zoom.us/j/828817988 https://mozilla.zoom.us/j/828817988.] Do '''not''' use this room if you're not planning to speak. <br />
* One-tap mobile<br />
** +16465588656,,828817988# US (New York)<br />
** +17207072699,,828817988# US<br />
* Dial-in by your location<br />
** +1 646 558 8656 US (New York)<br />
** +1 720 707 2699 US<br />
** 877 853 5257 US Toll-free<br />
** +61 2 8015 2088 Australia<br />
** +61 8 7150 1149 Australia<br />
** 1800 893 423 Australia Toll-free<br />
** +1 647 558 0588 Canada<br />
** +33 1 8288 0188 France<br />
** +33 7 5678 4048 France<br />
** 0 805 082 588 France Toll-free<br />
** +49 30 5679 5800 Germany<br />
** +49 69 8088 3899 Germany<br />
** +49 30 3080 6188 Germany<br />
** 800 724 3138 Germany Toll-free<br />
** +852 5808 6088 Hong Kong, China<br />
** +44 203 695 0088 United Kingdom<br />
** +44 203 966 3809 United Kingdom<br />
** +44 203 051 2874 United Kingdom<br />
** 0 800 031 5717 United Kingdom Toll-free<br />
<br />
__TOC__<br />
<br />
= Weekly Project Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live status meeting.<br />
<br />
== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==<br />
Thank you to the AV team that supports this meeting. Coordinating all the offices and speakers and generally providing a great video experience for all of you is a big task and they do it week in and week out without fail so thank you!<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===<br />
<br />
=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
=== Later Events and Available Tickets ===<br />
<br />
'''Mozilla DevRel Complimentary Tickets'''<br />
<br />
Our DevRel Sponsorship team sometimes receives complimentary tickets to share with Mozillians interested in attending the following events. Please fill out this form [https://airtable.com/shrRFuIEm7j2a0Gtu Ticket RequestForm ]. <br />
If you have questions, reach out to the DevSponsorship Team at devsponsorship@mozilla.com for more details. <br />
<br />
'''[http://connect.tech/ CONNECT.TECH]''' Atlanta, GA, USA | 2019-10-16 to 2019-10-18<br />
<br />
'''[https://2018.ffconf.org/ ffconf]''' ffconf (formerly known as Full Frontal) Brighton, England | 2019-10-08 to 2019-10-08<br />
<br />
'''[https://www.rust-belt-rust.com: Rust Belt Rust]'''| Dayton, OH, USA | 2019-10-18-19<br />
<br />
'''[https://scriptconf.org/ Script'19: Javascript for Everyone]'''| Linz, Austria | 2019-10-25<br />
<br />
'''[https://halfstackconf.com/ Halfstack]''' London | 2019-11-22 <br />
<br />
'''[https://2019.webconf.asia/ Webconf Asia]''' Hong Kong | 2019-11-20-23 <br />
<br />
'''[https://ntnu.edu/wac2019 Web Audio Conference 2019]''' Trondheim, Norway | 2019-12-04 to 2019-12-06<br />
<br />
'''[https://halfstackconf.com/ Halfstack]''' Phoenix, AZ | 2020-01-17 <br />
<br />
<br />
''' Mozilla Sponsored Developer Events'''<br />
<br />
Current list of Mozilla sponsored developer events (with their start dates) around the globe (DevRel Events team will update):<br />
<br />
Dev Day 4 Women CDMX 2019 | 10/09/19 | Mexico City<br />
<br />
Paris Web 2019 | 10/10-12/19 | Bois-Colombes and Paris, France<br />
<br />
Web Engines Hackfest 2019 | 10/14/19 | Galicia, Spain<br />
<br />
CONNECT.TECH | 10/16/19 | Atlanta, GA, USA<br />
<br />
Rust Belt Rust | 10/18-19/19 | Dayton, OH, USA<br />
<br />
[https://indieweb.org/2019/Brighton 🎪 IndieWebCamp Brighton 2019] | 10/19/19 - 10/20/19 | Brighton, England<br />
<br />
ThunderPlains Developer Conference | 10/22/19 | Oklahoma City, USA<br />
<br />
2019 LLVM Developers' Meeting | 10/22-23/19 | San Jose, USA<br />
<br />
Rust.Tokyo | 10/26/19 | Tokyo<br />
<br />
a11yTO Conf | 10/24/19 | Toronto<br />
<br />
Script'19: Javascript for Everyone 10/25/19 | Linz, Austria<br />
<br />
Security BSides Portland | 10/25-26/19 | Portland, USA<br />
<br />
beyond tellerrand // | BERLIN 2019 | 11/4/19 | Berlin, Germany<br />
<br />
CascadiaJS | 11/07/19 | Seattle<br />
<br />
ffconf | 11/8/19 | Brighton, UK<br />
<br />
BoyaConf | 11/09/19 | Duitama, Boyacá, Colombia<br />
<br />
RustFest Barcelona | 11/09/19 | Barcelona<br />
<br />
Performance now |11/21-22/19 | Amsterdam, The Netherlands<br />
<br />
Halfstack | 11/22/19| London<br />
<br />
WebConf Asia | 11/20-23| Hong Kong<br />
<br />
webclerks community conference | 11/25/19 | Vienna<br />
<br />
Web Audio Conference 2019 | 12/4/19 | Trondheim, Norway<br />
<br />
Halfstack | 01/17/20 | Phoenix<br />
<br />
You Got This 2020 | 01/18/20 | Birmingham, UK<br />
<br />
JS Kongress Munich | 04/15-16/20 | Munich, Germany<br />
<br />
[https://indieweb.org/2020 ⛰ IndieWeb Summit 2020] | 06/27/20 - 06/28/20 | Portland, Oregon, USA<br />
<br />
== Speakers ==<br />
<br />
The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! [https://mozillians.org/u/USERNAME Presenter]<br />
! Title<br />
! Topic<br />
! Location<br />
! Sharing<br />
! Media<br />
! More Details<br />
|-<br />
| Who Are You?<br />
| What Do You Do?<br />
| What are you going to talk about?<br />
| Where are you presenting from? (Moz Space, your house, space)<br />
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
| Andrew Krug<br />
| Staff Security Engineer, Enterprise Information Security<br />
| IT MinIT<br />
| Remote, Via PreRecorded Video <br />
| Please play [https://drive.google.com/file/d/1t1W3Ft2f7Wpa7nTnsXPeyWfuTjs43SXu/view?usp=sharing video]<br />
| n/a<br />
| <br />
* [https://drive.google.com/file/d/1t1W3Ft2f7Wpa7nTnsXPeyWfuTjs43SXu/view?usp=sharing Video]<br />
* [https://wiki.mozilla.org/IT/WeeklyMinIT#2019-10-07 MinIT Wiki Shownotes]<br />
|-<br />
| Melissa Huerta<br />
| Senior Program Officer, Mozilla Fellowships<br />
| Mozilla's newest 29 fellows<br />
| San Francisco<br />
| No<br />
| n/a<br />
| Blog: [https://foundation.mozilla.org/en/blog/introducing-our-29-newest-mozilla-fellows/ Introducing Our 29 Newest Mozilla Fellows]<br />
|-<br />
| Ali Spivak<br />
| Director of Developer Relations<br />
| Emerging Technologies update<br />
| Mountain View<br />
| No<br />
| n/a<br />
| [https://wiki.mozilla.org/index.php?title=WeeklyUpdates/EmergingTechnology&action=edit#October_7th.2C_2019 ET headlines]<br />
|-<br />
| Asa Dotzler<br />
| Team Firefox<br />
| Weekly Browser Update<br />
| Mountain View<br />
| no<br />
| n/a<br />
| [https://wiki.mozilla.org/Firefox/Roadmap/Updates#2019-10-07 2019-10-07]<br />
|-<br />
|}<br />
<br />
= Welcome! =<br />
<br />
Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! ''Who is being introduced?''<br />
! ''Who are you? (the introducer)''<br />
! ''Where are you doing the introduction?''<br />
! ''Where are they from?''<br />
! ''How will they be part of Mozilla?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| Kyzzhibek Batyrkanova, Sara Dib, Hannatu Onogu<br />
| Miriam Avery, Liv Erikson, Kathy Giori, Nancy Hang, Emma Humphries, Kelsey Witthauer <br />
| Mountain View<br />
| Mountain View<br />
| TechWomen Emerging Leaders<br />
|-<br />
|}<br />
<br />
<br />
[[Category:Weekly Updates]]<br />
[[Category:Meeting Notes]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BugBot&diff=1218115BugBot2019-09-23T01:26:01Z<p>Emceeaich: Add close_intermittents.py documentation</p>
<hr />
<div>{{ DISPLAYTITLE:Autonag: Bugzilla triaging bot and alerting system }}<br />
<br />
<p style="font-size: larger; font-weight:bold;"><br />
This page lists all the actions done by the [https://github.com/mozilla/relman-auto-nag/ Autonag bot].</p><br />
<br />
= Introduction =<br />
Every day hundreds of tickets are opened in [https://bugzilla.mozilla.org Bugzilla] which track the tasks, defects and enhancements needed for the development of Firefox and other Mozilla projects. <br />
Triaging and priotirizing these bugs are an essential part of our development process and we automate part of this process so as to increase our development turn around and improve the quality of our bugs metadata. The set of scripts we use to improve the quality of our bugs, decrease our triaging time and help Release Management ship better quality software is called '''Autonag'''.<br />
<br />
Initially created as an alerting system (by email) to our triagers, Autonag rules now also make changes to our bugs metadata on Bugzilla so as to fix inconsistencies. <br />
<br />
Rules that change automatically some data in Bugzilla (change a priority, needinfo somebody, close a bug…) are called "Rules with Autofix" and those rules are applied once per hour. ''For now, security bugs aren't touched.''<br />
<br />
Rules that do not change data but have other results such as generate a report or send an email are called "Rules without Autofix". Rules without autofix are processed once a day (at 2PM CET).<br />
<br />
= Rules =<br />
== With autofix ==<br />
<br />
{{AutonagRule<br />
| Rule name = Bug assigned but marked as <code>UNCONFIRMED</code><br />
| Purpose = Mitigate an issue in Bugzilla (bugs reported by new users are not tagged as <code>NEW</code><br />
| Action = Change the status from <code>UNCONFIRMED</code> to <code>ASSIGNED</code> if there is an assignee<br />
| Example = 1495908<br />
| Source = assignee_but_unconfirmed.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Regression keyword is missing<br />
| Purpose = Regression keyword is important to differentiate an actual defect<br />
| Action = Sets the <code>regression</code> keyword on bugs with the <code>regression-range-wanted</code> keyword is set<br />
| Example = 1461034<br />
| Source = has_regression_range_no_keyword.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remove <code>leave-open</code> keyword on closed bug<br />
| Purpose = Clean up a mismatch in metadata<br />
| Action = If a bug is closed but the <code>leave-open</code> keyword is still set, remove it<br />
| Example = 1382185<br />
| Source = leave_open.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = [meta] in title but not in keywords<br />
| Purpose = Improve metedata quality<br />
| Action = Adds the <code>meta</code> keyword if the bug title starts by [META]<br />
| Example = 1435799 <br />
| Source = meta_summary_missing.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Update Firefox Status flags for bugs reopened during Nightly cycle<br />
| Purpose = Avoids potential issues for sheriffs and release managers<br />
| Action = Set <code>firefox-status</code> flag back from ''fixed'' to ''affected''<br />
| Example = 1495962<br />
| Source = nightly_reopened.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bug with no assignee but a patch landed<br />
| Purpose = Attribute unassigned bug to the developer that fixed it<br />
| Action = The ASSIGNEE field on the bug is changed from nobody@mozilla.org to the author of the patch that landed in mozilla-central<br />
| Example = 1514338<br />
| Source = no_assignee.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Close crash bugs with no crashes over 12 weeks<br />
| Purpose = Reduce the backlog of bugs to check for Release Managers <br />
| Action = Crash bugs without any crash reports for more than 12 weeks<br />
| Example = 1470864<br />
| Source = no_crashes.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remove <code>stalled</code> keyword on closed bugs<br />
| Purpose = Fix inconsistency between metadata and bug status<br />
| Action = If a bug is marked as <code>FIXED</code> and also has a <code>stalled</code> keyword set, the keyword is removed<br />
| Example = 1491624<br />
| Source = stalled.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Has meta keyword but not [meta] in the bug title<br />
| Purpose = Having [meta] in the bug title helps with quick search results<br />
| Action = If a bug has the meta keyword set, [meta] is added to the bug title<br />
| Example = 1257692<br />
| Source = summary_meta_missing.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Set a Firefox status flag for beta if there is one for nightly and release<br />
| Purpose = Fix inconsistency in Firefox status flags that can lead to a bug going undetected by Release Managers during the beta cycle<br />
| Action = If a status exists for Firefox N-1 and for Firefox N+1, guess a value for Firefox N <br />
| Example = 1500273<br />
| Source = missing_beta_status.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Increase priority of bugs tracked y Release Managers<br />
| Purpose = Priotitizes bugs needing an action for shipping quality software<br />
| Action = If a bug is tracked by a Release Manager, update the priority (P2 for nightly, P1 for the rest)<br />
| Example = 1515946,1508277,1512493<br />
| Source = mismatch_priority_tracking_release.py<br />
| Note = There are multiple files mismatch-priority-tracking-*.py, one per channel<br />
}}<br />
{{AutonagRule<br />
| Rule name = Add <code>regression</code> keywords to bugs (uses Machine Learning)<br />
| Purpose = Surface regressions not filed as such<br />
| Action = If a bug is tracked by a Release Manager, update the priority (P2 for nightly, P1 for the rest)<br />
| Example = 1529139<br />
| Source = regression.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Move untriaged bug into the correct component (uses machine learning) <br />
| Purpose = Decrease manual triagin time<br />
| Action = Uses machine learning to mass move bugs in Firefox::Untriaged into a better component<br />
| Example = 1530316 <br />
| Source = component.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Copy crash signature from duplicate bugs to main bugs<br />
| Purpose = Crash bugs marked as duplicate of another one may have a different crash signature. We need to consolidate all signatures in the bug where a patch to fix them is being worked on, other wise we may not fix them all<br />
| Action = If a crash bug is marked as a duplicate, the signatures it referenced are added to the new bug<br />
| Example = 1517205<br />
| Source = copy_duplicate_info.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Increase severity of bugs tracked by Release Managers<br />
| Purpose = Fix inconsistency in metadata<br />
| Action = If a bug is tracked for an upcoming release but it's severity field is low, the severity is increased<br />
| Example = 1538966<br />
| Source = tracked_bad_severity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner to set priority on bugs<br />
| Purpose = Every defect should have a priority set. Also bugs with no priority set are harder to prioritize for Release Managers with regards to the release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage])<br />
| Action = The triage owner is needinfoed in Bugzilla or nagged via email to set a priority on bugs<br />
| Example = 1527818<br />
| Source = workflow/no_priority.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner on P1 bugs with no activity<br />
| Purpose = Since P1 means that the bug should be fixed for the next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), the bug needs to show any progress in its resolution (or maybe the priority should be decreased)<br />
| Action = The triage owner is nagged via email to have a reminder<br />
| Example = 1507251<br />
| Source = workflow/p1_no_activity.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Nag triage owner to find an assignee for P1 bugs with no assignee and no activity<br />
| Purpose = Since P1 means that the bug should be fixed for the next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), the bug urgently needs to have an assignee (or the priority should be decreased)<br />
| Action = The triage owner is needinfoed in Bugzilla or nagged via email to find an assignee on bugs<br />
| Example = 1541291<br />
| Source = workflow/p1_no_assignee.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Change the priority from P2 to P1 on assigned bug the merge day<br />
| Purpose = Since P2 means that the bug should be fixed for the next next release (see [https://mozilla.github.io/bug-handling/triage-bugzilla#what-do-you-triage what-do-you-triage]), when we are the merge day then this bug automatically becomes a P1.<br />
| Action = Update the priority to P1 and add a comment to explain.<br />
| Example = <br />
| Source = workflow/p2_merge_day.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Patch not landed <br />
| Purpose = Identify bugs with an unlanded r+ patch. Maybe the patch is now obsolete or the bug needs to have a sheriff land the code with the <code>checkin-needed</code> keyword set.<br />
| Action = The bug assignee is needinfoed in Bugzilla to ask her/him to have look<br />
| Example = 1496844<br />
| Source = not_landed.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Regression without regressed_by and some bug dependencies <br />
| Purpose = Identify regressions which have dependencies (blocks or depends_on) and an empty regressed_by, probably people forgot to use the new field.<br />
| Action = The bug assignee or the person who added some dependencies or the reporter is needinfoed to ask to fill regressed_by when it's possible.<br />
| Example = 1545797<br />
| Source = regression_without_regressed_by.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Product::Component changed after the priority has been set <br />
| Purpose = Identify bugs where Product::Component changed after the priority has been set. The priority is probably no more up-to-date and so triage owner needs to set it.<br />
| Action = Reset the priority to "--" with a comment explaining why the bot is doing that.<br />
| Example = 1546366<br />
| Source = prod_comp_changed_with_priority.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Close intermittent test failure bugs <br />
| Purpose = Close intermittent test failure bugs which are P5s, not marked <code>leave-open</code>, and have not had a new failure in 21 days.<br />
| Action = RESOLVE bug as INCOMPLETE with a comment explaining why the bot is doing this.<br />
| Example = 1577895<br />
| Source = close_intermittents.py<br />
}}<br />
<br />
== Without autofix ==<br />
<br />
<br />
{{AutonagRule<br />
| Rule name = Feature vs regression<br />
| Purpose = Fix inconsistency in bugs with both the <code>regression</code> and <code>feature</code> keywords set <br />
| Source = feature_regression.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Inactive bugs with the <code>leave-open</code> keyword set<br />
| Purpose = Help identify dead/inactive bugs<br />
| Action = Needinfo the triage owner if a bug is inactive but has the <code>leave-open</code> keyword set<br />
| Example = 1367072<br />
| Source = leave_open_no_activity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Inactive Meta bugs<br />
| Purpose = Help identify dead/inactive bugs<br />
| Action = Needinfo the triage owner if a meta bug has no activity and no dependencies set <br />
| Source = meta_no_deps_no_activity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Low-severity bug but tracked by a release manager <br />
| Purpose = Idenitfy mismatch in metadata, a tracked bug should not have a priotity lower than ''normal''<br />
| Source = mismatch-priority-tracking.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Alert for lack of feedback in a bug<br />
| Purpose = Increase reaction time on bugs prioritized by upper management or release managers<br />
| Action = If a bug as an unanswered NeedInfo request from a release manager or a director, send a warning email<br />
| Source = ni_from_manager.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with no priority and no activity<br />
| Purpose = Triage owners need to process the backlog<br />
| Action = Needinfo the triage owner (only :Overholt for now)<br />
| Example = 1503461<br />
| Source = ni_triage_owner.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with only one or two words in the summary<br />
| Purpose = Make sure the bug is actually useful, a two-words summary often indicates a poor quality bug report<br />
| Example = 1512823<br />
| Source = one_two_word_summary.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Remind developers about tracked bugs<br />
| Purpose = Make sure that bugs tracked for the next release are addressed<br />
| Source = query_creator.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Reporter not answering to Needinfo request<br />
| Purpose = identify bugs stalled because we need more information fron the reporter to reproduce it<br />
| Source = reporter_with_ni.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Top crashers vs ''normal'' severity<br />
| Purpose = Consistency and help getting traction on bugs<br />
| Example = 1471692<br />
| Source = topcrash_bad_severity.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Identify tracked bugs with a NeedInfo request<br />
| Purpose = Make sure that bugs tracked for a release or nominated for tracking which also have a NeedInfo request do not get stuck<br />
| Action = Send an email<br />
| Source = tracked_needinfo.py <br />
}}<br />
{{AutonagRule<br />
| Rule name = Tracked bugs untouched for a week<br />
| Purpose = Identify important bugs for a release which are not being acted upon <br />
| Action = Send an email<br />
| Source = tracking.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Regressed in upcoming release<br />
| Purpose = Identify potential regression<br />
| Action = Send an email with the list of bugs marked as non affecting a release but affecting the next one<br />
| Source = unaffected_affected_no_reg.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Identify unlanded uplifts to Beta and ESR<br />
| Purpose = Make sure that we ship with the bugs that we need<br />
| Action = Send an email wih the list of bugs with uplift requests not landed on the affected branch<br />
| Example = 1509394<br />
| Source = unlanded.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Bugs with high severity in Firefox::Untriaged<br />
| Purpose = Identify potentially important issues left untriaged<br />
| Source = untriage_important_sev.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = <code>Version</code> set but not <code>status_firefox</code><br />
| Purpose = The <code>Version</code> value is set automatically by Bugzilla on landing a patch but not the <code>status_firefoxXX</code><br />
| Action = Send an email<br />
| Source = version_affected.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Check release dates on the Wiki<br />
| Purpose = Verify the consistency of our release dates on wiki.mozilla.org as we use them in automation <br />
| Action = Send an email<br />
| Source = ../next_release.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Information about bugs landed during Soft Code Freeze<br />
| Purpose = List fixed bug with patches which landed in mozilla-central during the soft freeze week. The listing includes patch statistics.<br />
| Action = Send an email<br />
| Source = code_freeze_week.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = Hightlight Fixed bugs in nightly we may want to uplift<br />
| Purpose = Identify potentially upliftable bugs. <br />
| Action = Send an email with the recent fixes, the affected branches and metadata for prioritization<br />
| Source = missed_uplifts.py<br />
}}<br />
{{AutonagRule<br />
| Rule name = New user with a Needinfo request<br />
| Purpose = Help identify potentially unactionnable bugs per lack of information<br />
| Action = Send an email<br />
| Source = newbie_with_ni.py<br />
}}<br />
[[category:Release_Management|Autonag]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide/BugStatuses&diff=1217091BMO/UserGuide/BugStatuses2019-08-27T23:29:39Z<p>Emceeaich: /* Resolutions */ Add MOVED</p>
<hr />
<div>= Bug Statuses =<br />
<br />
; STATUS<br />
: The Status field indicates the current state of a bug. Only certain status transitions are allowed.<br />
; RESOLUTION<br />
: The Resolution field indicates what happened to this bug.<br />
<br />
== Open Bugs ==<br />
<br />
=== Statuses ===<br />
<br />
; UNCONFIRMED<br />
: This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the "canconfirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED. <br />
; NEW<br />
: This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED. <br />
; ASSIGNED<br />
: This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED. <br />
; REOPENED<br />
: This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED. <br />
<br />
== Closed Bugs == <br />
<br />
=== Statuses ===<br />
<br />
; RESOLVED<br />
: A resolution has been performed, and it is awaiting verification by QA. From here bugs are either reopened and given some open status, or are verified by QA and marked VERIFIED. <br />
; VERIFIED<br />
: QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED. <br />
<br />
=== Resolutions ===<br />
<br />
; FIXED<br />
: A fix for this bug is checked into the tree and tested. <br />
; INVALID<br />
: The problem described is not a bug. <br />
; WONTFIX<br />
: The problem described is a bug which will never be fixed. <br />
; MOVED ''(Proposed 2019-08-27)''<br />
: The problem is now being worked on another issue tracker. The [https://wiki.mozilla.org/BMO/UserGuide/BugFields#see_also See Also field] must contain the URL of the bug on the other tracker.<br />
; DUPLICATE<br />
: The problem is a duplicate of an existing bug (the problems must be exactly the same). Marking a bug duplicate requires the bug# of the duplicating bug and will at least put that bug number in the description field. If a bug has the same root cause as another one but the two bugs are finally different, then they should have a dependency such as [https://wiki.mozilla.org/BMO/UserGuide/BugFields#dependson depends_on].<br />
; WORKSFORME<br />
: All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the bug can be reopened. <br />
; INCOMPLETE<br />
: The problem is vaguely described with no steps to reproduce, or is a support request. The reporter should be directed to the product's support page for help diagnosing the issue. If there are only a few comments in the bug, it may be reopened only if the original reporter provides more info, or confirms someone else's steps to reproduce. If the bug is long, when enough info is provided a new bug should be filed and the original bug marked as a duplicate of it.</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide/BugFields&diff=1217090BMO/UserGuide/BugFields2019-08-27T23:29:00Z<p>Emceeaich: /* Bugzilla Field Descriptions */ See Also should be for related bugs or bugs in other trackers</p>
<hr />
<div>== Bugzilla Field Descriptions ==<br />
<br />
{{anchor|alias}}<br />
; Alias<br />
: A short, unique name assigned to a bug in order to assist with looking it up and referring to it in other places in Bugzilla.<br />
{{anchor|assigned_to}}<br />
; Assignee<br />
: This is the person in charge of resolving the bug. Every time this field changes, the status changes to NEW to make it easy to see which new bugs have appeared on a person's list.<br />
{{anchor|blocks}}<br />
; Blocks<br />
: This bug must be resolved before the bugs listed in this field can be resolved.<br />
{{anchor|bug_id}}<br />
; Bug ID<br />
: The numeric id of a bug, unique within this entire installation of Bugzilla.<br />
{{anchor|cc}}<br />
; CC<br />
: Users who may not have a direct role to play on this bug, but who are interested in its progress.<br />
{{anchor|delta_ts}}<br />
; Changed<br />
: When this bug was last updated.<br />
{{anchor|classification}}<br />
; Classification<br />
: Bugs are categorised into Classifications, Products and Components. classifications is the top-level categorization.<br />
{{anchor|comment}}<br />
; Comment<br />
: Bugs have comments added to them by Bugzilla users. You can search for some text in those comments.<br />
{{anchor|comment_tag}}<br />
; Comment Tag<br />
: Comments can have arbitrary tags added to them to help with filtering as well as mark comments as spam or abusive. <br />
{{anchor|component}}<br />
; Component<br />
: Components are second-level categories; each belongs to a particular Product. Select a Product to narrow down this list.<br />
{{anchor|creation_ts}}<br />
; Creation date<br />
: When the bug was filed.<br />
{{anchor|dependson}}<br />
; Depends on<br />
: The bugs listed here must be resolved before this bug can be resolved.<br />
{{anchor|duplicates}}<br />
; Duplicates<br />
: List of bugs that have been marked a duplicate of the bug currently being viewed.<br />
{{anchor|rep_platform}}<br />
; Hardware<br />
: This is the hardware platform against which the bug was reported.<br />
{{anchor|importance}}<br />
; Importance<br />
: The importance of a bug is described as the combination of its Priority and Severity.<br />
{{anchor|keywords}}<br />
; Keywords<br />
: Keywords are a controlled vocabulary for characterizing bugs across Products and Components. Examples of this field are <code>regression</code>, <code>sec-high</code>, and <code>topcrash</code>. Bugzilla administrators manage [https://bugzilla.mozilla.org/describekeywords.cgi the list of keywords]. If you believe you need a new keyword, [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration please contact the administrators to discuss]. <br />
{{anchor|bug_mentor}}<br />
; Mentors<br />
: Mentors are users who have offered to help the bug owner with such tasks as setting up a development environment, finding relevant information to fixing the bug, how to submit a patch for review, and finally how to get the fix committed.<br />
{{anchor|needinfo}}<br />
; Needinfo<br />
: More information has been requested from specific individuals, or anyone, to move the bug forward to completion.<br />
{{anchor|op_sys}}<br />
; OS<br />
: This is the operating system against which the bug was reported.=<br />
{{anchor|priority}}<br />
; Priority<br />
: This field describes the importance and order in which a bug should be fixed compared to other bugs. This field is utilized by the programmers/engineers/release managers/managers to prioritize the work to be done. See [https://mozilla.github.io/bug-handling/triage-bugzilla the Firefox triage documentation] or for the main Bugzilla project, [[Bugzilla:Priority_System]].<br />
{{anchor|product}}<br />
; Product<br />
: Bugs are categorised into Products and Components. Select a Classification to narrow down this list.<br />
{{anchor|qa_contact}}<br />
; QA Contact<br />
: The person responsible for confirming this bug if it is unconfirmed, and for verifying the fix once the bug has been resolved.<br />
{{anchor|rank}}<br />
; Rank<br />
: Used by some groups to provide finer-grained ordering for working on bugs than afforded by the Priority field. Use of this field is restricted to the `rank-setters` group.<br />
{{anchor|regressed_by}}<br />
; Regressed by<br />
: This bug has been introduced by the bugs listed here.<br />
{{anchor|regresses}}<br />
; Regressions<br />
: This bug has introduced the bugs listed here.<br />
{{anchor|reporter}}<br />
; Reporter<br />
: The person who filed this bug.<br />
{{anchor|see_also}}<br />
; See Also<br />
: This allows you to refer to bugs in other bug tracker installations. You can enter a URL to a bug in the 'Add Bug URLs' field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma. You should normally use this field to refer to bugs in other bug tracker installations, or bugs which are related to, but not known to be duplicates of the bug. Bugs which are regressions should be listed in the Regressed by field (above)<br />
{{anchor|bug_severity}}<br />
; Severity<br />
: This field describes the impact of a bug.<br />
{| class="wikitable"<br />
|'''blocker'''<br />
|Broken important user-facing feature, Blocks development and/or testing work<br />
|-<br />
|'''critical'''<br />
|Affecting a large number of users (all users on AMD64, Windows, MacOS, Linux), or major areas of functionality (tls, DOM, JavaScript, FxA, Add-ons)<br />
|-<br />
|'''normal'''<br />
|Default; Regular issue, some loss of functionality under specific circumstances<br />
|-<br />
|'''minor'''<br />
|Affecting a small number of users (i.e. ArchLinux users on PowerPC), a problem with an easy workaround, or a cosmetic issue such as misspellings or text alignment<br />
|} <br />
{{anchor|short_desc}}<br />
; Summary<br />
: The bug summary is a short sentence which succinctly describes what the bug is about.<br />
{{anchor|target_milestone}}<br />
; Target Milestone<br />
: For Firefox-related bugs, when a change set (patch) lands in Mozilla-Central, the [[Sheriffing|sheriffs]] will set this field to the corresponding release value for the current Nightly.<br />
: Release status and tracking flags are used to mark intentions for when a fix or other patch should land. <br />
: If you need to track a bug against a set of milestones other than upcoming versions of Firefox, please tell the Bugzilla team, you may want a custom status flag. <br />
{{anchor|triage_owner}}<br />
; Triage Owner<br />
: User that is responsible [https://mozilla.github.io/bug-handling/triage-bugzilla for triaging bugs in a specific component].<br />
{{anchor|bug_type}}<br />
; Type<br />
: This field describes the [https://mozilla.github.io/bug-handling/bug-types type of a bug].<br />
{| class="wikitable"<br />
|-<br />
|'''defect'''<br />
|regression, crash, hang, security vulnerability and any other general issue.<br />
|-<br />
|'''enhancement'''<br />
|new feature, improvement in UI, performance, etc. and any other request for user-facing changes and enhancements in the product; not engineering changes<br />
|-<br />
|'''task'''<br />
|refactoring, removal, replacement, enabling or disabling of functionality and any other engineering task<br />
|} <br />
{{anchor|bug_file_loc}}<br />
; URL<br />
: Bugs can have a URL associated with them - for example, a pointer to a web site where the problem is seen.<br />
{{anchor|version}}<br />
; Version<br />
: The version field defines the version of the software the bug was found in.<br />
{{anchor|votes}}<br />
; Votes<br />
: Some bugs can be voted for, and you can limit your search to bugs with more than a certain number of votes. Votes are not used by Mozilla developers to set priorities.<br />
{{anchor|status_whiteboard}}<br />
; Whiteboard<br />
: Each bug has a free-form single line text entry box for adding tags and status information</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2019-08-19&diff=1216713WeeklyUpdates/2019-08-192019-08-19T00:02:17Z<p>Emceeaich: /* Friends of Mozilla */ ao3 shoutout</p>
<hr />
<div><br />
{{WeeklyUpdateNav}}<br />
* Every Monday @ 11:00am Pacific Time (19:00 UTC) <br />
* Watch anonymously at https://air.mozilla.org.<br />
* join #weekly-project-call on irc.mozilla.org or Slack for backchannel discussion<br />
* If you plan on presenting, please join the Zoom video chat 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.<br />
* '''Presenters only:''' Zoom Meeting ID: 828 817 988 [https://mozilla.zoom.us/j/828817988 https://mozilla.zoom.us/j/828817988.] Do '''not''' use this room if you're not planning to speak. <br />
* One-tap mobile<br />
** +16465588656,,828817988# US (New York)<br />
** +17207072699,,828817988# US<br />
* Dial-in by your location<br />
** +1 646 558 8656 US (New York)<br />
** +1 720 707 2699 US<br />
** 877 853 5257 US Toll-free<br />
** +61 2 8015 2088 Australia<br />
** +61 8 7150 1149 Australia<br />
** 1800 893 423 Australia Toll-free<br />
** +1 647 558 0588 Canada<br />
** +33 1 8288 0188 France<br />
** +33 7 5678 4048 France<br />
** 0 805 082 588 France Toll-free<br />
** +49 30 5679 5800 Germany<br />
** +49 69 8088 3899 Germany<br />
** +49 30 3080 6188 Germany<br />
** 800 724 3138 Germany Toll-free<br />
** +852 5808 6088 Hong Kong, China<br />
** +44 203 695 0088 United Kingdom<br />
** +44 203 966 3809 United Kingdom<br />
** +44 203 051 2874 United Kingdom<br />
** 0 800 031 5717 United Kingdom Toll-free<br />
<br />
__TOC__<br />
<br />
= Weekly Project Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live status meeting.<br />
<br />
== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==<br />
<br />
A shout out to the Archive of Our Own project at https://ao3.org/, who became the first Open Source project to win a Hugo award at last night's ceremony in Dublin, Ireland. Not only is it an Open Source project, but one lead by Non-Binary and Women.<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===<br />
<br />
=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
=== Later Events and Available Tickets ===<br />
<br />
'''Mozilla DevRel Complimentary Tickets'''<br />
<br />
Our DevRel Sponsorship team sometimes receives complimentary tickets to share with Mozillians interested in attending the following events. Please fill out this form [https://airtable.com/shrRFuIEm7j2a0Gtu Ticket RequestForm ]. <br />
If you have questions, reach out to the DevSponsorship Team at devsponsorship@mozilla.com for more details. <br />
<br />
''' Mozilla Sponsored Developer Events'''<br />
<br />
Current list of Mozilla sponsored developer events (with their start dates) around the globe (DevRel Events team will update):<br />
<br />
== Speakers ==<br />
<br />
The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! [https://mozillians.org/u/USERNAME Presenter]<br />
! Title<br />
! Topic<br />
! Location<br />
! Sharing<br />
! Media<br />
! More Details<br />
|-<br />
| Who Are You?<br />
| What Do You Do?<br />
| What are you going to talk about?<br />
| Where are you presenting from? (Moz Space, your house, space)<br />
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
|}<br />
<br />
= Welcome! =<br />
<br />
Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! ''Who is being introduced?''<br />
! ''Who are you? (the introducer)''<br />
! ''Where are you doing the introduction?''<br />
! ''Where are they from?''<br />
! ''How will they be part of Mozilla?''<br />
|-<br />
|-<br />
| Morgan Reschenberg<br />
| Daniel Holbert<br />
| San Francisco<br />
| UC Berkeley<br />
| Platform engineer on the Accessibility team<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| Their Name<br />
| Your Name<br />
| Intro location<br />
| Their Location<br />
| Their Role<br />
|-<br />
|}<br />
<br />
<br />
[[Category:Weekly Updates]]<br />
[[Category:Meeting Notes]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/Requesting_Changes&diff=1215445BMO/Requesting Changes2019-07-23T00:44:47Z<p>Emceeaich: /* Components */ templates</p>
<hr />
<div>This page details the information you need to provide in order to get speedy resolution to requests to change the configuration of [https://bugzilla.mozilla.org/ bugzilla.mozilla.org]. The BMO administration team aims to turn around all correctly-specified requests in 1 business day, however some changes made take longer (due to development effort required).<br />
<br />
In general, the more significant a change you want to make, the more likely it is that you will need to provide evidence of discussion and consensus around the change.<br />
<br />
==Additions==<br />
<br />
[https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration File a bug], providing:<br />
<br />
===Products===<br />
<br />
* (required) The name of the product<br />
* (required) The [https://bugzilla.mozilla.org/enter_bug.cgi?full=1 classification] (group) you would like the product in<br />
* (required) A longer description, usually including a web link for more info on the product<br />
* (required) The initial list of components, with their info (see [[BMO/Requesting_Changes#Components|below]])<br />
* (required) The security group(s) bugs should be classified under when a user checks the security flag (if you don't know, we can help figure this out for you)<br />
* (optional) A template (in markdown) for bugs in the new product (this can be overriden at the component level)<br />
* (optional) The initial list of versions, with their info (see [[BMO/Requesting_Changes#Versions|below]])<br />
* (optional) The initial list of target milestones, with their info (see [[BMO/Requesting_Changes#Target_Milestones|below]])<br />
* (optional) The number of votes needed to confirm a bug (UNCO --> NEW) (disabled by default)<br />
* (optional) If you want review requests to require a reviewer (false by default)<br />
* (optional) The list of [https://bugzilla.mozilla.org/page.cgi?id=review_suggestions.html suggested reviewers] for the review flag (empty by default)<br />
* (optional) The number of days until a review/needinfo/feedback is considered "overdue" and will trigger a reminder email (default 7 days)<br />
* (optional) Any flags you want visible on the product (this can be per-component, or product-wide).<br />
<br />
===Components===<br />
<br />
* (required) The name of the component<br />
* (required) The product it should go in<br />
* (required) A longer description<br />
* (required) A [https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html triage lead], responsible for [https://wiki.mozilla.org/Bugmasters/Process/Triage making decisions] on NEW bugs in the component (optional if not a Firefox component, but recommended)<br />
* (optional) A template (in markdown) for new bugs in the component. If this is specified, it will override the template for the parent product if one exists<br />
* (optional) It's highly recommended that the default assignee for new bugs is 'nobody@mozilla.org', however this can be changed if required<br />
* (optional) Normally the "QA Contact" is empty, but you can optionally set it to a specific individual<br />
* (optional) Any flags (bug and/or attachment) that will need to be visible for bugs against the new component<br />
* (optional) The list of [https://bugzilla.mozilla.org/page.cgi?id=review_suggestions.html suggested reviewers] for the review flag (uses the product's review suggestions by default)<br />
<br />
Triage lead, QA contact, and recommended viewers should all be bugmail addresses, so check against Mozillians, Phonebook, or ask to make sure you have the right email.<br />
<br />
===Bug Templates===<br />
<br />
You can specify, at the product and component level, a template for new bugs. The template should be in Markdown and should ask for information and steps specific to the product or component.<br />
<br />
If a product has a bug template, all new bugs in the product will display the template, unless the template is overridden at the component level.<br />
<br />
If a component has a bug template, all new bugs in the component will display that template, overriding any product level components template.<br />
<br />
===Versions===<br />
<br />
* (required) The name of the version<br />
* (required) The product it should go in<br />
<br />
===Target Milestones===<br />
<br />
* (required) The name of the target milestone<br />
* (required) The product it should go in<br />
<br />
===Custom Fields===<br />
Adding new custom fields is not something we can do easily, so we try to be careful about adding them.<br />
They add more complexity to the UI, and carry an overhead for all bugs on the system, regardless of their visibility. You'll need to make your case before a custom field can be added. Generally, if a custom field is very specific to one niche area and do not concern the Project as a whole, we encourage the use of status whiteboard markers or other existing fields. <br />
* (required) The name of the field<br />
* (required) A longer description<br />
* (required) The type (Bug ID, Large Text Box, Free Text, Multiple Selection Box, Single Selection Box or Date/Time)<br />
* (required) The initial set of values, if Multiple or Single Selection Box<br />
* (required) The product(s) it should show up in<br />
* (required) Whether it can be set on bug creation<br />
<br />
===Keywords===<br />
<br />
Keywords are a faster and typo-free alternative to using whiteboard tags. In order to create one we'll need:<br />
<br />
* (required) The name of the keyword<br />
* (required) The description to use<br />
<br />
===Additional Field Values===<br />
<br />
This could be Hardware or OS.<br />
<br />
* (required) The value to be added<br />
* (required) The field it should be added to<br />
<br />
===Flags===<br />
<br />
* (required) The name of the flag<br />
* (required) A longer description<br />
* (required) Which products/components the flag should appear in<br />
* (required) Whether the flag applies to bugs or attachments<br />
* (required) Whether the flag is requestable (i.e. users can ask for flags of this type to be set)<br />
* (required) Whether the flag should be requested from a specific person<br />
* (required) Whether the flag can be set multiple times<br />
* (optional) If flags of this type are requestable, the group allowed to request them, if any<br />
* (optional) The group allowed to grant/deny flags of this type, if any<br />
* (optional) CC list for request notifications, if any (not recommended, use component watching)<br />
<br />
===Users===<br />
<br />
Users can sign up for accounts themselves.<br />
<br />
===Statuses and Resolutions===<br />
<br />
Changing the Bugzilla workflow is a big deal, and is very unlikely to happen without serious discussion. If you don't know whether you are authorised to make this sort of change, you aren't.<br />
<br />
===Security Groups===<br />
<br />
* Security groups are rarely granted explicitly into. Normally the groups membership is determined by inheritance from other groups.<br />
* Most security groups have a related "-team" group that is used for actually granting people into. For example, no one is in the 'client-services-security' group directly. There is a 'client-services-security-team' group which is a member of the 'client-services-security' group. The individual users are placed directly into the 'client-services-security-team' group when needed. Therefore they get access to the other group as well through inheritance. Only the 'client-services-security' group should be actually visible on the bug report.<br />
<br />
'''Information Needed'''<br />
<br />
* Name for the new group.<br />
* Which products need to have the new group enabled.<br />
* Whether a specific account or mailing list should be automatically cc'ed when a bug is placed in the new group (optional).<br />
* List of users to be placed in the new team group initially.<br />
* Who should be the admin for the new group (bless rights) that will be able place others in the team group (optional).<br />
<br />
==Changes==<br />
<br />
===Changing Product, Component, Version or Milestone Name===<br />
<br />
Bugzilla uses integer mappings internally for mapping IDs to human readable names such as Product, Component, etc. But when creating store queries in the form of a URL or when specifying a product to file a bug against, it doesn't use the ID, it uses the name. When a textual name is changed in BMO using the admin UI to something else, Bugzilla continues to work properly as it still uses the same ID everywhere internally and in the database. But if a stored query or a URL has been passed around to others via a wiki page, mailing list, etc. then the URL will no longer be valid. Users will need to update their queries and revise and relevant documentation to reflect the name change. Bugzilla, and BMO for that matter, does not support aliasing of the new name to any old names so that the old queries will continue to work. BMO admins will try harder to remind requesters that these issues may arise when making these types of name changes.<br />
<br />
Note that this also affects BzAPI or the newer native REST API in that you will need to update the search parameters for bug searches to reflect the name changes as well.<br />
<br />
===Suggested Reviewers===<br />
<br />
A curated list of users can be suggested when the review flag is set for a patch, to aid new contributors in picking a reviewer. These suggested reviewers can be set globally for a product, or on a per-component basis. For the current list of users, see the [https://bugzilla.mozilla.org/page.cgi?id=review_suggestions.html suggested reviewers report].<br />
<br />
===Usernames and Passwords===<br />
<br />
Users can change their own username (email address) or password in the preferences. Changing your own email address is greatly preferred to creating a new account and then asking for a merge. If you have already created a new account but have not yet used it, then change its username to something bogus (i.e. abandon it), and change the username on your old account to the new one.<br />
<br />
If you do need two accounts merged, and both have activity you don't want to lose, you will need to file a bug (see above).<br />
<br />
===Retiring Products and Components===<br />
<br />
Products and components aren't deleted from Bugzilla, since the records of their bugs or the work done on them may be useful. Instead, usually they are changed to disable the creation of new bugs in their category. They can also be moved to a "Graveyard" area.<br />
<br />
Here's [[BMO/RetiringComponents|how to retire components and products]].<br />
<br />
===User Permissions===<br />
<br />
For common user permissions, i.e. canconfirm and editbugs, please see the [instructions on BMO itself https://bugzilla.mozilla.org/page.cgi?id=get_permissions.html]. For other permissions, e.g. security groups, please file a confidential bug or contact the BMO team.<br />
<br />
==Disablings==<br />
<br />
===Users===<br />
<br />
Email bugzilla-admin@mozilla.org giving sufficient evidence of violation of Mozilla policies or community norms.<br />
<br />
===Versions===<br />
<br />
===Target Milestones===<br />
<br />
Old target milestones are normally disabled by the team at some point after the release has happened. This means that they can't be selected on bugs (although they will continue to show up if that's the current value) and you have to use the Boolean Charts to search for them.<br />
<br />
==Deletions==<br />
<br />
Things in Bugzilla rarely get deleted. Many things can be disabled (see above) instead. You should not expect deletions to happen fast. It's probably best to file a bug explaining what you need deleted and why, and expect questions.<br />
<br />
===Attachments===<br />
<br />
If you add an attachment and then realise it contains confidential or personal information, file a bug and it can be manually annulled. (The attachment links and name will remain, but the data will be removed.)<br />
<br />
===Users===<br />
<br />
We don't delete accounts because that would be messing with the historical record. However, users can disable all their bug mail in their preferences if they would like to stop hearing from Bugzilla, and they may change their email address to an inactive or throwaway one if they wish.<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/Requesting_Changes&diff=1215444BMO/Requesting Changes2019-07-23T00:41:08Z<p>Emceeaich: /* Products */ add template</p>
<hr />
<div>This page details the information you need to provide in order to get speedy resolution to requests to change the configuration of [https://bugzilla.mozilla.org/ bugzilla.mozilla.org]. The BMO administration team aims to turn around all correctly-specified requests in 1 business day, however some changes made take longer (due to development effort required).<br />
<br />
In general, the more significant a change you want to make, the more likely it is that you will need to provide evidence of discussion and consensus around the change.<br />
<br />
==Additions==<br />
<br />
[https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration File a bug], providing:<br />
<br />
===Products===<br />
<br />
* (required) The name of the product<br />
* (required) The [https://bugzilla.mozilla.org/enter_bug.cgi?full=1 classification] (group) you would like the product in<br />
* (required) A longer description, usually including a web link for more info on the product<br />
* (required) The initial list of components, with their info (see [[BMO/Requesting_Changes#Components|below]])<br />
* (required) The security group(s) bugs should be classified under when a user checks the security flag (if you don't know, we can help figure this out for you)<br />
* (optional) A template (in markdown) for bugs in the new product (this can be overriden at the component level)<br />
* (optional) The initial list of versions, with their info (see [[BMO/Requesting_Changes#Versions|below]])<br />
* (optional) The initial list of target milestones, with their info (see [[BMO/Requesting_Changes#Target_Milestones|below]])<br />
* (optional) The number of votes needed to confirm a bug (UNCO --> NEW) (disabled by default)<br />
* (optional) If you want review requests to require a reviewer (false by default)<br />
* (optional) The list of [https://bugzilla.mozilla.org/page.cgi?id=review_suggestions.html suggested reviewers] for the review flag (empty by default)<br />
* (optional) The number of days until a review/needinfo/feedback is considered "overdue" and will trigger a reminder email (default 7 days)<br />
* (optional) Any flags you want visible on the product (this can be per-component, or product-wide).<br />
<br />
===Components===<br />
<br />
* (required) The name of the component<br />
* (required) The product it should go in<br />
* (required) A longer description<br />
* (required) A [https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html triage lead], responsible for [https://wiki.mozilla.org/Bugmasters/Process/Triage making decisions] on NEW bugs in the component (optional if not a Firefox component, but recommended)<br />
* (optional) It's highly recommended that the default assignee for new bugs is 'nobody@mozilla.org', however this can be changed if required<br />
* (optional) Normally the "QA Contact" is empty, but you can optionally set it to a specific individual<br />
* (optional) Any flags (bug and/or attachment) that will need to be visible for bugs against the new component<br />
* (optional) The list of [https://bugzilla.mozilla.org/page.cgi?id=review_suggestions.html suggested reviewers] for the review flag (uses the product's review suggestions by default)<br />
<br />
Triage lead, QA contact, and recommended viewers should all be bugmail addresses, so check against Mozillians, Phonebook, or ask to make sure you have the right email.<br />
<br />
===Versions===<br />
<br />
* (required) The name of the version<br />
* (required) The product it should go in<br />
<br />
===Target Milestones===<br />
<br />
* (required) The name of the target milestone<br />
* (required) The product it should go in<br />
<br />
===Custom Fields===<br />
Adding new custom fields is not something we can do easily, so we try to be careful about adding them.<br />
They add more complexity to the UI, and carry an overhead for all bugs on the system, regardless of their visibility. You'll need to make your case before a custom field can be added. Generally, if a custom field is very specific to one niche area and do not concern the Project as a whole, we encourage the use of status whiteboard markers or other existing fields. <br />
* (required) The name of the field<br />
* (required) A longer description<br />
* (required) The type (Bug ID, Large Text Box, Free Text, Multiple Selection Box, Single Selection Box or Date/Time)<br />
* (required) The initial set of values, if Multiple or Single Selection Box<br />
* (required) The product(s) it should show up in<br />
* (required) Whether it can be set on bug creation<br />
<br />
===Keywords===<br />
<br />
Keywords are a faster and typo-free alternative to using whiteboard tags. In order to create one we'll need:<br />
<br />
* (required) The name of the keyword<br />
* (required) The description to use<br />
<br />
===Additional Field Values===<br />
<br />
This could be Hardware or OS.<br />
<br />
* (required) The value to be added<br />
* (required) The field it should be added to<br />
<br />
===Flags===<br />
<br />
* (required) The name of the flag<br />
* (required) A longer description<br />
* (required) Which products/components the flag should appear in<br />
* (required) Whether the flag applies to bugs or attachments<br />
* (required) Whether the flag is requestable (i.e. users can ask for flags of this type to be set)<br />
* (required) Whether the flag should be requested from a specific person<br />
* (required) Whether the flag can be set multiple times<br />
* (optional) If flags of this type are requestable, the group allowed to request them, if any<br />
* (optional) The group allowed to grant/deny flags of this type, if any<br />
* (optional) CC list for request notifications, if any (not recommended, use component watching)<br />
<br />
===Users===<br />
<br />
Users can sign up for accounts themselves.<br />
<br />
===Statuses and Resolutions===<br />
<br />
Changing the Bugzilla workflow is a big deal, and is very unlikely to happen without serious discussion. If you don't know whether you are authorised to make this sort of change, you aren't.<br />
<br />
===Security Groups===<br />
<br />
* Security groups are rarely granted explicitly into. Normally the groups membership is determined by inheritance from other groups.<br />
* Most security groups have a related "-team" group that is used for actually granting people into. For example, no one is in the 'client-services-security' group directly. There is a 'client-services-security-team' group which is a member of the 'client-services-security' group. The individual users are placed directly into the 'client-services-security-team' group when needed. Therefore they get access to the other group as well through inheritance. Only the 'client-services-security' group should be actually visible on the bug report.<br />
<br />
'''Information Needed'''<br />
<br />
* Name for the new group.<br />
* Which products need to have the new group enabled.<br />
* Whether a specific account or mailing list should be automatically cc'ed when a bug is placed in the new group (optional).<br />
* List of users to be placed in the new team group initially.<br />
* Who should be the admin for the new group (bless rights) that will be able place others in the team group (optional).<br />
<br />
==Changes==<br />
<br />
===Changing Product, Component, Version or Milestone Name===<br />
<br />
Bugzilla uses integer mappings internally for mapping IDs to human readable names such as Product, Component, etc. But when creating store queries in the form of a URL or when specifying a product to file a bug against, it doesn't use the ID, it uses the name. When a textual name is changed in BMO using the admin UI to something else, Bugzilla continues to work properly as it still uses the same ID everywhere internally and in the database. But if a stored query or a URL has been passed around to others via a wiki page, mailing list, etc. then the URL will no longer be valid. Users will need to update their queries and revise and relevant documentation to reflect the name change. Bugzilla, and BMO for that matter, does not support aliasing of the new name to any old names so that the old queries will continue to work. BMO admins will try harder to remind requesters that these issues may arise when making these types of name changes.<br />
<br />
Note that this also affects BzAPI or the newer native REST API in that you will need to update the search parameters for bug searches to reflect the name changes as well.<br />
<br />
===Suggested Reviewers===<br />
<br />
A curated list of users can be suggested when the review flag is set for a patch, to aid new contributors in picking a reviewer. These suggested reviewers can be set globally for a product, or on a per-component basis. For the current list of users, see the [https://bugzilla.mozilla.org/page.cgi?id=review_suggestions.html suggested reviewers report].<br />
<br />
===Usernames and Passwords===<br />
<br />
Users can change their own username (email address) or password in the preferences. Changing your own email address is greatly preferred to creating a new account and then asking for a merge. If you have already created a new account but have not yet used it, then change its username to something bogus (i.e. abandon it), and change the username on your old account to the new one.<br />
<br />
If you do need two accounts merged, and both have activity you don't want to lose, you will need to file a bug (see above).<br />
<br />
===Retiring Products and Components===<br />
<br />
Products and components aren't deleted from Bugzilla, since the records of their bugs or the work done on them may be useful. Instead, usually they are changed to disable the creation of new bugs in their category. They can also be moved to a "Graveyard" area.<br />
<br />
Here's [[BMO/RetiringComponents|how to retire components and products]].<br />
<br />
===User Permissions===<br />
<br />
For common user permissions, i.e. canconfirm and editbugs, please see the [instructions on BMO itself https://bugzilla.mozilla.org/page.cgi?id=get_permissions.html]. For other permissions, e.g. security groups, please file a confidential bug or contact the BMO team.<br />
<br />
==Disablings==<br />
<br />
===Users===<br />
<br />
Email bugzilla-admin@mozilla.org giving sufficient evidence of violation of Mozilla policies or community norms.<br />
<br />
===Versions===<br />
<br />
===Target Milestones===<br />
<br />
Old target milestones are normally disabled by the team at some point after the release has happened. This means that they can't be selected on bugs (although they will continue to show up if that's the current value) and you have to use the Boolean Charts to search for them.<br />
<br />
==Deletions==<br />
<br />
Things in Bugzilla rarely get deleted. Many things can be disabled (see above) instead. You should not expect deletions to happen fast. It's probably best to file a bug explaining what you need deleted and why, and expect questions.<br />
<br />
===Attachments===<br />
<br />
If you add an attachment and then realise it contains confidential or personal information, file a bug and it can be manually annulled. (The attachment links and name will remain, but the data will be removed.)<br />
<br />
===Users===<br />
<br />
We don't delete accounts because that would be messing with the historical record. However, users can disable all their bug mail in their preferences if they would like to stop hearing from Bugzilla, and they may change their email address to an inactive or throwaway one if they wish.<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=Firefox/firefox-dev&diff=1215310Firefox/firefox-dev2019-07-18T23:37:06Z<p>Emceeaich: /* Moderation Policy */ Link to CPG and inclusion.</p>
<hr />
<div>==Goals==<br />
[https://mail.mozilla.org/listinfo/firefox-dev firefox-dev] is a mailing list with one explicit goal:<br />
<br />
* Offer an easy, transparent venue for getting constructive, Firefox-related development work done and providing development status updates.<br />
<br />
and some explicit non-goals:<br />
* It does not offer community members the chance to post until they get satisfaction about their concerns.<br />
* It is not a suitable forum for requesting or offering technical support for users of Firefox<br />
* It is not a suitable forum for unsolicited Firefox feature requests or suggestions<br />
<br />
Topics related to add-on development in Firefox are best asked on the [https://mail.mozilla.org/listinfo/dev-addons dev-addons] list.<br />
<br />
==Subscribe==<br />
You can subscribe [https://mail.mozilla.org/listinfo/firefox-dev from the mailman info page].<br />
<br />
==Moderation Policy==<br />
firefox-dev is a moderated list:<br />
<br />
* Participants must abide by Mozilla's [https://www.mozilla.org/about/governance/policies/participation/ Community Participation Guidelines]<br />
* Anyone can subscribe and read the messages<br />
* Anyone can post. By default, posts will be reviewed by a moderator before being sent to the list<br />
* A smaller number of contributors will be added to a whitelist, and their postings will go directly to the list without having to first be reviewed by a moderator<br />
* Posts which are ranting, venting, and being unnecessarily argumentative may not go to the list<br />
<br />
Messages need to abide by two simple rules to be approved by the moderators:<br />
<br />
* Be nice (in other words, no personal attacks, ranting, etc.)<br />
* Be constructive (in other words, no whining, repetition, venting, etc.) <br />
<br />
Whitelist membership is subject to temporary or permanent suspension. Abuse or conduct complaints should be sent to <firefox-dev-owner@mozilla.org> or <inclusion@mozilla.com>.<br />
<br />
This policy is expected to evolve at the discretion of the list-owner (<firefox-dev-owner@mozilla.org>).<br />
<br />
==Archives==<br />
There are read-only archives available:<br />
* [https://groups.google.com/forum/?fromgroups=&hl=en#!forum/firefox-dev via Google Groups]<br />
* [http://dir.gmane.org/gmane.comp.mozilla.firefox.devel provided by Gmane (including NNTP support)]<br />
* [https://mail.mozilla.org/pipermail/firefox-dev/ on the web, via mailman]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide&diff=1215014BMO/UserGuide2019-07-12T23:46:57Z<p>Emceeaich: /* Status Flags */ add product flags</p>
<hr />
<div>[[File:Bmo-introduction-video.png|thumb|Understanding Mozilla: Bugzilla|link=https://gerv.makes.org/popcorn/1bn6]]<br />
<br />
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.<br />
<br />
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!<br />
<br />
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!<br />
<br />
= BMO vs Bugzilla =<br />
<br />
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.<br />
<br />
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]].<br />
<br />
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].<br />
<br />
=Creating a Bugzilla Account=<br />
<br />
To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.<br />
<br />
==Create a Local Account==<br />
<br />
From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.<br />
<br />
==Log in With GitHub==<br />
<br />
If you have a GitHub account you can use it to log in and create an account.<br />
<br />
* First click "Log in".<br />
* Then click the Octocat/GitHub logo. <br />
* If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.<br />
* If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.<br />
* You'll be identified by the email address you use on GitHub.<br />
<br />
'''Note:''' If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.<br />
<br />
= Searching =<br />
''Omg, so many ways to search; why do we have so many, and how do they work?''<br />
<br />
== Quick Search ==<br />
''Quick Search rocks! You should use it.''<br />
<br />
== Advanced Search, Pronouns ==<br />
''Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.''<br />
<br />
== Other Searches (Instant, Simple, Google) ==<br />
''In case you were looking for more ways to search.''<br />
<br />
= Bugmail =<br />
<br />
''Bugmail'' is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.<br />
<br />
== Filtering ==<br />
''Too much bugmail? Filter on BMO itself and/or via x-headers!''<br />
<br />
=== Filtering with GMail ===<br />
GMail's ability to filter on headers is somewhat limited. We've got a separate, complete [[/Filtering Bugzilla Email in GMail|guide]] on advanced bugmail filtering with GMail.<br />
<br />
= Users =<br />
<br />
Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.<br />
<br />
== User Profiles ==<br />
<br />
By selecting [https://bugzilla.mozilla.org/user_profile My Profile] from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.<br />
<br />
There's a [[BMO/UserProfiles|project page]] about User Profiles which has brief description of the fields.<br />
<br />
== "New to Bugzilla" ==<br />
<br />
A user's comments will be tagged as "New to Bugzilla" under the following conditions:<br />
* The user does ''not'' have editbugs access.<br />
* The user has made 25 comments or less '''OR''' the account is less than 60 days old.<br />
<br />
The "New to Bugzilla" indicator doesn't mean ''this account was created recently'', it's an indicator that ''this user hasn't used Bugzilla much, please tailor your responses accordingly''.<br />
<br />
This is only displayed to people with canconfirm or editbugs access.<br />
<br />
= Understanding, Editing, and Filing Bugs =<br />
<br />
== Standard Bug Fields ==<br />
Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described [[BMO/UserGuide/BugFields|here]].<br />
<br />
== Comment Tagging ==<br />
''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.''<br />
<br />
== Keywords and the Whiteboard ==<br />
''What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?''<br />
<br />
'''Keywords''':<br />
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.<br />
<br />
'''Whiteboard''':<br />
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.<br />
<br />
== Tracking Flags ==<br />
''Who's doing the tracking? Should i even set these flags?''<br />
<br />
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.<br />
<br />
[[File:Tracking-flag-example.png|thumb]]<br />
<br />
Tracking flags have the values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value !! Meaning<br />
|-<br />
| --- || Default/Not nominated<br />
|-<br />
| ? || Bug is nominated for this release<br />
|-<br />
| + || Bug is tracked for this release<br />
|-<br />
| - || Bug will not be tracked for this release<br />
|-<br />
| blocking || Bug is considered a blocker for this release<br />
|}<br />
<br />
Most users will only be able to [[Release_Management/Release_Process#All_about_Flags|nominate a bug for tracking]] by setting the tracking flag for a release to ''?''. The Release Drivers group (which includes Release Management) will respond to the request for tracking.<br />
<br />
For example, a [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_beta&o1=equals&v1=%2B search for tracking Firefox Beta and "+"] would list the bugs which release managers decided to track for the Beta release of Firefox. <br />
<br />
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.<br />
<br />
== Status Flags ==<br />
<br />
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]. <br />
<br />
[[File:Status-flag-example.png|Thumb]]<br />
<br />
== Project Flags == <br />
<br />
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.<br />
<br />
== Needinfo Flag ==<br />
''It's good and you should use it.''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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].<br />
<br />
= Other Ways to use BMO and its Data =<br />
<br />
== Whining ==<br />
''Bugzilla can automatically send you buglists (requires canconfirm).''<br />
<br />
BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to [https://bugzilla.mozilla.org/editwhines.cgi create whines].<br />
<br />
== APIs ==<br />
''I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.''<br />
<br />
BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found [http://bmo.readthedocs.io/en/latest/api/index.html here].<br />
<br />
== Dashboards ==<br />
''Trying to answer the "what should i do today" question? Go no further than the dashboards.''<br />
<br />
[https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard] has some nice options for viewing lists of bugs that may be of interest to you.<br />
<br />
=Permissions and Groups=<br />
<br />
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org. <br />
<br />
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive. <br />
<br />
==How to apply for upgraded permissions==<br />
<br />
If you want '''canconfirm''', you can add it yourself using [https://bugzilla.mozilla.org/page.cgi?id=triage_request.html triage request form].<br />
<br />
If you want '''editbugs''', [https://mzl.la/2izLT4J file a new bug, including]:<br />
<br />
* The URLs of two bugs to which you have attached patches or testcases.<br />
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.<br />
<br />
'''Note:''' '''editbugs''' implies '''canconfirm''' there's no need to apply for both.<br />
<br />
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group '''everyone'''. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.<br />
<br />
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide&diff=1215013BMO/UserGuide2019-07-12T23:43:21Z<p>Emceeaich: /* Tracking Flags */ add status flag docs</p>
<hr />
<div>[[File:Bmo-introduction-video.png|thumb|Understanding Mozilla: Bugzilla|link=https://gerv.makes.org/popcorn/1bn6]]<br />
<br />
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.<br />
<br />
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!<br />
<br />
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!<br />
<br />
= BMO vs Bugzilla =<br />
<br />
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.<br />
<br />
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]].<br />
<br />
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].<br />
<br />
=Creating a Bugzilla Account=<br />
<br />
To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.<br />
<br />
==Create a Local Account==<br />
<br />
From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.<br />
<br />
==Log in With GitHub==<br />
<br />
If you have a GitHub account you can use it to log in and create an account.<br />
<br />
* First click "Log in".<br />
* Then click the Octocat/GitHub logo. <br />
* If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.<br />
* If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.<br />
* You'll be identified by the email address you use on GitHub.<br />
<br />
'''Note:''' If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.<br />
<br />
= Searching =<br />
''Omg, so many ways to search; why do we have so many, and how do they work?''<br />
<br />
== Quick Search ==<br />
''Quick Search rocks! You should use it.''<br />
<br />
== Advanced Search, Pronouns ==<br />
''Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.''<br />
<br />
== Other Searches (Instant, Simple, Google) ==<br />
''In case you were looking for more ways to search.''<br />
<br />
= Bugmail =<br />
<br />
''Bugmail'' is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.<br />
<br />
== Filtering ==<br />
''Too much bugmail? Filter on BMO itself and/or via x-headers!''<br />
<br />
=== Filtering with GMail ===<br />
GMail's ability to filter on headers is somewhat limited. We've got a separate, complete [[/Filtering Bugzilla Email in GMail|guide]] on advanced bugmail filtering with GMail.<br />
<br />
= Users =<br />
<br />
Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.<br />
<br />
== User Profiles ==<br />
<br />
By selecting [https://bugzilla.mozilla.org/user_profile My Profile] from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.<br />
<br />
There's a [[BMO/UserProfiles|project page]] about User Profiles which has brief description of the fields.<br />
<br />
== "New to Bugzilla" ==<br />
<br />
A user's comments will be tagged as "New to Bugzilla" under the following conditions:<br />
* The user does ''not'' have editbugs access.<br />
* The user has made 25 comments or less '''OR''' the account is less than 60 days old.<br />
<br />
The "New to Bugzilla" indicator doesn't mean ''this account was created recently'', it's an indicator that ''this user hasn't used Bugzilla much, please tailor your responses accordingly''.<br />
<br />
This is only displayed to people with canconfirm or editbugs access.<br />
<br />
= Understanding, Editing, and Filing Bugs =<br />
<br />
== Standard Bug Fields ==<br />
Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described [[BMO/UserGuide/BugFields|here]].<br />
<br />
== Comment Tagging ==<br />
''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.''<br />
<br />
== Keywords and the Whiteboard ==<br />
''What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?''<br />
<br />
'''Keywords''':<br />
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.<br />
<br />
'''Whiteboard''':<br />
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.<br />
<br />
== Tracking Flags ==<br />
''Who's doing the tracking? Should i even set these flags?''<br />
<br />
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.<br />
<br />
[[File:Tracking-flag-example.png|thumb]]<br />
<br />
Tracking flags have the values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value !! Meaning<br />
|-<br />
| --- || Default/Not nominated<br />
|-<br />
| ? || Bug is nominated for this release<br />
|-<br />
| + || Bug is tracked for this release<br />
|-<br />
| - || Bug will not be tracked for this release<br />
|-<br />
| blocking || Bug is considered a blocker for this release<br />
|}<br />
<br />
Most users will only be able to [[Release_Management/Release_Process#All_about_Flags|nominate a bug for tracking]] by setting the tracking flag for a release to ''?''. The Release Drivers group (which includes Release Management) will respond to the request for tracking.<br />
<br />
For example, a [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_beta&o1=equals&v1=%2B search for tracking Firefox Beta and "+"] would list the bugs which release managers decided to track for the Beta release of Firefox. <br />
<br />
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.<br />
<br />
== Status Flags ==<br />
<br />
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]. <br />
<br />
[[File:Status-flag-example.png|Thumb]]<br />
<br />
== Needinfo Flag ==<br />
''It's good and you should use it.''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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].<br />
<br />
= Other Ways to use BMO and its Data =<br />
<br />
== Whining ==<br />
''Bugzilla can automatically send you buglists (requires canconfirm).''<br />
<br />
BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to [https://bugzilla.mozilla.org/editwhines.cgi create whines].<br />
<br />
== APIs ==<br />
''I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.''<br />
<br />
BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found [http://bmo.readthedocs.io/en/latest/api/index.html here].<br />
<br />
== Dashboards ==<br />
''Trying to answer the "what should i do today" question? Go no further than the dashboards.''<br />
<br />
[https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard] has some nice options for viewing lists of bugs that may be of interest to you.<br />
<br />
=Permissions and Groups=<br />
<br />
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org. <br />
<br />
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive. <br />
<br />
==How to apply for upgraded permissions==<br />
<br />
If you want '''canconfirm''', you can add it yourself using [https://bugzilla.mozilla.org/page.cgi?id=triage_request.html triage request form].<br />
<br />
If you want '''editbugs''', [https://mzl.la/2izLT4J file a new bug, including]:<br />
<br />
* The URLs of two bugs to which you have attached patches or testcases.<br />
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.<br />
<br />
'''Note:''' '''editbugs''' implies '''canconfirm''' there's no need to apply for both.<br />
<br />
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group '''everyone'''. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.<br />
<br />
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=File:Status-flag-example.png&diff=1215012File:Status-flag-example.png2019-07-12T23:42:33Z<p>Emceeaich: </p>
<hr />
<div>How status flags are displayed in Bugzilla</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide&diff=1215011BMO/UserGuide2019-07-12T23:30:45Z<p>Emceeaich: /* Tracking Flags */ https://bugzilla.mozilla.org/show_bug.cgi?id=1561431</p>
<hr />
<div>[[File:Bmo-introduction-video.png|thumb|Understanding Mozilla: Bugzilla|link=https://gerv.makes.org/popcorn/1bn6]]<br />
<br />
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.<br />
<br />
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!<br />
<br />
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!<br />
<br />
= BMO vs Bugzilla =<br />
<br />
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.<br />
<br />
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]].<br />
<br />
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].<br />
<br />
=Creating a Bugzilla Account=<br />
<br />
To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.<br />
<br />
==Create a Local Account==<br />
<br />
From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.<br />
<br />
==Log in With GitHub==<br />
<br />
If you have a GitHub account you can use it to log in and create an account.<br />
<br />
* First click "Log in".<br />
* Then click the Octocat/GitHub logo. <br />
* If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.<br />
* If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.<br />
* You'll be identified by the email address you use on GitHub.<br />
<br />
'''Note:''' If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.<br />
<br />
= Searching =<br />
''Omg, so many ways to search; why do we have so many, and how do they work?''<br />
<br />
== Quick Search ==<br />
''Quick Search rocks! You should use it.''<br />
<br />
== Advanced Search, Pronouns ==<br />
''Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.''<br />
<br />
== Other Searches (Instant, Simple, Google) ==<br />
''In case you were looking for more ways to search.''<br />
<br />
= Bugmail =<br />
<br />
''Bugmail'' is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.<br />
<br />
== Filtering ==<br />
''Too much bugmail? Filter on BMO itself and/or via x-headers!''<br />
<br />
=== Filtering with GMail ===<br />
GMail's ability to filter on headers is somewhat limited. We've got a separate, complete [[/Filtering Bugzilla Email in GMail|guide]] on advanced bugmail filtering with GMail.<br />
<br />
= Users =<br />
<br />
Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.<br />
<br />
== User Profiles ==<br />
<br />
By selecting [https://bugzilla.mozilla.org/user_profile My Profile] from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.<br />
<br />
There's a [[BMO/UserProfiles|project page]] about User Profiles which has brief description of the fields.<br />
<br />
== "New to Bugzilla" ==<br />
<br />
A user's comments will be tagged as "New to Bugzilla" under the following conditions:<br />
* The user does ''not'' have editbugs access.<br />
* The user has made 25 comments or less '''OR''' the account is less than 60 days old.<br />
<br />
The "New to Bugzilla" indicator doesn't mean ''this account was created recently'', it's an indicator that ''this user hasn't used Bugzilla much, please tailor your responses accordingly''.<br />
<br />
This is only displayed to people with canconfirm or editbugs access.<br />
<br />
= Understanding, Editing, and Filing Bugs =<br />
<br />
== Standard Bug Fields ==<br />
Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described [[BMO/UserGuide/BugFields|here]].<br />
<br />
== Comment Tagging ==<br />
''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.''<br />
<br />
== Keywords and the Whiteboard ==<br />
''What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?''<br />
<br />
'''Keywords''':<br />
These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.<br />
<br />
'''Whiteboard''':<br />
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.<br />
<br />
== Tracking Flags ==<br />
''Who's doing the tracking? Should i even set these flags?''<br />
<br />
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.<br />
<br />
[[File:Tracking-flag-example.png|thumb]]<br />
<br />
Tracking flags have the values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value !! Meaning<br />
|-<br />
| --- || Default/Not nominated<br />
|-<br />
| ? || Bug is nominated for this release<br />
|-<br />
| + || Bug is tracked for this release<br />
|-<br />
| - || Bug will not be tracked for this release<br />
|-<br />
| blocking || Bug is considered a blocker for this release<br />
|}<br />
<br />
Most users will only be able to [[Release_Management/Release_Process#All_about_Flags|nominate a bug for tracking]] by setting the tracking flag for a release to ''?''. The Release Drivers group (which includes Release Management) will respond to the request for tracking.<br />
<br />
For example, a [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_tracking_firefox_beta&o1=equals&v1=%2B search for tracking Firefox Beta and "+"] would list the bugs which release managers decided to track for the Beta release of Firefox. <br />
<br />
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.<br />
<br />
== Needinfo Flag ==<br />
''It's good and you should use it.''<br />
<br />
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.<br />
<br />
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. <br />
<br />
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].<br />
<br />
= Other Ways to use BMO and its Data =<br />
<br />
== Whining ==<br />
''Bugzilla can automatically send you buglists (requires canconfirm).''<br />
<br />
BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to [https://bugzilla.mozilla.org/editwhines.cgi create whines].<br />
<br />
== APIs ==<br />
''I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.''<br />
<br />
BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found [http://bmo.readthedocs.io/en/latest/api/index.html here].<br />
<br />
== Dashboards ==<br />
''Trying to answer the "what should i do today" question? Go no further than the dashboards.''<br />
<br />
[https://bugzilla.mozilla.org/page.cgi?id=mydashboard.html My Dashboard] has some nice options for viewing lists of bugs that may be of interest to you.<br />
<br />
=Permissions and Groups=<br />
<br />
If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org. <br />
<br />
The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive. <br />
<br />
==How to apply for upgraded permissions==<br />
<br />
If you want '''canconfirm''', you can add it yourself using [https://bugzilla.mozilla.org/page.cgi?id=triage_request.html triage request form].<br />
<br />
If you want '''editbugs''', [https://mzl.la/2izLT4J file a new bug, including]:<br />
<br />
* The URLs of two bugs to which you have attached patches or testcases.<br />
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.<br />
<br />
'''Note:''' '''editbugs''' implies '''canconfirm''' there's no need to apply for both.<br />
<br />
There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group '''everyone'''. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.<br />
<br />
You can see your current [https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions groups and permissions].<br />
<br />
[[Category:BMO]]</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=File:Tracking-flag-example.png&diff=1215010File:Tracking-flag-example.png2019-07-12T23:13:55Z<p>Emceeaich: </p>
<hr />
<div>Example of tracking flag displayed in Bugzilla</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=MDN/Development/Bug_triage_guidelines&diff=1214908MDN/Development/Bug triage guidelines2019-07-10T22:34:22Z<p>Emceeaich: /* Platform issues */ update definitions</p>
<hr />
<div>=MDN Bug Triage Guidelines=<br />
<br />
* IRC: #mdn<br />
* Triage meeting Vidyo: MDN VIDYO ROOM<br />
<br />
; How do we know a bug is triaged?<br />
: It has the "in-triage" keyword set<br />
<br />
; What bugs need triaging?<br />
: The last 15 days of bugs not in Code Cleanup component, not having "in-triage" keyword: https://mzl.la/2NE0zgP<br />
<br />
; Any other good guidelines?<br />
: Plenty! https://wiki.gnome.org/Bugsquad/TriageGuide#Eight_Quick_Steps_to_Triage_Nirvana<br />
<br />
(Details below)<br />
<br />
Action items:<br />
<br />
<br />
==Severity==<br />
<br />
===Platform issues===<br />
;Blocker: Broken important user-facing feature, Blocks development and/or testing work<br />
;Critical: Affecting a large number of users, or major areas of functionality<br />
;Normal: Default; Regular issue, some loss of functionality under specific circumstances<br />
;Minor: Affecting a small number of users, a problem with an easy workaround, or a cosmetic issue such as misspellings or text alignment<br />
<br />
===Usability issues===<br />
Needs a specialist's eye<br />
<br />
===Accessibility issues===<br />
Needs a specialist's eye<br />
<br />
<br />
==Priorities==<br />
; P1 : "We have to fix this before we are done. We will lose substantial visitors, contributors, or money if we don't."<br />
<br />
; P2 : "We'd like to fix this before we are done. It might perturb some customers, but we don't think they'll throw out the product or move to our competitors. If we don't fix it before we are done, we either have to do something to that module or fix it in the next release."<br />
<br />
; P3 : "Minor: We'd like to fix this before we throw out this product."<br />
<br />
==Common Keywords==<br />
; productwanted : For features that need a Keep/WontFix decision from a product manager. You do not have to needinfo the PM, just use the keyword.<br />
; access : Bugs and enhancement requests related to making Mozilla accessible to users with disabilities and special needs.<br />
; mobile For bugs which are important to mobile developmental work.<br />
; rtl : A bug tied to or exposed by languages with a right-to-left (RTL) writing system.<br />
; meta : A placeholder bug for tracking the progress of other bugs. Meta bugs are made dependent on other bugs so that interested parties can be kept up-to-date with status via one bug, without having to receive all the mails related to all the bugs related to the development of a particular area.<br />
; perf : This bug is about a site performance issue: response times, page load times, etc. For SEO performance issues, use the [seo] whiteboard flag.<br />
<br />
==Whiteboard Flags==<br />
<br />
; [good first bug] : Another way to specify simple bugs that may not have a mentor.<br />
; [dev-papercut] : Technical Debt that the engineering team would like to fix.<br />
; [might-expire] : Bugs where the bug triager has requested feedback via needinfo and they are waiting for a response. If the response does not come in a reasonable (2-6 weeks, depending on the bug) amount of time, then the issue can be closed. Typically used for bugs more than 12 months old.<br />
[closeme?] This tag means that people who are looking at the bug (triagers, qa people, others) are not sure if this bug can be closed. <br />
; [closeme yyyy-MM-dd] : this tag means that the bug can be closed after the date reported. Good when used with the INCOMPLETE status after a reasonable (2-6 weeks) of time waiting for a response.<br />
[dupeme?] This bug might be a duplicate, but the triager isn't sure - you can help by finding it for them<br />
; [needs-component] : You've triaged a bug in General, but you're not sure where it belongs. Advanced triagers/core devs can give you a hand finding the right place.<br />
; [newlang] : A request for a new language locale in MDN - these bugs should be refiled in the Localization component, too<br />
; [support] : A user support request filed in our bug tracker: e.g. email missing from login, lost my email, etc.<br />
; [LOE] : The estimated level of effort this might require, in days. [LOE:?] indicates a request for an estimate. [LOE:3] is an estimate the bug will take 3 days to complete.<br />
<br />
==DEPRECATED==<br />
; [mentor=YOURNAMEHERE] : Bugs or features that you are willing to help a community member develop. Good for small and starter bugs. DEPRECATED: use the mentor field<br />
; [performance] : This bug is about a site performance issue. DEPRECATED: use the 'perf' keyword<br />
[pm-wanted] The MDN Product Manager should evaluate this feature. They will remove the tag when they are done. DEPRECATED: Use the productwanted keyword<br />
; [type:feature] : We use this to track all feature requests. If a bug is obviously a feature request and this tag is missing, then please add it. (DEPRECATED in favour of Severity:enhancement)<br />
; [seo] : This bug pertains to Search Engine Optimization on MDN (DEPRECATED: Use Component:Search Engine Optimization)<br />
; [opportunity] : Ideas that we want to put through the experimental opportunity evaluation process. (DEPRECATED: Use the productwanted keyword)</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/UserGuide/BugFields&diff=1214907BMO/UserGuide/BugFields2019-07-10T22:30:40Z<p>Emceeaich: /* Bugzilla Field Descriptions */ update severity field</p>
<hr />
<div>== Bugzilla Field Descriptions ==<br />
<br />
{{anchor|alias}}<br />
; Alias<br />
: A short, unique name assigned to a bug in order to assist with looking it up and referring to it in other places in Bugzilla.<br />
{{anchor|assigned_to}}<br />
; Assignee<br />
: This is the person in charge of resolving the bug. Every time this field changes, the status changes to NEW to make it easy to see which new bugs have appeared on a person's list.<br />
{{anchor|blocks}}<br />
; Blocks<br />
: This bug must be resolved before the bugs listed in this field can be resolved.<br />
{{anchor|bug_id}}<br />
; Bug ID<br />
: The numeric id of a bug, unique within this entire installation of Bugzilla.<br />
{{anchor|cc}}<br />
; CC<br />
: Users who may not have a direct role to play on this bug, but who are interested in its progress.<br />
{{anchor|delta_ts}}<br />
; Changed<br />
: When this bug was last updated.<br />
{{anchor|classification}}<br />
; Classification<br />
: Bugs are categorised into Classifications, Products and Components. classifications is the top-level categorization.<br />
{{anchor|comment}}<br />
; Comment<br />
: Bugs have comments added to them by Bugzilla users. You can search for some text in those comments.<br />
{{anchor|comment_tag}}<br />
; Comment Tag<br />
: Comments can have arbitrary tags added to them to help with filtering as well as mark comments as spam or abusive. <br />
{{anchor|component}}<br />
; Component<br />
: Components are second-level categories; each belongs to a particular Product. Select a Product to narrow down this list.<br />
{{anchor|creation_ts}}<br />
; Creation date<br />
: When the bug was filed.<br />
{{anchor|dependson}}<br />
; Depends on<br />
: The bugs listed here must be resolved before this bug can be resolved.<br />
{{anchor|duplicates}}<br />
; Duplicates<br />
: List of bugs that have been marked a duplicate of the bug currently being viewed.<br />
{{anchor|rep_platform}}<br />
; Hardware<br />
: This is the hardware platform against which the bug was reported.<br />
{{anchor|importance}}<br />
; Importance<br />
: The importance of a bug is described as the combination of its Priority and Severity.<br />
{{anchor|keywords}}<br />
; Keywords<br />
: Keywords are a controlled vocabulary for characterizing bugs across Products and Components. Examples of this field are <code>regression</code>, <code>sec-high</code>, and <code>topcrash</code>. Bugzilla administrators manage [https://bugzilla.mozilla.org/describekeywords.cgi the list of keywords]. If you believe you need a new keyword, [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration please contact the administrators to discuss]. <br />
{{anchor|bug_mentor}}<br />
; Mentors<br />
: Mentors are users who have offered to help the bug owner with such tasks as setting up a development environment, finding relevant information to fixing the bug, how to submit a patch for review, and finally how to get the fix committed.<br />
{{anchor|needinfo}}<br />
; Needinfo<br />
: More information has been requested from specific individuals, or anyone, to move the bug forward to completion.<br />
{{anchor|op_sys}}<br />
; OS<br />
: This is the operating system against which the bug was reported.=<br />
{{anchor|priority}}<br />
; Priority<br />
: This field describes the importance and order in which a bug should be fixed compared to other bugs. This field is utilized by the programmers/engineers/release managers/managers to prioritize the work to be done. See [https://mozilla.github.io/bug-handling/triage-bugzilla the Firefox triage documentation] or for the main Bugzilla project, [[Bugzilla:Priority_System]].<br />
{{anchor|product}}<br />
; Product<br />
: Bugs are categorised into Products and Components. Select a Classification to narrow down this list.<br />
{{anchor|qa_contact}}<br />
; QA Contact<br />
: The person responsible for confirming this bug if it is unconfirmed, and for verifying the fix once the bug has been resolved.<br />
{{anchor|rank}}<br />
; Rank<br />
: Used by some groups to provide finer-grained ordering for working on bugs than afforded by the Priority field. Use of this field is restricted to the `rank-setters` group.<br />
{{anchor|regressed_by}}<br />
; Regressed by<br />
: This bug has been introduced by the bugs listed here.<br />
{{anchor|regresses}}<br />
; Regressions<br />
: This bug has introduced the bugs listed here.<br />
{{anchor|reporter}}<br />
; Reporter<br />
: The person who filed this bug.<br />
{{anchor|see_also}}<br />
; See Also<br />
: This allows you to refer to bugs in other bug tracker installations. You can enter a URL to a bug in the 'Add Bug URLs' field to note that that bug is related to this one. You can enter multiple URLs at once by separating them with a comma. You should normally use this field to refer to bugs in other bug tracker installations. For bugs in this bug tracker installation, it is better to use the Depends on and Blocks fields.<br />
{{anchor|bug_severity}}<br />
; Severity<br />
: This field describes the impact of a bug.<br />
{| class="wikitable"<br />
|'''blocker'''<br />
|Broken important user-facing feature, Blocks development and/or testing work<br />
|-<br />
|'''critical'''<br />
|Affecting a large number of users (all users on AMD64, Windows, MacOS, Linux), or major areas of functionality (tls, DOM, JavaScript, FxA, Add-ons)<br />
|-<br />
|'''normal'''<br />
|Default; Regular issue, some loss of functionality under specific circumstances<br />
|-<br />
|'''minor'''<br />
|Affecting a small number of users (i.e. ArchLinux users on PowerPC), a problem with an easy workaround, or a cosmetic issue such as misspellings or text alignment<br />
|} <br />
{{anchor|short_desc}}<br />
; Summary<br />
: The bug summary is a short sentence which succinctly describes what the bug is about.<br />
{{anchor|target_milestone}}<br />
; Target Milestone<br />
: For Firefox-related bugs, when a change set (patch) lands in Mozilla-Central, the [[Sheriffing|sheriffs]] will set this field to the corresponding release value for the current Nightly.<br />
: Release status and tracking flags are used to mark intentions for when a fix or other patch should land. <br />
: If you need to track a bug against a set of milestones other than upcoming versions of Firefox, please tell the Bugzilla team, you may want a custom status flag. <br />
{{anchor|triage_owner}}<br />
; Triage Owner<br />
: User that is responsible [https://mozilla.github.io/bug-handling/triage-bugzilla for triaging bugs in a specific component].<br />
{{anchor|bug_type}}<br />
; Type<br />
: This field describes the [https://mozilla.github.io/bug-handling/bug-types type of a bug].<br />
{| class="wikitable"<br />
|-<br />
|'''defect'''<br />
|regression, crash, hang, security vulnerability and any other general issue.<br />
|-<br />
|'''enhancement'''<br />
|new feature, improvement in UI, performance, etc. and any other request for user-facing changes and enhancements in the product; not engineering changes<br />
|-<br />
|'''task'''<br />
|refactoring, removal, replacement, enabling or disabling of functionality and any other engineering task<br />
|} <br />
{{anchor|bug_file_loc}}<br />
; URL<br />
: Bugs can have a URL associated with them - for example, a pointer to a web site where the problem is seen.<br />
{{anchor|version}}<br />
; Version<br />
: The version field defines the version of the software the bug was found in.<br />
{{anchor|votes}}<br />
; Votes<br />
: Some bugs can be voted for, and you can limit your search to bugs with more than a certain number of votes. Votes are not used by Mozilla developers to set priorities.<br />
{{anchor|status_whiteboard}}<br />
; Whiteboard<br />
: Each bug has a free-form single line text entry box for adding tags and status information</div>Emceeaichhttps://wiki.mozilla.org/index.php?title=BMO/new-version&diff=1214796BMO/new-version2019-07-08T23:38:08Z<p>Emceeaich: /* Versions */ correct template for testing</p>
<hr />
<div>{{note|These activities should be completed before or at the same time we have the merge for the next major release of Firefox.}}<br />
<br />
{{warning|There are several steps to the process and care must be taken.}}<br />
<br />
= Adding a new "rapid release" version to Firefox/Core/Thunderbird = <br />
<br />
== Bugzilla Ticket ==<br />
<br />
During the [[RapidRelease/Calendar|days before a merge date]] check in with the Release Management team and ask when they want to increment the fields.<br />
<br />
# Look for a bug with the title ''release tracking flag refresh (<code>version</code>)''<br />
# If you don't find it, clone the bug for the most recent version<br />
# If you still can't find it [https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration create] a BMO:: Administration bug to track the new versions/milestones<br />
# Use subject: ''release tracking flag refresh (<code>version</code>)''<br />
<br />
== Status and Release Flags == <br />
<br />
The flags for release status and tracking are created with the [https://bugzilla.mozilla.org/page.cgi?id=tracking_flags_admin_list.html release tracking flags administration page], not the "custom fields" page.<br />
<br />
* Create a copy of the current release's version of the following flags, updating the name and sort-order:<br />
** copy cf_tracking_firefox''N'' to cf_tracking_firefox''N+1''<br />
** copy cf_status_firefox''N'' to cf_status_firefox''N+1''<br />
<br />
Only members of the <code>mozilla-next-drivers</code> group may set a tracking flag to something other than ''?''. Members of the <code>canconfirm</code> group can set status flags or set a tracking flag to ''?''.<br />
<br />
** copy cf_tracking_thunderbird''N'' to cf_tracking_thunderbird''N+1''<br />
** copy cf_status_thunderbird''N'' to cf_status_thunderbird''N_1''<br />
* edit the flags for previous (now released) versions (N-3) and uncheck 'active':<br />
** cf_tracking_firefox''N-3''<br />
** cf_status_firefox''N-3''<br />
** cf_tracking_thunderbird''N-3''<br />
** cf_status_thunderbird''N-3''<br />
<br />
* update cf_tracking_firefox_relnote (which is relnote-firefox in the UI) (add N+1, disable N-3 except for ESR)<br />
* update the current esr tracking field: cf_tracking_firefox_esr* (add N+2)<br />
<br />
== Milestones ==<br />
<br />
* Use the [https://bugzilla.mozilla.org/editmilestones.cgi milestone admin page] to add new milestones<br />
* The template strings listed may not be the only forms of string in the lists of milestones<br />
* Move the --- milestone marker to between N-1 and N for all products where a milestone was added<br />
* Leave all milestones from most recent ESR to nightly (and '---' and 'Future') active. Disable others <br />
* ''Don't delete old milestones''<br />
<br />
=== Products ===<br />
<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Chat%20Core Chat Core]: "Instantbird N"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Cloud%20Services Cloud Services]: "Firefox N"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Core Core]: "mozillaN"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=DevTools DevTools]: "Firefox N"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox Firefox]: "Firefox N"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox%20Build%20System Firefox Build System]: "mozillaN"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Firefox%20for%20Android Firefox for Android]: "Firefox N"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=GeckoView GeckoView]: "N Branch"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=MailNews%20Core MailNews Core]: "Thunderbird N.0"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=SeaMonkey SeaMonkey]: "SeaMonkey N.0"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Taskcluster Taskcluster]: "mozillaN'<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Testing Testing]: "mozillaN"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Thunderbird Thunderbird]: "Thunderbird N.0"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=Toolkit Toolkit]: "mozillaN"<br />
* [https://bugzilla.mozilla.org/editmilestones.cgi?product=WebExtensions WebExtensions]: "mozillaN"<br />
<br />
== Versions ==<br />
<br />
Use the [https://bugzilla.mozilla.org/editversions.cgi version admin page] to add new versions.<br />
<br />
{{TODO|What's missing from this list? What should be removed?}}<br />
<br />
* Chat Core "NN"<br />
* Cloud Services: "NN Branch"<br />
* Core: "NN Branch"<br />
* DevTools: "NN Branch"<br />
* Firefox: "NN Branch"<br />
* Firefox Build System: "NN Branch"<br />
* Firefox for Android: "Firefox NN"<br />
* GeckoView: "NN Branch"<br />
* MailNews Core: "NN"<br />
* SeaMonkey: "SeaMonkey N.0"<br />
* Testing: "NN Branch"<br />
* Thunderbird: "NN"<br />
* Toolkit: "NN Branch"<br />
* WebExtensions: "Firefox NN"<br />
<br />
= Adding a "rapid release" version to SeaMonkey =<br />
<br />
To determine the correct version number to add, check with a SeaMonkey owner first (Callek, or any member of the [http://www.seamonkey-project.org/about SeaMonkey Council]).<br />
<br />
these steps use 2.27 as an example.<br />
<br />
use the [https://bugzilla.mozilla.org/page.cgi?id=tracking_flags_admin_list.html release tracking flags admin page] to:<br />
* copy the prior flags and edit as per firefox<br />
** copy cf_tracking_seamonkey226 to cf_tracking_seamonkey_227<br />
** copy cf_status_seamonkey226 to cf_status_seamonkey_227<br />
* deactivate old flags for previous (now released) versions (N-4)<br />
** deactivate cf_tracking_seamonkey223 and cf_status_seamonkey223<br />
<br />
use the [https://bugzilla.mozilla.org/editmilestones.cgi?product=SeaMonkey milestone admin page] to:<br />
* add a new milestone "seamonkey2.27"<br />
* move the --- milestone marker to between seamonkey2.26 and seamonkey2.27<br />
<br />
use the [https://bugzilla.mozilla.org/editversions.cgi?product=SeaMonkey version admin] page to:<br />
* add a new version "SeaMonkey 2.27 Branch"<br />
<br />
[[Category:BMO]]</div>Emceeaich