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
[email protected]
https://lists.mozilla.org/listinfo/dev-platform