Due to unexpected circumstances, we couldn’t deploy and migrate the bug type 
field this week. Will try again next week as soon as on Monday.

Thanks,
-Kohei


On 2019-03-26 8:05 p.m., Kohei Yoshino wrote:
An update on the bug type and regression fields:

Because of Firefox 66 and the subsequent 66.0.1 pwn2own chemspill, we decided 
to delay the deployment of the change. We are now ready to deploy the new bug 
type and regressions/regressed-by fields to production Bugzilla later this week.

A one-time bug type auto migration will follow this weekend. It will be done 
with a component-based migration script [1] as well as the bugbug machine 
learning tool [2]. Marco tested bugbug with several bugs on the staging server 
last weekend and the results look good overall. The current instance can be 
seen on: https://bugzilla.allizom.org/

It should be noted that bugbug only classifies bugs as defect or enhancement 
over the last 2 years, because the accuracy of the detection between 
enhancement and task is not perfect. So triage owners and/or assignees will 
have to manually change the type of some existing bugs from enhancement to task 
once the migration is complete.

We’ll keep you posted.
-Kohei

[1] https://github.com/mozilla-bteam/bmo/pull/1106/files
[2] https://github.com/mozilla/bugbug


On 2019-03-12 6:55 a.m., Sylvestre Ledru wrote:
Bugzilla is one of the key tools used for the development of Firefox since the 
Netscape era. Even though this tool is serving us well, after interviewing a 
bunch of people at every level inside the company, we realized that we need to 
go the extra step.


Therefore, we decided to focus on improving Bugzilla itself but also, as a next 
step, improve the workflows we have on bugs.


To start with, we are coming with a set of three major changes to make our life 
better and easier.


1) Enforcing the usage of the priority field


As described in this schema 
<https://docs.google.com/drawings/d/1G8SV3EUPknh-2zExL08cd9lzzGMOHAZeRA1geBQnGD4/edit>,
 we are now asking triage owners to set the priority field according to the priority 
definition 
<https://mozilla.github.io/bug-handling/triage-bugzilla#how-do-you-triage>. The main 
goal is to make sure that every bug has been looked at and a priority has been set in 
accordance with the priority definitions.

A bot will automatically needinfo the triage owner (or a member of the team if 
it uses a round robin triage method).

We have been experimenting with this for several components and the results 
look great!


2) Bug type - new field

Firefox development requires a bug for every change in the Firefox code base. 
It doesn’t matter if this is used to fix a defect in the product, to implement 
a new feature or to refactor some code.


For years, we have been using bugzilla keywords to classify them. However, as 
they are not mandatory, the metadata can be missing, unmaintained, or 
inconsistent.


With this change, we are going to extend Bugzilla to add a new field with three 
new values:

  *

    Defect - an issue in one of our products

  *

    Enhancement - a new feature or an improvement

  *

    Task - a developer task. For example: refactor code foo.


Since we don’t want to increase the confusion for new users, the default value will 
be defectand, to the best of our ability, existing bugs will be moved 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1524738>under one of these 
categories.


With this information, we will be able to more precisely measure the quality of 
our products, as we will not mix defects together with feature-related work.


We have a development instance of Bugzilla 
<https://bugzilla-dev.allizom.org/>where the changes can be evaluated, we are 
planning to go live in the new few weeks.


More information https://bugzilla.mozilla.org/1522340


3) Adding a new field called “Regressed by”

Currently, we misuse the blocks/depends fields to mark bugs causing 
regressions. However, they can be confusing and aren’t used consistently by 
developers. Moreover, since we are using bugs for defects, enhancements or 
tasks, it can be very hard to pinpoint the changes which introduced a 
regression.

Being able to pinpoint changes which introduced regressions will make it easier 
to build tools to help with assessing the riskiness of changes.


Therefore, we will add a new field in bugzilla which will clearly identify 
which bug caused a regression.

More:

http://bugzilla.mozilla.org/1461492


Last but not least, nothing is written in stone and we have other improvements 
(bug workflow, improved search, regression field, etc) coming. Sylvestre

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to