Changes to numbering of Versions and Milestones fields in Bugzilla

[Emma Humphries]

Version will be numbered as Firefox NN, and Milestone will be NN Branch
starting with Firefox 81.

This is in order to reduce confusion when filing, reading, and making
decisions about bugs.

It also simplifies the set of tasks the Bugzilla and Release Management
teams perform at the start of a nightly cycle.

This naming convention will apply to new Firefox related projects. See the
table below.

NSS uses its own version numbering.

This is a simplified version of changes which the Bugzilla team were
considering during H1 of 2020.

The bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=1553533

Please contact the BMO team on #bmo on Slack and #bugzilla.mozilla.org on
chat.m.o if you have questions.

- Emma Humphries

Product

Old

New

Version

Milestone

Version

Milestone

Cloud Services

Firefox NN

NN Branch

Firefox NN

NN Branch

Core

mozillaNN

NN Branch

Firefox NN

NN Branch

DevTools

Firefox NN

NN Branch

Firefox NN

NN Branch

Firefox

Firefox NN

NN Branch

Firefox NN

NN Branch

Firefox Build System

mozillaNN

NN Branch

Firefox NN

NN Branch

Firefox for Android

Firefox NN

Firefox NN

Firefox NN

NN Branch

GeckoView

NN Branch

MozillaNN

Firefox NN

NN Branch

Remote Protocol

NN Branch

NN Branch

Firefox NN

NN Branch

Testing

mozillaNN

NN Branch

Firefox NN

NN Branch

Toolkit

mozillaNN

NN Branch

Firefox NN

NN Branch

WebExtensions

mozillaNN

Firefox NN

Firefox NN

NN Branch
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New Triage Process: Triage Center Updated

[Emma Humphries]

Last week when we announced the changes to the Firefox triage process (
https://docs.google.com/document/d/1HYPBDePvYX26JOrk6ymsEeViwTdWhCVL-elSwInsMKw/)
I said that https://mozilla.github.io/triage-center/ was going to be
retired.

We don't have any sort of stats reporting on that project, so we didn't
realize how much it was used.

I discussed this with the Bugzilla team this morning and we decided to
update it for now while we review tools that depend on Bugzilla.

Thanks for your feedback on this, as always, contact me if you have
questions about the triage process or how your teams can use Bugzilla.

-- Emma H
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tooling and reporting changes

[Emma Humphries]

That's arewetriagedyet.net, not. org.

Sorry for the confusion.

-- Emma

On Thu, Apr 30, 2020 at 6:14 PM Emma Humphries  wrote:

> Hi, thank you all for your questions and comments on the changes to the
> triage process starting this Monday with the next merge. I want to
> acknowledge that we're asking to accommodate this during a time of
> uncertainty, but this will help us attain our goal of build quality.
>
> I wanted to let you know about some changes to tooling coming up:
>
> First, if you use https://mozilla.github.io/triage-center, it'll no
> longer be supported and I'm taking the site down because of the changes to
> what we consider triaged.
>
> Second, we'll be updating arewetriagedyet.org to reflect the new triage
> standard.
>
> Lastly, if you have editbugs and are the triage owner for one or more
> components, there's a query saved to Bugzilla for you "Untriaged Bugs
> (Severity Based)"
>
> AutoNag changes are being worked on, and so are the triage documentation
> in-tree.
>
> If you want to refresh yourself on the change, the document on it is here:
> https://docs.google.com/document/d/1HYPBDePvYX26JOrk6ymsEeViwTdWhCVL-elSwInsMKw/
>
> Stay safe and in good health,
>
> Emma
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tooling and reporting changes

[Emma Humphries]

That should be triaged as severity = n/a, and I'll make sure the triage
definition is clear that if the severity is n/a then the status_firefoxNN
flags do not need to be set.

Thanks for calling it out!

-- Emma

On Fri, May 1, 2020 at 7:39 AM Kartikaya Gupta  wrote:

> With this new triage query, a bug like
> https://bugzilla.mozilla.org/show_bug.cgi?id=1633584 is considered
> untriaged, because it doesn't have any of the status-firefoxXX flags
> set. However it's an "enhancement" type bug and so those flags don't
> really make much sense to be setting. Is this intentional, or can this
> part of the query be revisited so that the status-firefoxXX flags
> don't need to be set on enanchement/task bugs?
>
> On Thu, Apr 30, 2020 at 9:15 PM Emma Humphries  wrote:
> >
> > Hi, thank you all for your questions and comments on the changes to the
> triage process starting this Monday with the next merge. I want to
> acknowledge that we're asking to accommodate this during a time of
> uncertainty, but this will help us attain our goal of build quality.
> >
> > I wanted to let you know about some changes to tooling coming up:
> >
> > First, if you use https://mozilla.github.io/triage-center, it'll no
> longer be supported and I'm taking the site down because of the changes to
> what we consider triaged.
> >
> > Second, we'll be updating arewetriagedyet.org to reflect the new triage
> standard.
> >
> > Lastly, if you have editbugs and are the triage owner for one or more
> components, there's a query saved to Bugzilla for you "Untriaged Bugs
> (Severity Based)"
> >
> > AutoNag changes are being worked on, and so are the triage documentation
> in-tree.
> >
> > If you want to refresh yourself on the change, the document on it is
> here:
> https://docs.google.com/document/d/1HYPBDePvYX26JOrk6ymsEeViwTdWhCVL-elSwInsMKw/
> >
> > Stay safe and in good health,
> >
> > Emma
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Tooling and reporting changes

[Emma Humphries]

Hi, thank you all for your questions and comments on the changes to the
triage process starting this Monday with the next merge. I want to
acknowledge that we're asking to accommodate this during a time of
uncertainty, but this will help us attain our goal of build quality.

I wanted to let you know about some changes to tooling coming up:

First, if you use https://mozilla.github.io/triage-center, it'll no longer
be supported and I'm taking the site down because of the changes to what we
consider triaged.

Second, we'll be updating arewetriagedyet.org to reflect the new triage
standard.

Lastly, if you have editbugs and are the triage owner for one or more
components, there's a query saved to Bugzilla for you "Untriaged Bugs
(Severity Based)"

AutoNag changes are being worked on, and so are the triage documentation
in-tree.

If you want to refresh yourself on the change, the document on it is here:
https://docs.google.com/document/d/1HYPBDePvYX26JOrk6ymsEeViwTdWhCVL-elSwInsMKw/

Stay safe and in good health,

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

Changes to the Firefox Bug Triage Process [ If you use Bugzilla, read this ]

[Emma Humphries]

Starting with the next Firefox release cycle, Monday, May 4th, we expect
you to set the Severity field to a non-default value when triaging Firefox
related bugs.

If you use Bugzilla, but not for Firefox, please read on, because there's
changes to the Severity field.

After discussions with engineering management, release management, QA, and
people triaging bugs we’ve decided that we want consistent assessments of a
bug’s severity so that we know what bugs will affect the quality of a
release.

This is a change from what we've been doing historically during triage,
which is setting the Priority field. Using Priority alone conflates
severity with scheduling.

The new definition of Triaged will be Firefox-related bugs of all types
(defect, task, enhancement) where the component is not UNTRIAGED, which has
one or more current (Nightly, Beta, Release, ESR) Status_FirefoxNN flags
set to a non-default value, and a non-default value of Severity.

Bugs of type Task or Enhancement may have a severity of N/A, but defects
must have a severity that is neither ‘--’ or N/A. No bug with a severity of
‘--’ is considered triaged.

We will update our triage dashboards, saved bugzilla queries, and AutoNag
rules to reflect this change.

Please join us on the Bug Handling channel on Riot/Matrix (
https://chat.mozilla.org/#/room/#bug-handling:mozilla.org) with your
questions.

Part of the reason we’ve not consistently used severity is that the field’s
default was NORMAL, so we could not easily determine when it was modified.

By default, a new bug’s severity will be ‘--’ and the severity values will
change to:

--: Default for new bugs

N/A: (not applicable): Only applies to bugs of type Task or Enhancement.

S1: (Catastrophic) Blocks development/testing, may impact more than 25% of
users, causes data loss, potential chemspill, and no workaround available

S2: (Serious) Major Functionality/product severely impaired and a
satisfactory workaround doesn't exist

S3: (Normal) Blocks non-critical functionality and a work around exists

S4: (Small/Trivial) minor significance, cosmetic issues, low or no impact
to users
Use these descriptions to guide your decision on a bug’s severity. We’ll be
mapping existing bugs to the new definitions.

We are making this change so that we can focus on identifying and fixing
critical issues in current and upcoming releases.

You can continue to set Priority when you triage bugs, and it’s suggested
that you do continue to follow the definitions for the values of the
Priority field if you do.

Note that a bug can be a regression but may have a minor severity, and
conversely bugs which are not regressions can have a major severity.

High Severity and tracking are not the same. If in doubt whether a high
severity bug merits tracking, err on the side of requesting it - relman can
turn it down, and we'd rather have more visibility than less. In general,
it is not necessary to request tracking for low-severity bugs.

For bugs triaged by QA, apart from setting needed flags and components, the
severity field will be updated by QA. Triage owners can review and update
severity if needed.

After an S1 defect found in QA or release has been resolved, a Root Cause
should be determined and the RCA program flag for the bug updated. Process
on this topic will be communicated later in a separate email.

If you have scripts, dashboards, or processes that depend on the current
values of the Severity field, please update them. The Bugzilla team will
update your saved searches to reflect the new values of the Severity field.
This new process was the result of review and discussions with: Vicky Chin,
Tania Maity, Ryan VanderMulen, Thomas Elin, Andrew Overholt, Asa Dotzler,
Mike Connoly, Gijs Kruitbosch, and Jared Wein. I'm grateful to them for
their ideas and contributions to this. Any errors are my own.

A longer version of this email with more background can be found at:
https://docs.google.com/document/d/1HYPBDePvYX26JOrk6ymsEeViwTdWhCVL-elSwInsMKw/

In solidarity,

Emma Humphries, Developer Workflow Team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Identifying bugs affecting people working and learning from home

[Emma Humphries]

tl;dr

Put '[wfh]' in a bug's whiteboard if it affects people working from or
learning from home.

Longer version:

As part of an effort to identify and prioritize Firefox bugs that affect
people who are working and learning from home during the current crisis,
we're asking you to tag bugs as you enter, or triage them with '[wfh]' so
we can find them.

https://mzl.la/2xAsWt3 is the link to a bug template you can share that has
the whiteboard tag filled out.

Thanks,

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

Requesting SUMO docs from Bugzilla

[Emma Humphries]

At the request of the Firefox Desktop team, we've revised how you request
user-facing docs (in SUMO) from Bugzilla.

There's a new flag, `user-doc-firefox`, available to Firefox related
products.

Its use is documented in
https://firefox-bug-handling.mozilla.org/doc-requests.

The summary is, set the flag to `docs-needed` if you think your work
requires user-facing documentation. The SUMO team will get notifications.

You can file documentation issues in
https://github.com/mozilla/firefox-bug-handling/, or ask in #bug-handling:
mozilla.org on chat.mozilla.com.

Thanks.

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

Fwd: happy bmo push day!

[Emma Humphries]

I wanted to call attention to an important change that went out with
today's Bugzilla deployment.

We had been suspending the accounts of people whose bugmail was bouncing,
and they had to contact the Bugzilla Admins to get their account
reactivated.

Now if your bugmail bounces, we'll stop sending bugmail, notify you, and
let you turn bugmail back on once you address the bounces.

I know that this has been an annoyance for many users, and we've spent more
time than we've wanted to fixing things for users, so this is a big win.

Many thanks to Dave Lawrence (:dkl) for building this feature!

-- Emma

-- Forwarded message -
From: Dave Lawrence 
Date: Wed, Feb 26, 2020 at 2:30 PM
Subject: happy bmo push day!
To: 


happy bmo push day!

https://bugzil.la/1612290 : Provide self-service UI for users to reactivate
their account after being disabled due to bouncing

One notable change that was pushed live to production today was the ability
to self-service your own account if you get blocked due to email bouncing
issues. Now if your email bounces, instead of not being able to login
completely, your email notifications will be temporarily disabled but you
will still be able to login. You will see a banner message stating that
your email has been disabled with a link to a page where you can turn it
back on.

The linked page will display the error messages returned from the upstream
mail relay and display a form to turn on your email. Please do not enable
email if you are not sure the bouncing issue has been resolved.

A internal counter will allow you to reactivate your email notifications up
to five times in a thirty day period. On the fifth time, your account will
be disabled for login and you will need an admin to reactivate the account
similar to the process before.

This new feature should hopefully help BMO admins to not have to deal with
the majority of intermittent email bounce issues and instead allow the user
to admin their own account when they happen.

The following other changes have been pushed to bugzilla.mozilla.org:

https://bugzil.la/1617358 : Extra slash in the "phabricator review
requests" link's url on the BMO dashboard
https://bugzil.la/1591549 : Hide bugs in dependencies and regression fields
from users without access
https://bugzil.la/1237874 : File size unit always plural: "1 bytes"
https://bugzil.la/1599865 : Bug description is erased during page load,
leading to dataloss during Firefox session restore
https://bugzil.la/1472757 : Comment field empty after clicking "go back
page"
https://bugzil.la/1614634 : 13 hours ago wasn't "1 day ago"

(tag: https://github.com/mozilla-bteam/bmo/tree/release-20200226.1)
___
tools-bmo mailing list
tools-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/tools-bmo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Upcoming Bugzilla API and Bot Changes

[Emma Humphries]

## Summary ##

During 2020, the Bugzilla team will be making several changes to improve
security and performance for our users who rely on APIs and automation. We
want you to know about them so you can start preparations.

## AutoNag  ##

AutoNag is a service which runs a Bugzilla query and then takes actions on
the results. It’s used to notify teams about untriaged bugs, close
intermittent test failures, clean up bugs, and other tasks.

You can write your own scripts, following the guidelines in the repository,
or file an issue to request one.

If you want to set up a rotation of people to triage a component, AutoNag
will enable that as well. You need to set up a Google Calendar or JSON file
with a schedule of people triaging bugs first.

If AutoNag does not meet your requirements and you run your own bots and
scripts, please take note about upcoming changes.

- https://wiki.mozilla.org/Release_Management/autonag
- https://github.com/mozilla/relman-auto-nag

## Bot guidelines ##

If you run a script or bot that uses the Bugzilla API, make sure it is in
our registry.

Check the registry page because it has requirements we expect all bots and
scripts to follow by mid-2020: including standard naming, using api keys,
and our REST interface.

- https://bmo.readthedocs.io/en/latest/api/index.html
- https://wiki.mozilla.org/BMO/Bot_Registry

If you use our old APIs you need to know about their retirement.

## Old interfaces going away ##

We plan to shut down the JSONRPC (https://bugzilla.mozilla.org/jsonrpc.cgi),
XMLRPC (https://bugzilla.mozilla.org/xmlrpc.cgi), and BzAPI (
https://bugzilla.mozilla.org/bzapi/) interfaces by the end of June, 2020.

If you use one of these, you will need to update your code to use REST.
That interface is documented, and if you find problems or issues with it
please file a bug.

- https://bmo.readthedocs.io/en/latest/api/
-
https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org=API

This would be a good time to move the definition of the base URL you use to
access our API to a configuration in your applications using it.

- https://bugzilla.mozilla.org/rest

Questions?

Please seek the BMO team out on Slack and Matrix.

Thanks,

Emma Humphries, on behalf of the BMO team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Bugzilla Bugmail Powertip: preventing bounces

[Emma Humphries]

We get notified accounts getting blocked in Bugzilla fairly often and the
two biggest causes are systems deciding bugmail is spam, and delivery
problems.

For the first, if you can configure a 'confirmed senders' list for your
email host/service, add "bugzilla-dae...@mozilla.org" to it. That's the
address bugmail comes from.

For the second, if you aren't using gmail, make sure you have all your MX
hosts listed/or backup mailhosts.

If you, for example:

% dig emmas.bugs MX +short

You should get back a few hosts:

10 mx1.plotka.fnord.co
20 mx2.plotka.fnord.co
30 mx3.plotka.fnord.co
40 mx4.plotka.fnord.co
50 mx5.plotka.fnord.co

If you're running your own mail server, make sure you have backup mail
services for your bugmail domain.

% dig emmas.bugs MX +short

10 linux.emma.at.home
20 vms.emma.at.home
30 mx1.mailpeople.se
40 mx2.mailpeople.se

I hope that helps!

-- Emma

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

Bug Handling in Bugzilla over the End of the Year

[Emma Humphries]

As you're winding down work on Firefox at the end of the year, there's a
few things to remember.

First, there will be coverage for Bugzilla. Staff will be monitoring #bmo
on Slack and cloud operations will be watching over Bugzilla.

Second, if you see something, tag something. If you run across comments or
attachments that are spam or violate our Community Participation Guidlines,
please tag them as 'spam' or 'admin' accordingly, and we will review them.

Last, if you are taking time away from Bugzilla over the holidays:

* Update your display name in preferences with the days you are out
* Set yourself to decline needinfo and review/feedback requests while you
are away

If you are celebrating this time of year, I wish you a wonderful time with
your friends and families.

-- Emma Humphries, Bugmaster
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New home for Firefox Bughandling Docs

[Emma Humphries]

Triage, regressions, priorities?

If you have questions about handling bugs in Firefox, check out our
documentation at its new home: https://firefox-bug-handling.mozilla.org/.

If you have questions, see an error, or would like to see documentation and
guides in area not covered; open an issue in our repo at
https://github.com/mozilla/bug-handling/.

Emma Humphries, Bugmaster
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using MozPhab without Arcanist

[Emma Humphries]

Will this make it easier for non-staff contributors to get their change
sets reviewed and landed?

What else should we be doing for that.

I have some ideas I'm working on for views in Bugzilla to help with that so
that contributors can see what's going on, and where they can take action
to help.

-- Emma

On Wed, Oct 23, 2019 at 8:56 AM glob  wrote:

> It's available now - make sure you're running the latest version by
> running `moz-phab self-update`.
>
>
> -glob
>
> Henrik Skupin wrote on 23/10/19 11:49 pm:
> > Piotr Zalewa wrote on 22.10.19 17:25:
> >
> >> Since today MozPhab does not require Arcanist to submit patches in all
> >> supported VCS's. It's an optional and experimental feature. Add the
> >> `--no-arc` option to switch it on.
> > Great to hear, but is there also an ETA when this mode will be available
> > for users of Mercurial? When I use this option I get:
> >
> >> NotImplementedError: Mercurial revisions can't be submitted without
> > Arcanist
> >
> > Thanks
> >
>
> --
> glob — engineering workflow — moz://a
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Updates to Bugzilla components for Bugzilla

[Emma Humphries]

I've updated the components for bugzilla.mozilla.org in Bugzilla today.

All the active components now have triage owners, and the BMO team will be
reviewing open bugs in these components (yes, the bugmaster needs to triage
her bugs. ) We'll be cleaning up the obsolete components over the next
few days.

If you got mail because of the cleanup, it was related to a secure bug in
the component which you either filed or were cc'ed on. Almost all these
were bugs which have been closed.

If you have questions about where to file a bug against Bugzilla, please
check in #bmo on slack, or contact me.

Thanks,

Emma Humphries, Bugmaster
Firefox
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[notice] Bugzilla Errors

[Emma Humphries]

This is not a fun way to start Monday, but we're seeing errors similar to
those we had on Friday with Bugzilla.

I've paged operations to assist.

These errors manifest as API requests not returning bugs, or not the
expected number of bugs. This will interfere with some tools such

They will also manifest with non-logged in users getting errors requesting
show_bug on recently created bugs.

Emma Humphries
Bugmaster
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bugzilla posting failure.

[Emma Humphries]

Moving dev-platform to bcc.

Thank you for your email.

You had posted a bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1574787,
which was resolved as a duplicate of
https://bugzilla.mozilla.org/show_bug.cgi?id=1472757, so that would not
show up in My Dashboard.

I'll ask the BMO team to see if they can can find the error logged from
this most recent incident where you tried to create an attachment, got an
error message, but the attachment had been created.

For future reference, the best place to file bugs related to creating bugs
is
https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org=Bug+Creation%2FEditing
.

E C Humphries, Bugmaster


On Mon, Sep 23, 2019 at 8:10 PM ishikawa  wrote:

> Hi,
>
> Where is the proper forum to post a bug regarding bugzilla.mozilla.org?
>
> I *THINK* I posted a bug regarding bugzilla failure a couple of months ago,
> but for some reason, I could not find it in "My Dashboard" and so I am
> posting the question here.
>
> I experienced a bugzilla problem today and it resulted in a pair of
> duplicated entry.
> Problem was that
> - bugzilla showed a message after initial posting that an attachment could
> not be uploaded or something ( I wish I had recorded the message), but
> - then I realize that after I added an attachment to the
>   resulting page WITHOUT attachment that a complete entry had already been
> created ...
>
> 1. Completely entry created despite the confusing error(?) message from
> bugzilla.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1583415
>
> 2. After I clear the error message, I got a link to the following entry
> that
> lacked the attachment, and so I  added the attachment. See comment 1 there.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1583416
>
> I only learned the existence of the URL 1 above AFTER I added the
> attachment
> since bugzilla said something about the failure of upload (?).
>
> I have not deleted the duplicate entries yet since the existence of the
> entry and the log on the bugzilla server may help whoever wants to debug
> the
> issue to find the cause of the strange bogus error message and what
> happened
> after I clicked a link the error message screen.
> (I DID, however, mark 1583416 as a dup of 1583415)
>
> At least, the error message screen, which I failed to capture,  ought to be
> rewritten IMHO to inform the poster what has happened correctly in an
> easy-to-comprehend manner.
>
> Thank you for your attention in advance.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[ Intent to change ] Updates to Are We Triaged Yet

[Emma Humphries]

Hi, I want to give you a heads up on some incoming updates to the Are We
Triaged Yet tool.

You can see these at https://are-we-triaged-yet.glitch.me/.

The changes:

* This release gets rid of the separate sets of charts for each release,
that way of tracking wasn't helpful.
 - Now there's two sets of columns for each component
 - The first is open bugs in a category by age: more than a month old, more
than a week old (including previous column,) and less than a week old
 - The second set of columns are the numbers of open bugs in a category
that were opened during the current nightly, beta, and release

* The uplifts report has been removed

The change means that the API for requesting charts no longer takes version
as an argument on the query string.

If you have questions or comments on the new version, please let me know,
otherwise I plan to merge the changes into production next Monday.

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

[ Intent to Change ] Enabling the Triage Lead role to see security bugs in their component

[Emma Humphries]

When work on https://bugzilla.mozilla.org/show_bug.cgi?id=1417229 is
completed and the patch deployed to Bugzilla, users who are a Triage Owner
will be able to see security bugs in their components without needing
membership in security group or access through a role.

This follows the same pattern as access for users in the reporter, qa
contact, assignee, or cc list roles to security bugs.

If the triage owner for a component changes, the new owner will have access
and the previous owner, unless they have access through another means
(role, or group membership,) will not.

We expect this to go to production within the next two weeks.

Many thanks to DKL for working on a patch for this.

Emma Humphries, Bugmaster
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[ Intent to Change ] Enabling the MOVED resolution in Bugzilla

[Emma Humphries]

This a is notification of an upcoming change to bugzilla.mozilla.org.

The detailed version of this notification is at
https://docs.google.com/document/d/1OH0BO3LHfaqZqVK0hi7-EOh5Ctjebx0k2imcgF8JOSk/
and open for comment.

The bug for this change is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1553597

A summary follows.

We plan to re-enable the MOVED resolution in Bugzilla. We want to advise
you of this change and give your product or component the opportunity to
opt out of it or set restrictions on its use.

=
You must notify us if, as the triage owner or other person responsible for
a component in Bugzilla:

* You do not want bugs to be resolved as MOVED
* If you want restrictions on the value of the See Also field of bugs
resolved as MOVED

Please notify us of your choice by September 9th, 2019.
=

The meaning of MOVED is that the bug is now being tracked in another issue
tracker. This may be another Mozilla project such as one on GitHub. It may
also be another organization’s issue tracker such as Apple’s Radar,
Google’s Monorail, or another organization’s own GitHub.

This was motivated by the WebCompat team’s request to enable moving issues
filed in Bugzilla to the WebCompat project’s issue trackers on GitHub.

Bug resolutions cannot be enabled on a per product or component basis, so
when we enable this, the resolution will be available for all bugs.

If you want your product or component to opt out this change we need you to
tell us so that we can set up a rule to enforce the exception. If you want
to set rules on the URLs where bugs resolved as MOVED can point to, you
must let us know.

If you have questions about this change, please comment the linked document
or the bug.

Thank you,

Emma Humphries, Bugmaster
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[intent to deploy] Changes to show_bug.cgi on BMO

[Emma Humphries]

Hello,

Kohei's finishing up some changes to how information is organized in
show_bug.cgi, and we'd like your feedback before we deploy it.

The enhancement bug for this work is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1344091

You can see this work previewed on https://bugzilla-dev.allizom.org. For
example: https://bugzilla-dev.allizom.org/show_bug.cgi?id=238966.

Please take a look, and either comment on, or file a blocker on
https://bugzilla.mozilla.org/show_bug.cgi?id=1344091.

Thanks.

Emma, for the BMO team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Change: Reducing the number of severity values in Bugzilla

[Emma Humphries]

The first part of this change has been made in Bugzilla.

The Major and Trivial severity levels have been disabled for filing and
editing bugs.

Soon we will remap existing Major bugs to Critical, and Trivial bugs to
Minor.

If, for any reason, you need to see which bugs have the old value, you can
search for the disabled values in Advanced Search, view values of severity
which were changed using the History view of a bug, or request `history` as
one of the returned fields in the Bugzilla API.

Thank you,

Emma



On Wed, Jun 12, 2019 at 12:40 PM Emma Humphries  wrote:

> Hello, and apologies if you receive duplicates of this email.
>
> Bugzilla has multiple values for bug severity which are displayed
> alongside priority.
>
> The differences between minor or trivial are small and do not help with
> describing a bug’s effect.
>
> We have keywords to indicate bugs which are crashes, data loss, or memory
> leaks; making the major value redundant.
>
> We removed the enhancement severity when we introduced bug types in 1H19.
>
> After review and discussion with a subset of Bugzilla stakeholders, we're
> announcing our intent to make the following change to Bugzilla.
>
> Existing Severity Values
> 
> * Blocker: Blocks development and/or testing work
> * Critical: Crashes, loss of data, severe memory leak
> * Major: Major loss of function
> * Normal: Regular issue, some loss of functionality under specific
> circumstances
> * Minor: Minor loss of function, or other problem where easy workaround is
> present
> * Trivial: Cosmetic problem like misspelled words or misaligned text
>
> We plan to collapse the existing values into blocker, normal, minor and
> critical.
>
> New Severity Values
> ---
> * Blocker: Broken important user-facing feature, Blocks development and/or
> testing work
> * Critical: Affecting a large number of users (all users on AMD64,
> Windows, MacOS, Linux), or major areas of functionality (tls, DOM,
> JavaScript, FxA, Add-ons)
> * Normal: Default; Regular issue, some loss of functionality under
> specific circumstances
> * Minor: 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
>
> We'll be implementing this change in Bugzilla after the Whistler
> All-Hands.
>
> If you have questions or concerns about this change, please see me at
> Whistler or set up a meeting.
>
> I'll be available after the "How to Bugzilla" session on Tuesday at the
> All Hands (Fairmont Macdonald C, 13:30 to 15:30).
>
> You can also leave comments in:
> https://docs.google.com/document/d/1dCiiKV4CE4ZUuOb6yCtCjATzpbnh7MZfLKPqepxzasA/
>
> Thanks,
>
> Emma H.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Inbound change to Are We Triaged Yet?

[Emma Humphries]

To clarify, these reports are defects only:

* Untriaged defects with needinfos pending
* Untriaged defects without needinfos

Remember it's a triage power-move to look at bug descriptions and move them
to enhancements or tasks if they aren't bugs.

-- Emma

On Mon, Jul 8, 2019 at 2:05 PM Emma Humphries  wrote:

> Hello,
>
> With today's merge for Firefox 70, I'm pushing a small, but hopefully
> useful change to our triage dashboards at
> https://are-we-triaged-yet.herokuapp.com/.
>
> I'm breaking out untriaged bugs into two groups:
>
> * Untriaged bugs with needinfos pending
> * Untriaged bugs without needinfos
>
> I'm doing this to make it easier to focus on triage backlogs and follow-up
> on bugs which we need to ask for more information on.
>
> The Corisca dashboards in the offices will now show the reports for
> Untriaged bug without needinfos.
>
> These reports are meant to make your jobs easier, so please let me know of
> any improvements you want to see.
>
> Thank you,
>
> Emma
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Inbound change to Are We Triaged Yet?

[Emma Humphries]

Hello,

With today's merge for Firefox 70, I'm pushing a small, but hopefully
useful change to our triage dashboards at
https://are-we-triaged-yet.herokuapp.com/.

I'm breaking out untriaged bugs into two groups:

* Untriaged bugs with needinfos pending
* Untriaged bugs without needinfos

I'm doing this to make it easier to focus on triage backlogs and follow-up
on bugs which we need to ask for more information on.

The Corisca dashboards in the offices will now show the reports for
Untriaged bug without needinfos.

These reports are meant to make your jobs easier, so please let me know of
any improvements you want to see.

Thank you,

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

Intent to Change: Marking Up Regressions in Bugzilla

[Emma Humphries]

We are making more changes to how we report and track regressions in
Bugzilla.

There are multiple fields and keywords we use to track regressions in
Bugzilla. It’s confusing and the fields are used inconsistently across
teams.

We are consolidating these fields to reduce confusion and provide a
consistent way to track these bugs. This change will also improve our
understanding of defects by humans,  tools and automation.

You have already seen the first part of this work. We’ve added the
regresses and regressed_by fields to identify the bug associated with the
changeset that caused a regression. That step eliminated the confusion over
if a bug caused a regression or was a dependency.

Currently we use the regression and regressionwindow-wanted keywords to
indicate regressions and look for the changeset responsible. We also have
the has-regression-range field (which is used less frequently.)

We’re replacing the regression and regressionwindow-wanted keywords, and
the has-regression-range field with is_regression, which has the values:

* yes-range-known
* yes-range-needed
* yes-range-not-needed
* unsure
* no
* '---'

We have yes-range-not-needed as a value because there are some
long-standing regressions we know of, and also to preserve history on
older, resolved regression bugs for which we may not know the cause or for
which finding the range would be too expensive or difficult to find.

Usage


The default value of is_regression is '---'.

If you believe a bug is a regression, but don’t know what commit introduced
it, set is_regression to yes-range-needed.

If you are not sure if a bug is a regression, set is_regression to unsure.

Once you’ve found the changeset that introduced the regression, set
is_regression to yes-range-known and set the regressed_by field to the bug
containing the changeset.

If a bug turns out to not be a regression, set is_regression to no and make
sure regressed_by is empty.

If you set is_regression to yes-range-not-needed, then you’re asserting
that there’s not a changeset you can revert to fix the regression.

If you are looking for regressions to find ranges for, search on
is_regression = yes-range-needed.

Bugs with is_regression = unsure need help confirming if they are
regressions. If you can confirm it’s a regression set the value to
yes-range-needed, or yes-range-known. If not, set the value to no.

We will notify triage owners through setting a needinfo request via the
Autonag Bot when these fields are in an inconsistent state.

This proposal benefited from the review and comments of several Mozillians:
Ritu Kothari, Neha Kochar, Kohei Yoshino, Julien Cristau, Marco
Castelluccio, Calixte Denizet, Ehsan Akhgari, and Andrew Overholt. Any
errors or oversights are my responsibility alone.

We will implement this change after the Whistler All-Hands.

If you have questions or concerns about this change, please see me at
Whistler or set up a meeting.

I'll be available after the "How to Bugzilla" session on Tuesday at the All
Hands (Fairmont Macdonald C, 13:30 to 15:30).

You can leave comments in
https://docs.google.com/document/d/1UaHeJtttVGCKOq2qK7EuN9jQdfp_jXtDDfoLSLC3jRw/

The bug for this is: https://bugzilla.mozilla.org/show_bug.cgi?id=1534280

Thank you,

Emma H
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling the UINEEDED keyword

[Emma Humphries]

Hi Dão,

Thank you for calling out that use case. This week I met with one of the UX
managers to plan a replacement for the keyword. The goal here is to have a
work queue that UX can triage and is visible to all the stakeholders.

I'll report on that soon.

-- Emma

On Wed, May 15, 2019 at 3:41 AM Dão Gottwald  wrote:

> After reading the bug, it seems that this use case was just completely
> missed, and only UX people who barely use bugzilla were consulted.
> Therefore I'd like to ask that we re-enable this keyword until we have a
> proper replacement.
>
> Thanks,
> Dao
>
> Am Mi., 15. Mai 2019 um 12:28 Uhr schrieb Dão Gottwald <
> dgottw...@mozilla.com>:
>
>> I used the uiwanted keyword in Firefox front-end components to indicate
>> that a bug needs UX input before it can move forward, without explicitly
>> flagging a particular UX person because the bug has a low priority. It's
>> valuable meta data even if nobody monitors all uiwanted bugs. How do you
>> suggest we support that use case going forward? There's the whiteboard but
>> that seems like a step backwards.
>>
>> TIA, Dao
>>
>> Am Fr., 26. Apr. 2019 um 01:52 Uhr schrieb Emma Humphries <
>> e...@mozilla.com>:
>>
>>> Typo: s/uineeded/uiwanted/gi
>>>
>>> On Thu, Apr 25, 2019 at 4:50 PM Emma Humphries  wrote:
>>>
>>>> Previously teams and other contributors have used the uineeded keyword
>>>> in Bugzilla to indicate if the UX team’s expertise was needed.
>>>>
>>>> However, that keyword, with a couple of exceptions, is not currently
>>>> monitored by that team.
>>>>
>>>> In order to prevent misunderstandings, I will be disabling the uineeded
>>>> keyword in Bugzilla. It will appear in bugs that have it until it is
>>>> removed so you may clean up backlogs, but it will no longer be able to be
>>>> set for new bugs.
>>>>
>>>> If you are working with a UX team member who is monitoring Bugzilla
>>>> bugs (DevTools and Activity Stream) then please use needinfo to call out
>>>> bugs to them.
>>>>
>>>> Otherwise, please work with the UX managers (Tif, Markus, and Anthony
>>>> who all reviewed this) to ask about getting UX resources to help with
>>>> your project.
>>>>
>>>> The relevant BMO bug for this is:
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1541690
>>>>
>>>> In May I will be working with the UX managers to investigate a
>>>> replacement UX triage for Bugzilla.
>>>>
>>>> -- Emma
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to how we track regressions in Bugzilla

[Emma Humphries]

Thanks for everyone's feedback.

We're starting on the implementation in these bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=1542378 (enter bug form),
https://bugzilla.mozilla.org/show_bug.cgi?id=1545258 (create new field),
and https://bugzilla.mozilla.org/show_bug.cgi?id=1543876 (migrate existing
metadata).

I will follow up when we are ready to enable the field in production
Bugzilla.

-- Emma

On Mon, Apr 29, 2019 at 3:15 PM Emma Humphries  wrote:

> We are making more changes to how we report and track regressions in
> Bugzilla.
>
>
> There are multiple fields and keywords we use to track regressions in
> Bugzilla. It’s confusing and the fields are used inconsistently across
> teams.
>
>
> We are consolidating these fields to reduce confusion and provide a
> consistent way to track these bugs. This change will also improve our
> understanding of defects by humans,  tools and automation.
>
>
> == The Change
>
>
> You have already seen the first part of this work. We’ve added the
> regresses and regressed_by fields to identify the bug associated with the
> changeset that caused a regression. That step eliminated the confusion over
> if a bug caused a regression or was a dependency.
>
> Currently we use the regression and regressionwindow-wanted keywords to
> indicate regressions and look for the changeset responsible. We also have
> the has-regression-range field (which is used less frequently.)
>
> We’re replacing the regression and regressionwindow-wanted keywords, and
> the has-regression-range field with is_regression, which has the values:
>
>
>-
>
>yes-range-known
>-
>
>yes-range-needed
>-
>
>yes-range-not-needed
>-
>
>unsure
>-
>
>no
>-
>
>'---'
>
> We have yes-range-not-needed as a value because there are some
> long-standing regressions we know of, and also to preserve history on
> older, resolved regression bugs for which we may not know the cause or for
> which finding the range would be too expensive or difficult to find.
> == Usage
>
>
> The default value of is_regression is '---'.
>
> If you believe a bug is a regression, but don’t know what commit
> introduced it, set is_regression to yes-range-needed.
>
> If you are not sure if a bug is a regression, set is_regression to unsure.
>
>
> Once you’ve found the changeset that introduced the regression, set
> is_regression to yes-range-known and set the regressed_by field to the
> bug containing the changeset.
>
> If a bug turns out to not be a regression, set is_regression to no and
> make sure regressed_by is empty.
>
> If you set is_regression to yes-range-not-needed, then you’re asserting
> that there’s not a changeset you can revert to fix the regression.
>
> If you are looking for regressions to find ranges for, search on
> is_regression = yes-range-needed.
>
> Bugs with is_regression = unsure need help confirming if they are
> regressions. If you can confirm it’s a regression set the value to
> yes-range-needed, or yes-range-known. If not, set the value to no.
>
> We will notify triage owners through setting a needinfo request via the
> Autonag Bot when these fields are in an inconsistent state (see below).
>
>
> == Notes
>
>
> The is_regression field is intended for bugs of type defect.
>
> We will be updating our UI for bug entry so that when setting a bug
>
> So that we don’t lose history in the move, we will have to note older,
> resolved regression bugs for which we don’t have values for the
> regresses/regressed_by fields. If the bug is a regression which was RESOLVED
> FIXED or RESOLVED VERIFIED, we will mark it as yes-range-known, and look
> into backfilling the field using the information in the blocked_by field.
>
> These changes were discussed, at length, on Bugzilla (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1534280)
>
>
> == Feedback
>
>
> I'll be reading your feedback on this on this thread, or in the bugzilla
> bug and will respond later this week.
>
>
> -- Emma
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to how we track regressions in Bugzilla

[Emma Humphries]

When I was emailing this yesterday, I neglected to shout out folks for
their help: Calixte suggested the improvements, and the plan benefited from
Marco's reflecting on what we were trying to achieve. I recommend reading
the thread https://bugzilla.mozilla.org/show_bug.cgi?id=1534280 to follow
the evolution of the process.

-- Emma

On Mon, Apr 29, 2019 at 3:15 PM Emma Humphries  wrote:

> We are making more changes to how we report and track regressions in
> Bugzilla.
>
>
> There are multiple fields and keywords we use to track regressions in
> Bugzilla. It’s confusing and the fields are used inconsistently across
> teams.
>
>
> We are consolidating these fields to reduce confusion and provide a
> consistent way to track these bugs. This change will also improve our
> understanding of defects by humans,  tools and automation.
>
>
> == The Change
>
>
> You have already seen the first part of this work. We’ve added the
> regresses and regressed_by fields to identify the bug associated with the
> changeset that caused a regression. That step eliminated the confusion over
> if a bug caused a regression or was a dependency.
>
> Currently we use the regression and regressionwindow-wanted keywords to
> indicate regressions and look for the changeset responsible. We also have
> the has-regression-range field (which is used less frequently.)
>
> We’re replacing the regression and regressionwindow-wanted keywords, and
> the has-regression-range field with is_regression, which has the values:
>
>
>-
>
>yes-range-known
>-
>
>yes-range-needed
>-
>
>yes-range-not-needed
>-
>
>unsure
>-
>
>no
>-
>
>'---'
>
> We have yes-range-not-needed as a value because there are some
> long-standing regressions we know of, and also to preserve history on
> older, resolved regression bugs for which we may not know the cause or for
> which finding the range would be too expensive or difficult to find.
> == Usage
>
>
> The default value of is_regression is '---'.
>
> If you believe a bug is a regression, but don’t know what commit
> introduced it, set is_regression to yes-range-needed.
>
> If you are not sure if a bug is a regression, set is_regression to unsure.
>
>
> Once you’ve found the changeset that introduced the regression, set
> is_regression to yes-range-known and set the regressed_by field to the
> bug containing the changeset.
>
> If a bug turns out to not be a regression, set is_regression to no and
> make sure regressed_by is empty.
>
> If you set is_regression to yes-range-not-needed, then you’re asserting
> that there’s not a changeset you can revert to fix the regression.
>
> If you are looking for regressions to find ranges for, search on
> is_regression = yes-range-needed.
>
> Bugs with is_regression = unsure need help confirming if they are
> regressions. If you can confirm it’s a regression set the value to
> yes-range-needed, or yes-range-known. If not, set the value to no.
>
> We will notify triage owners through setting a needinfo request via the
> Autonag Bot when these fields are in an inconsistent state (see below).
>
>
> == Notes
>
>
> The is_regression field is intended for bugs of type defect.
>
> We will be updating our UI for bug entry so that when setting a bug
>
> So that we don’t lose history in the move, we will have to note older,
> resolved regression bugs for which we don’t have values for the
> regresses/regressed_by fields. If the bug is a regression which was RESOLVED
> FIXED or RESOLVED VERIFIED, we will mark it as yes-range-known, and look
> into backfilling the field using the information in the blocked_by field.
>
> These changes were discussed, at length, on Bugzilla (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1534280)
>
>
> == Feedback
>
>
> I'll be reading your feedback on this on this thread, or in the bugzilla
> bug and will respond later this week.
>
>
> -- Emma
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Changes to how we track regressions in Bugzilla

[Emma Humphries]

We are making more changes to how we report and track regressions in
Bugzilla.


There are multiple fields and keywords we use to track regressions in
Bugzilla. It’s confusing and the fields are used inconsistently across
teams.


We are consolidating these fields to reduce confusion and provide a
consistent way to track these bugs. This change will also improve our
understanding of defects by humans,  tools and automation.


== The Change


You have already seen the first part of this work. We’ve added the regresses
and regressed_by fields to identify the bug associated with the changeset
that caused a regression. That step eliminated the confusion over if a bug
caused a regression or was a dependency.

Currently we use the regression and regressionwindow-wanted keywords to
indicate regressions and look for the changeset responsible. We also have
the has-regression-range field (which is used less frequently.)

We’re replacing the regression and regressionwindow-wanted keywords, and
the has-regression-range field with is_regression, which has the values:


   -

   yes-range-known
   -

   yes-range-needed
   -

   yes-range-not-needed
   -

   unsure
   -

   no
   -

   '---'

We have yes-range-not-needed as a value because there are some
long-standing regressions we know of, and also to preserve history on
older, resolved regression bugs for which we may not know the cause or for
which finding the range would be too expensive or difficult to find.
== Usage


The default value of is_regression is '---'.

If you believe a bug is a regression, but don’t know what commit introduced
it, set is_regression to yes-range-needed.

If you are not sure if a bug is a regression, set is_regression to unsure.

Once you’ve found the changeset that introduced the regression, set
is_regression to yes-range-known and set the regressed_by field to the bug
containing the changeset.

If a bug turns out to not be a regression, set is_regression to no and make
sure regressed_by is empty.

If you set is_regression to yes-range-not-needed, then you’re asserting
that there’s not a changeset you can revert to fix the regression.

If you are looking for regressions to find ranges for, search on
is_regression = yes-range-needed.

Bugs with is_regression = unsure need help confirming if they are
regressions. If you can confirm it’s a regression set the value to
yes-range-needed, or yes-range-known. If not, set the value to no.

We will notify triage owners through setting a needinfo request via the
Autonag Bot when these fields are in an inconsistent state (see below).


== Notes


The is_regression field is intended for bugs of type defect.

We will be updating our UI for bug entry so that when setting a bug

So that we don’t lose history in the move, we will have to note older,
resolved regression bugs for which we don’t have values for the
regresses/regressed_by fields. If the bug is a regression which was RESOLVED
FIXED or RESOLVED VERIFIED, we will mark it as yes-range-known, and look
into backfilling the field using the information in the blocked_by field.

These changes were discussed, at length, on Bugzilla (
https://bugzilla.mozilla.org/show_bug.cgi?id=1534280)


== Feedback


I'll be reading your feedback on this on this thread, or in the bugzilla
bug and will respond later this week.


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

Re: Disabling the UINEEDED keyword

[Emma Humphries]

Typo: s/uineeded/uiwanted/gi

On Thu, Apr 25, 2019 at 4:50 PM Emma Humphries  wrote:

> Previously teams and other contributors have used the uineeded keyword in
> Bugzilla to indicate if the UX team’s expertise was needed.
>
> However, that keyword, with a couple of exceptions, is not currently
> monitored by that team.
>
> In order to prevent misunderstandings, I will be disabling the uineeded
> keyword in Bugzilla. It will appear in bugs that have it until it is
> removed so you may clean up backlogs, but it will no longer be able to be
> set for new bugs.
>
> If you are working with a UX team member who is monitoring Bugzilla bugs
> (DevTools and Activity Stream) then please use needinfo to call out bugs to
> them.
>
> Otherwise, please work with the UX managers (Tif, Markus, and Anthony who
> all reviewed this) to ask about getting UX resources to help with your
> project.
>
> The relevant BMO bug for this is:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1541690
>
> In May I will be working with the UX managers to investigate a replacement
> UX triage for Bugzilla.
>
> -- Emma
>
>
>
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Disabling the UINEEDED keyword

[Emma Humphries]

Previously teams and other contributors have used the uineeded keyword in
Bugzilla to indicate if the UX team’s expertise was needed.

However, that keyword, with a couple of exceptions, is not currently
monitored by that team.

In order to prevent misunderstandings, I will be disabling the uineeded
keyword in Bugzilla. It will appear in bugs that have it until it is
removed so you may clean up backlogs, but it will no longer be able to be
set for new bugs.

If you are working with a UX team member who is monitoring Bugzilla bugs
(DevTools and Activity Stream) then please use needinfo to call out bugs to
them.

Otherwise, please work with the UX managers (Tif, Markus, and Anthony who
all reviewed this) to ask about getting UX resources to help with your
project.

The relevant BMO bug for this is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1541690

In May I will be working with the UX managers to investigate a replacement
UX triage for Bugzilla.

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

Update to "Are We Triaged Yet" for Bug Types

[Emma Humphries]

I've made a change to https://are-we-triaged-yet.herokuapp.com/ to support
the Bug Type changes we released today.

The change is to the pending untriaged report. That will only include bugs
of type Defect.

The other reports will still have all types of bugs.

We are working on reporting for untriaged enhancements with the Product
Team and if you have suggestions for other triage reports you need, please
let me know.

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

Writing JS preference observers? Help us test feature gate.

[Emma Humphries]

Are you writing your own observers in JavaScript to enable and disable code
paths based on boolean preference flips? Would you like to have a library
to use so you can focus on your features and experiments?

Mythmon is developing FeatureGates, a library that watches prefs for you,
so you don’t have to write your own observer code.

We need projects who would be writing their own pref observers to try this
library so we can land it in Firefox. The library is currently in review
and once we have a JavaScript project to test it with, it can be landed in
Mozilla Central.

If you are interested in trying it, please talk with Mythmon, Benson Wong,
or Emma Humphries.
Thank you!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Stalled keyword in BMO

[Emma Humphries]

At Randell Jesup's suggestion, I've created a `stalled` keyword in
bugzilla. This keyword is intended for bugs for which we want to keep open,
but have currently exhausted all our attempts to solve. The keyword is
documented on BMO and in our policy repo (
https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md)
but I've reproduced it below.The key takeaways:

   - Use this for bugs for which you've exhausted all opportunities to fix,
   but you want to keep open
   - Marking a bug with the `stalled` keyword takes it out of triage queues
   - `stalled` means we don't have a path forward on this bug but want to
   keep it open
   - use `leave-open` for when you want the bug to remain open after your
   patch has landed in M-C.

The stalled keyword

The extreme case of not-enough-information is one which cannot be answered
with a needinfo request. The reporter has shared all they know about the
bug, we are out of strategies to take to resolve it, but the bug should be
kept open.

Mark the bug as stalled by adding the stalled keyword to it. The keyword
will remove it from the list of bugs to be triaged.

The priority of stalled bugs should be '--' but other keywords may apply to
them.

Bugs which remain stalled for long periods of time should be reviewed, and
closed if necessary.

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

Intent to Disable Metadata:

[Emma Humphries]

There are two related requests to disable the use two tracking flag fields
in Bugzilla.

* https://bugzilla.mozilla.org/show_bug.cgi?id=1473002

Disable the verified-{aurora, beta, production} flag

We now use the status-firefoxNN flags for this.

* https://bugzilla.mozilla.org/show_bug.cgi?id=1473001

Disable the 'verifyme' keyword

We now use the qe-verify flag

Since it's a holiday in the US and people may not be back in the office
until next week, I'll wait until Tuesday the 10th to hear back on concerns
about disabling these, and then I'll follow through.

Sylvestre suggested these changes. You too can become a certified BMO
de-complexifiy-er (swag forthcoming). If you see a field, flag, or value we
aren't using and can be retired, open a bug in
bugzilla.mozilla.org::administration.


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

Re: Intent to disable 'backlog' tracking flag in Bugzilla

[Emma Humphries]

As I've not heard objections to this, I'm disabling the flag.

Thanks,

-- Emma

On Thu, Jun 28, 2018 at 12:19 AM Emma Humphries  wrote:

> The 'backlog' (originally known as 'blocking-loop') tracking flag, is
> available for bugs in Core::Audio/Video* and Core::WebRTC*.
>
> The flag is no longer used by the groups triaging and working on bugs in
> those components, and per a discussion with :drno (Nils Ohlmeier) I intend
> to disable setting this flag in new bugs.
>
> Disabling this flag *will not* affect the value of it on bugs which have
> it set. It will still show up and you can search on values of the flag.
>
> If there are no objections to this, I'll disable the flag on Monday, July
> 2nd.
>
> The bug for this task is
> https://bugzilla.mozilla.org/show_bug.cgi?id=1471819.
>
> Thanks,
>
> Emma
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to disable 'backlog' tracking flag in Bugzilla

[Emma Humphries]

The 'backlog' (originally known as 'blocking-loop') tracking flag, is
available for bugs in Core::Audio/Video* and Core::WebRTC*.

The flag is no longer used by the groups triaging and working on bugs in
those components, and per a discussion with :drno (Nils Ohlmeier) I intend
to disable setting this flag in new bugs.

Disabling this flag *will not* affect the value of it on bugs which have it
set. It will still show up and you can search on values of the flag.

If there are no objections to this, I'll disable the flag on Monday, July
2nd.

The bug for this task is
https://bugzilla.mozilla.org/show_bug.cgi?id=1471819.

Thanks,

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

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Emma Humphries]

My thanks to everyone who had commented on this so far. I’m replying to
your questions and comments in this email so that we don’t have a threading
catastrophe.

First, several of you mentioned the typo where I wrote qa-verify when the
flag is qe-verify. The policy document has the correct flag name.

Second, this is not process for the sake of process, but so that Program
and Release Management, PI, and engineering leadership can quickly assess
what is happening with features.

Please note that Program / Release Management did not come up with this
policy on our own.  The Firefox engineering teams were simultaneously
looking to create a similar policy to further alleviate releases where a
feature is inadvertently not tested or enabled.  A recent item was the
Retained Display list not be turned on.

There’s also some question about what qe-verify means. It can be requested
by anyone with editbugs and granted by anyone with editbugs. And `+` does
not mean the bug is verified, but that QA will verify the the fix and set
the bug’s resolution to VERIFIED. I’ve updated that in the document (at
https://github.com/mozilla/bug-handling/commit/9b461160df743262aa6ecb7e6a033872ce393ff1
).

Liz Henry points out we should be clear in the policy what VERIFIED means
here for testing and sign-off.

:mossop asked about the Trello board, it’s at
https://trello.com/b/8k1hT2vh/firefox (if you need access, please ask
:elan) and we use the board to track features of note so that we know to
communicate them through release notes and other channels. Since we’re
using a flag to indicate features behind a pref, we can use queries to
indicate features that need to go on that board.

Nick Alexander mentioned that features which interact with the OS, mobile
OSes (Android and iOS) are all or nothing. This policy does not mean you
must release behind a pref. But if you are releasing a feature that depends
on a change to your OS, the bug for the feature must note that. That sort
of change may not be atomic in nature, so early warning and notification of
Project and Release Management, and PI is important.

Jared Wein asked in the thread; MattN, and Mark Banner asked in Issues (
https://github.com/mozilla/bug-handling/issues/4, and
https://github.com/mozilla/bug-handling/issues/4) about feature work
involving large numbers of bugs associated with a [meta] bug. Mark’s
suggestion where the flag is associated with the meta bug, but not the
dependent bugs is most likely the way to go.

Ritu Kothari and D. Baron asked about managing features across release
trains. The behind-pref may need to be a status flag instead of a simple
flag since the target version field only indicates when a bug landed in M-C
and bugs supporting a feature may land across multiple releases. I’ve
started a discussion of this at
https://github.com/mozilla/bug-handling/issues/5.

Several of you note that we’ve overloaded preferences. And perhaps we
should think about releasing features under a feature flag system. I think
that would afford us a way to move features toggling to the pref panes
(even if we keep feature flags in a namespaced area in prefs.)

Finally, I need to talk more with Shield/Normandy about this and make sure
I’m not sabotaging you.

Thank you all for your feedback and for helping us ship high quality code.

— Emma

On Wed, May 2, 2018 at 4:57 PM Emma Humphries <e...@mozilla.com> wrote:

> Hello,
>
> We control enabling many features and changes to Firefox using preferences.
>
> Program and Release management as well as PI need a better view of this.
>
> We've written a new policy which you can read on our nascent bug-handling
> mini-site:
>
> https://github.com/mozilla/bug-handling/blob/master/policy/feature-flags.md
>
> To summarize, when you are releasing a feature that "rides behind a flag",
> on the bug for the feature:
>
> * set the behind-pref flag to +
> * set the qa-verify flag to ?
> * note the bug in the Firefox Feature Trello board
>
> We expect qa-verify to be set to + before enabling prefs on features.
>
> We'll be going over this at two upcoming meetings, with Reese's and JoeH's
> teams.
>
> There are two, known open questions to resolve on the policy:
>
> * Features developed over multiple releases with individual patches not
> verifiable by external testing (passing unit tests, but not integration
> tests) such as Hello and WebRTC
> * Features are often turned on in Nightly, ignoring prefs using compiler
> directives, and kept off in Beta and Release. Is this the right thing to
> do, or should we be flipping prefs from on to off when going from Nightly
> to Beta and forwards?
>
> The bug handling documentation is a GitHub repo to enable web publishing,
> please follow up there, using Issues and PRs, rather than to this email.
>
> I want to acknowledge and thank: Liz Henry, Ritu Kothari, Resse Morris,
> Er

New Policy: Marking Bugzilla bugs for features riding behind a pref

[Emma Humphries]

Hello,

We control enabling many features and changes to Firefox using preferences.

Program and Release management as well as PI need a better view of this.

We've written a new policy which you can read on our nascent bug-handling
mini-site:

https://github.com/mozilla/bug-handling/blob/master/policy/feature-flags.md

To summarize, when you are releasing a feature that "rides behind a flag",
on the bug for the feature:

* set the behind-pref flag to +
* set the qa-verify flag to ?
* note the bug in the Firefox Feature Trello board

We expect qa-verify to be set to + before enabling prefs on features.

We'll be going over this at two upcoming meetings, with Reese's and JoeH's
teams.

There are two, known open questions to resolve on the policy:

* Features developed over multiple releases with individual patches not
verifiable by external testing (passing unit tests, but not integration
tests) such as Hello and WebRTC
* Features are often turned on in Nightly, ignoring prefs using compiler
directives, and kept off in Beta and Release. Is this the right thing to
do, or should we be flipping prefs from on to off when going from Nightly
to Beta and forwards?

The bug handling documentation is a GitHub repo to enable web publishing,
please follow up there, using Issues and PRs, rather than to this email.

I want to acknowledge and thank: Liz Henry, Ritu Kothari, Resse Morris,
Erin Lancaster, Ryan VM, Thomas Elin, and Adam Roach for their comments and
feedback on this.

Thank you!

-- Emma Humphries
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is super-review still a thing?

[Emma Humphries]

I’m away from my computer until the morning, but I think we disabled the 
super-review flag. 

If Kris and David want to draft an architectural review policy that would be 
useful, and we could set up the flags at the right level

> On Apr 20, 2018, at 23:51, L. David Baron  wrote:
> 
>> On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:
>> For a lot of these patches, my opinion is only really critical for certain
>> architectural aspects, or implementation aspects at a few critical points.
>> There are other reviewers who are perfectly qualified to do a more detailed
>> review of the specifics of the patch, and have more spare cycles to devote
>> to it. Essentially, what's needed from me in these cases is a super-review,
>> which I can do fairly easily, but instead I become a bottleneck for the code
>> review as well.
>> 
>> So, for the areas where I have this responsibility, I'd like to institute a
>> policy that certain types of changes need a final super-review from me, but
>> should get a detailed code review from another qualified reviewer when that
>> makes sense.
> 
> I think it's reasonable to use the super-review flag for this sort
> of high-level or design review, at least until we come up with a
> better name for it (and make a new flag, and retire the old one).  I
> don't think the super-review policy (as written) is meaningful
> today.
> 
> -David
> 
> -- 
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
> Before I built a wall I'd ask to know
> What I was walling in or walling out,
> And to whom I was like to give offense.
>   - Robert Frost, Mending Wall (1914)
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Policy] Tracking Regressions in Firefox Components Managed in GitHub Projects

[Emma Humphries]

And I misspelled Glob's name. That's Byron Jones. Sorry about that.

-- Emma

On Tue, Apr 10, 2018 at 4:18 PM, Emma Humphries <e...@mozilla.com> wrote:

> Release Management and the weekly regression triage must be aware of the
> status of all reported regressions in order to assure we are not shipping
> known regressions in Firefox releases.
>
> If a team is using GitHub to manage their part of the Firefox project,
> there’s a risk that those groups might not see a regression.
>
> We need an agreed to standard for how we keep track of these.
> An initial version of this policy has been written and is available for
> inspection at https://github.com/mozilla/bug-handling/blob/master/
> policy/regressions-github.md
>
> If you have questions or concerns, please submit a pull-request against
> this repository or contact me through email, IRC, or Slack.
>
> I want to thank Ritu Kothari, Liz Henry, Mark Côté, Myk Melez, Wil
> Clouser, Jim Mathies, Edward Lee, Mike Taylor, Chris Karloff, and Bryon
> 'Glob' Jones for their review and comments on earlier drafts of this
> policy.
>
> -- Emma Humphries, Bugmaster, Firefox
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Policy] Tracking Regressions in Firefox Components Managed in GitHub Projects

[Emma Humphries]

Release Management and the weekly regression triage must be aware of the
status of all reported regressions in order to assure we are not shipping
known regressions in Firefox releases.

If a team is using GitHub to manage their part of the Firefox project,
there’s a risk that those groups might not see a regression.

We need an agreed to standard for how we keep track of these.
An initial version of this policy has been written and is available for
inspection at
https://github.com/mozilla/bug-handling/blob/master/policy/regressions-github.md

If you have questions or concerns, please submit a pull-request against
this repository or contact me through email, IRC, or Slack.

I want to thank Ritu Kothari, Liz Henry, Mark Côté, Myk Melez, Wil Clouser,
Jim Mathies, Edward Lee, Mike Taylor, Chris Karloff, and Bryon 'Glob' Jones
for their review and comments on earlier drafts of this policy.

-- Emma Humphries, Bugmaster, Firefox
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Flow Engineering Newsletter #25

[Emma Humphries]

> So, instead of using the [qf] status whiteboard tag, we will use the
existing perf keyword
 in Bugzilla, and
when triaging, teams will use the normal Bugzilla Priority fields to assign
priority to the performance bugs.  The existing set of open QF bugs will be
moved to use the perf keyword as well to unify how we handle these bugs.

I want to call out the importance of using a consistent metadata language
so we
​*all* ​
understand the state of our bugs, and
​know what ​
we need to fix or complete for a release. We're already using this to drive
decision making for Firefox 57.

Some of you have already moved from custom whiteboard tagging in your areas
to the P1-P3, P5 nomenclature. After Firefox 57, we'll work on getting
everyone consistent.

Thanks to you all for making a sleek and elegant release.

-- Emma

On Thu, Sep 21, 2017 at 1:38 PM, Ehsan Akhgari 
wrote:

> [You can read a version of this with better formatting on my blog:
> https://ehsanakhgari.org/blog/2017-09-21/quantum-flow-engine
> ering-newsletter-25]
>
> Hi everyone,
>
> The Quantum Flow project started as a cross-functional effort to study and
> fix the most serious performance issues of Firefox affecting real world
> browsing use cases for the Firefox 57 release.  Thanks to the hard work of
> everyone who helped us along the way, we believe that we have managed to
> fix a significant portion of the issues discovered in the past seven months
> or so that this project has run and have managed to achieve the performance
> goals that we had set for ourselves.
> A Short Retrospective
>
> Looking back at the past months, the Quantum Flow project went through
> three different stages in terms of the type of issues we focused on (even
> though these stages weren't consecutive in time).  In the first stage, we
> focused most of our energy on gathering information about performance
> issues and planning work that would fit in the scope of Firefox 57.  A lot
> of time was spent doing profiling and measurements to gather evidence
> around the most problematic areas of the code needing attention.  We also
> spent time thinking about what parts of our plans may or may not finish in
> time for Firefox 57, and thought about which issues were the most urgent to
> fix, and which ones could be deprioriotized to future releases.  In this
> time we had a work week
> 
> to consult various platform teams for help in various areas of their
> expertise.
>
> After the scope of all the work that was necessary to be done became more
> clear, we knew that we needed help from other teams to oversee some aspects
> of the ongoing work independently.  We started to work with the Firefox
> front-end team to ask for their help on reducing synchronous layout/style
> flushes and scheduled timers in the UI code.  That relationship grew with
> their effort on reducing the browser start-up time (which has been a great
> success so far!) and eventually with the Photon Performance project in
> place, the amount of effort on the Quantum Flow side to keep track of the
> UI performance was greatly reduced, which was a huge help.  Another
> successful example here was working with the layout team to improve
> reflow performance
> .  During our
> measurements we had seen a lot of reflow performance issues, which were not
> easy for us to diagnose and analyze.  The layout team was really busy with
> a lot of ongoing work all along, but they did a great job at keeping track
> of the issues we reported to them and fix the ones which were important.
> They also didn't stop there, a lot of great work happened based on other
> independent investigations which would benefit reflow performance in these
> past few months.
>
> The last stage and the longest running one perhaps was a cross-functional
> effort at fixing the bugs we had discovered and prioritized which I'm sure
> you are all familiar with by now.  There were some challenges to overcome
> here.  Perhaps the most obvious was the sheer number of bugs at hand.  I
> remember triage meetings with 50+ bugs to go through, and we had to be
> careful to not miscategorize something or not miss something important.
> The other challenge was the amount of time we had and the number of people
> who could help with fixing the bugs.  The number of person-hours of help we
> could get from each team depended on the existing workload of the team and
> their other priorities, so sometimes it was hard to predict how much help
> we can count on in a given area especially in the earlier stages.  As more
> people got involved, we needed to do more communication to make sure things
> kept moving forward, and nobody was blocked on something where we could
> give help.  Because of the number of bugs on our plate, we also always
> needed 

Re: Intermittent oranges and when to disable the related test case - a simplified policy

[Emma Humphries]

Andrew Swan noticed that whiteboard tag was showing up on bugs not filed by
the intermittent-test-failure bot (thanks!)

Here's the queries restricted to just bot filed bugs:

https://mzl.la/2eMnMRz (add ons)
https://mzl.la/2eMaPqQ (all core/ffx/toolkit)

This begs the question, why was that whiteboard tag being used that way?


On Wed, Sep 6, 2017 at 4:32 PM, Emma Humphries <e...@mozilla.com> wrote:

> Andy
>
> To start:
>
> https://bugzilla.mozilla.org/buglist.cgi?product=Core;
> product=Firefox=Firefox%20for%20Android&
> product=Firefox%20for%20iOS=Toolkit_format=
> advanced=---_whiteboard=test%20disabled%2Ctest-disabled%
> 2Ctestdisabled_whiteboard_type=anywordssubstr=bug_id=0
>
> Add-ons, Web Extensions, and Plugins related:
>
> https://bugzilla.mozilla.org/buglist.cgi?resolution=---;
> status_whiteboard_type=anywordssubstr_format=
> advanced_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled&
> component=Add-on%20Manager=Add-ons%20Manager&
> component=Plug-ins=WebExtensions%3A%20Android&
> component=WebExtensions%3A%20Compatibility=
> WebExtensions%3A%20Developer%20Tools=WebExtensions%3A%
> 20Experiments=WebExtensions%3A%20Frontend&
> component=WebExtensions%3A%20General=WebExtensions%3A%20Request%
> 20Handling=WebExtensions%3A%20Untriaged&
> product=Core=Firefox=Firefox%20for%
> 20Android=Firefox%20for%20iOS=Toolkit
>
> On Wed, Sep 6, 2017 at 3:46 PM, Andrew McKay <amc...@mozilla.com> wrote:
>
>> Is there an easy way for me to track what tests have been disabled as
>> result of intermittent issues we haven't been able to fix?
>>
>> On 6 September 2017 at 14:10,  <jma...@mozilla.com> wrote:
>> > Over the last 9 months a few of us have really watched intermittent
>> test failures almost daily and done a lot to pester people as well as fix
>> many.  While there are over 420 bugs that have been fixed since the
>> beginning of the year, there are half that many (211+) which have been
>> disabled in some form (including turning off the jobs).
>> >
>> > We don't like to disable and have been pretty relaxed in recommending
>> disabling a test.  Overall we have tried to adhere to a policy of:
>> > * >=30 failures/week- ask for owner to look at failure and fix it, if
>> this persists for a few weeks with no real traction we would go ahead [and
>> recommend] disabling it.
>> > * >= 75 failures/week- ask for people to fix this in a shorter time
>> frame and recommend disabling the test in a week or so
>> > * >= 150 failures/week- often just disable the test
>> >
>> > This is confusing and hard to manage.  Since then we have started
>> adjusting triage queries and some teams are doing their own triage and we
>> are ignoring those bugs (while they are getting prioritized properly).
>> >
>> > What we are looking to start doing this month is adopting a simpler
>> policy:
>> > * any bug that has >=200 instances in the last 30 days will be disabled
>> > ** this will be a manual process, so it will happen a couple times/week
>> >
>> > We expect the outcome of this to be a similar amount of disabling, just
>> an easier method for doing so.  It is very possible we might recommend
>> disabling a test before it hits the threshold- keep in mind a disabled test
>> is easy to re-enable (so feel free to disable for that one platform until
>> you have time to look at fixing it)
>> >
>> > To be clear we (and some component owners) will continue triaging bugs
>> and trying to get fixes in place as often as possible and prefer a fix, not
>> a disabled test!
>> >
>> > Please raise any concerns, otherwise we will move forward with this in
>> the coming weeks.
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intermittent oranges and when to disable the related test case - a simplified policy

[Emma Humphries]

In order to be more consistent, marking a failing test as disabled should
be done with a keyword instead of a whiteboard tag.

Proposed keyword: test-disabled
Description: Used by test automation team to indicate the failing test
associated with this bug has a failure rate above a threshold level and has
been disabled. To check the consistency of this keyword, bugs with it
keyword should be filed by the intermittent-bug-filer user.

On Wed, Sep 6, 2017 at 2:10 PM,  wrote:

> Over the last 9 months a few of us have really watched intermittent test
> failures almost daily and done a lot to pester people as well as fix many.
> While there are over 420 bugs that have been fixed since the beginning of
> the year, there are half that many (211+) which have been disabled in some
> form (including turning off the jobs).
>
> We don't like to disable and have been pretty relaxed in recommending
> disabling a test.  Overall we have tried to adhere to a policy of:
> * >=30 failures/week- ask for owner to look at failure and fix it, if this
> persists for a few weeks with no real traction we would go ahead [and
> recommend] disabling it.
> * >= 75 failures/week- ask for people to fix this in a shorter time frame
> and recommend disabling the test in a week or so
> * >= 150 failures/week- often just disable the test
>
> This is confusing and hard to manage.  Since then we have started
> adjusting triage queries and some teams are doing their own triage and we
> are ignoring those bugs (while they are getting prioritized properly).
>
> What we are looking to start doing this month is adopting a simpler policy:
> * any bug that has >=200 instances in the last 30 days will be disabled
> ** this will be a manual process, so it will happen a couple times/week
>
> We expect the outcome of this to be a similar amount of disabling, just an
> easier method for doing so.  It is very possible we might recommend
> disabling a test before it hits the threshold- keep in mind a disabled test
> is easy to re-enable (so feel free to disable for that one platform until
> you have time to look at fixing it)
>
> To be clear we (and some component owners) will continue triaging bugs and
> trying to get fixes in place as often as possible and prefer a fix, not a
> disabled test!
>
> Please raise any concerns, otherwise we will move forward with this in the
> coming weeks.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intermittent oranges and when to disable the related test case - a simplified policy

[Emma Humphries]

Andy

To start:

https://bugzilla.mozilla.org/buglist.cgi?product=Core=Firefox=Firefox%20for%20Android=Firefox%20for%20iOS=Toolkit_format=advanced=---_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled_whiteboard_type=anywordssubstr=bug_id=0

Add-ons, Web Extensions, and Plugins related:

https://bugzilla.mozilla.org/buglist.cgi?resolution=---_whiteboard_type=anywordssubstr_format=advanced_whiteboard=test%20disabled%2Ctest-disabled%2Ctestdisabled=Add-on%20Manager=Add-ons%20Manager=Plug-ins=WebExtensions%3A%20Android=WebExtensions%3A%20Compatibility=WebExtensions%3A%20Developer%20Tools=WebExtensions%3A%20Experiments=WebExtensions%3A%20Frontend=WebExtensions%3A%20General=WebExtensions%3A%20Request%20Handling=WebExtensions%3A%20Untriaged=Core=Firefox=Firefox%20for%20Android=Firefox%20for%20iOS=Toolkit

On Wed, Sep 6, 2017 at 3:46 PM, Andrew McKay  wrote:

> Is there an easy way for me to track what tests have been disabled as
> result of intermittent issues we haven't been able to fix?
>
> On 6 September 2017 at 14:10,   wrote:
> > Over the last 9 months a few of us have really watched intermittent test
> failures almost daily and done a lot to pester people as well as fix many.
> While there are over 420 bugs that have been fixed since the beginning of
> the year, there are half that many (211+) which have been disabled in some
> form (including turning off the jobs).
> >
> > We don't like to disable and have been pretty relaxed in recommending
> disabling a test.  Overall we have tried to adhere to a policy of:
> > * >=30 failures/week- ask for owner to look at failure and fix it, if
> this persists for a few weeks with no real traction we would go ahead [and
> recommend] disabling it.
> > * >= 75 failures/week- ask for people to fix this in a shorter time
> frame and recommend disabling the test in a week or so
> > * >= 150 failures/week- often just disable the test
> >
> > This is confusing and hard to manage.  Since then we have started
> adjusting triage queries and some teams are doing their own triage and we
> are ignoring those bugs (while they are getting prioritized properly).
> >
> > What we are looking to start doing this month is adopting a simpler
> policy:
> > * any bug that has >=200 instances in the last 30 days will be disabled
> > ** this will be a manual process, so it will happen a couple times/week
> >
> > We expect the outcome of this to be a similar amount of disabling, just
> an easier method for doing so.  It is very possible we might recommend
> disabling a test before it hits the threshold- keep in mind a disabled test
> is easy to re-enable (so feel free to disable for that one platform until
> you have time to look at fixing it)
> >
> > To be clear we (and some component owners) will continue triaging bugs
> and trying to get fixes in place as often as possible and prefer a fix, not
> a disabled test!
> >
> > Please raise any concerns, otherwise we will move forward with this in
> the coming weeks.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[no subject]

[Emma Humphries]

It's the weekly report on the state of triage in Firefox-related components.

Marking Bugs for the Firefox 57 Release

The bug that will overshadow all the hard work we put into the Firefox 57
release has probably already been filed. We need to find it and fix it. If
you think a bug might affect users in the 57 release, please set the
correct Firefox versions affected in the bug, and then set the
tracking-request flag to request tracking of bug by release management team
.


Poll Result

It’s not a large sample, but by an 8-1-1 margin, you said you’d like a
logged-in BMO home page like: https://fitzgen.github.io/bugzilla-todos/.

Now, the catch. We don’t have staff to work on this, but I’ve filed a bug,
https://bugzilla.mozilla.org/show_bug.cgi?id=1397063 to do this work. If
you’d like undying gratitude, and some WONTFIX swag, grab this bug.

Hotspots

The components with the most untriaged bugs remain the JavaScript Engine
and Build Config.

Rank

Component

Last Week

This Week

1

Core: JavaScript Engine

477

472

2

Core: Build Config

459

455

3

Firefox for Android: General

408

415

4

Firefox: General

254

258

5

Core: General

241

235

6

Core: JavaScript: GC

180

175

7

Core: XPCOM

171

172

8

Core: Networking

159

167

All Components

8,822

8,962

Please make sure you’ve made it clear what, if anything will happen with
these bugs.

Not sure how to triage? Read
https://wiki.mozilla.org/Bugmasters/Process/Triage.


We know the JS numbers are artificially-high, and working on a solution for
cleaning that up.

Next Release


Version

56

56

57

57

57

57

Date

7/31

8/7

8/14

8/21

8/21

9/5

Untriaged this Cycle

4,479

479

835

1,196

1,481

1,785

Unassigned Untriaged this Cycle

3,674

356

634

968

1,266

1,477

Affected this Release

139

125

123

119

42

83

Enhancements

103

3

5

11

17

15

Orphaned P1s

192

196

191

183

18

23

Stalled P1s

179

157

152

155

13

23

What should we do with these bugs? Bulk close them? Make them into P3s?
Bugs without decisions add noise to our system, cause despair in those
trying to triage bugs, and leaves the community wondering if we listen to
them.

Methods and Definitions

In this report I talk about bugs in Core, Firefox, Firefox for Android,
Firefox for IOs, and Toolkit which are unresolved, not filed from
treeherder using the intermittent-bug-filer account*, and have no pending
needinfos.

By triaged, I mean a bug has been marked as P1 (work on now), P2 (work on
next), P3 (backlog), or P5 (will not work on but will accept a patch).

https://wiki.mozilla.org/Bugmasters#Triage_Process

A triage decision is not the same as a release decision (status and
tracking flags.)

https://mozilla.github.io/triage-report/#report

Untriaged Bugs in Current Cycle

Bugs filed since the start of the Firefox 57 release cycle (August 2nd,
2017) which do not have a triage decision.

https://mzl.la/2wzJxLP

Recommendation: review bugs you are responsible for (
https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html) and make
triage decision, or RESOLVE.

Untriaged Bugs in Current Cycle Affecting Next Release

Bugs marked status_firefox56 = affected and untriaged.

https://mzl.la/2wzjHaH

Enhancements in Release Cycle

Bugs filed in the release cycle which are enhancement requests, severity =
enhancement, and untriaged.

https://mzl.la/2wzCBy8

​Recommendation: ​product managers should review and mark as P3, P5, or
RESOLVE as WONTFIX.

High Priority Bugs without Owners

Bugs with a priority of P1, which do not have an assignee, have not been
modified in the past two weeks, and do not have pending needinfos.

https://mzl.la/2sJxPbK

Recommendation: review priorities and assign bugs, re-prioritize to P2, P3,
P5, or RESOLVE.

Inactive High Priority Bugs

There 159 bugs with a priority of P1, which have an assignee, but have not
been modified in the past two weeks.

https://mzl.la/2u2poMJ

Recommendation: review assignments, determine if the priority should be
changed to P2, P3, P5 or RESOLVE.

Stale Bugs

Bugs in need of review by triage owners. Updated weekly.

https://mzl.la/2wNyONP

* New intermittents are filed as P5s, and we are still cleaning up bugs
after this change, See  https://bugzilla.mozilla.org/show_bug.cgi?id=1381587
,
https://bugzilla.mozilla.org/show_bug.cgi?id=1381960, and
https://bugzilla.mozilla.org/show_bug.cgi?id=1383923

If you have questions or enhancements you want to see in this report,
please reply to me here, on IRC, or Slack and thank you for reading.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Triage Report 2017-08-28

[Emma Humphries]

It's the weekly report on the state of triage in Firefox-related components.

Poll

Would you like a logged in BMO home page like:
https://fitzgen.github.io/bugzilla-todos/?

https://twitter.com/triagegirl/status/902327322178609153

Hotspots

The components with the most untriaged bugs remain the JavaScript Engine
and Build Config.

Rank

Component

Last Week

This Week

1

Core: JavaScript Engine

471

477

2

Core: Build Config

450

459

3

Firefox for Android: General

406

408

4

Firefox: General

246

254

5

Core: General

235

241

6

Core: XPCOM

178

180

7

Core: JavaScript: GC

168

171

8

Core: Networking

161

159

All Components

8,703

8,822

Please make sure you’ve made it clear what, if anything will happen with
these bugs.

Not sure how to triage? Read
https://wiki.mozilla.org/Bugmasters/Process/Triage.

Next Release


Version

56

56

57

57

57

Date

7/31

8/7

8/14

8/21

8/28

Untriaged this Cycle

4,479

479

835

1,196

1,481

Unassigned Untriaged this Cycle

3,674

356

634

968

1,266

Affected this Release

139

125

123

119

42

Enhancements

103

3

5

11

17

Orphaned P1s

192

196

191

183

18

Inactive P1s

179

157

152

155

13

Stale Bugs

–

–

–

–

117


What should we do with these bugs? Bulk close them? Make them into P3s?
Bugs without decisions add noise to our system, cause despair in those
trying to triage bugs, and leaves the community wondering if we listen to
them.

Bugs I Want to Close

There are over 10,000 unconfirmed bugs with no activity in at least a year.

https://mzl.la/2wNLrbS

There are over 45,000 bugs which are not in the General or Untriaged
components with no activity in at least a year.

https://mzl.la/2wNXiGC

I would like to close these.

Once the noise-free closing script is ready, my plan is to automate bug
stewardship.

Methods and Definitions

In this report I talk about bugs in Core, Firefox, Firefox for Android,
Firefox for IOs, and Toolkit which are unresolved, not filed from
treeherder using the intermittent-bug-filer account*, and have no pending
needinfos.

By triaged, I mean a bug has been marked as P1 (work on now), P2 (work on
next), P3 (backlog), or P5 (will not work on but will accept a patch).

https://wiki.mozilla.org/Bugmasters#Triage_Process

A triage decision is not the same as a release decision (status and
tracking flags.)

https://mozilla.github.io/triage-report/#report

Untriaged Bugs in Current Cycle

Bugs filed since the start of the Firefox 57 release cycle (August 2nd,
2017) which do not have a triage decision.

https://mzl.la/2wzJxLP

Recommendation: review bugs you are responsible for (
https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html) and make
triage decision, or RESOLVE.

Untriaged Bugs in Current Cycle Affecting Next Release

Bugs marked status_firefox56 = affected and untriaged.

https://mzl.la/2wzjHaH

Enhancements in Release Cycle

Bugs filed in the release cycle which are enhancement requests, severity =
enhancement, and untriaged.

https://mzl.la/2wzCBy8

​Recommendation: ​product managers should review and mark as P3, P5, or
RESOLVE as WONTFIX.

High Priority Bugs without Owners

Bugs with a priority of P1, which do not have an assignee, have not been
modified in the past two weeks, and do not have pending needinfos.

https://mzl.la/2sJxPbK

Recommendation: review priorities and assign bugs, re-prioritize to P2, P3,
P5, or RESOLVE.

Inactive High Priority Bugs

There 159 bugs with a priority of P1, which have an assignee, but have not
been modified in the past two weeks.

https://mzl.la/2u2poMJ

Recommendation: review assignments, determine if the priority should be
changed to P2, P3, P5 or RESOLVE.

Stale Bugs

Bugs in need of review by triage owners. Updated weekly.

https://mzl.la/2wNyONP


If you have questions or enhancements you want to see in this report,
please reply to me here, on IRC, or Slack and thank you for reading.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Summary 2017-08-21

[Emma Humphries]

Correcting some links at the bottom of this report:

*Untriaged Bugs in Current Cycle*

Bugs filed since the start of the Firefox 57 release cycle which do not
have a triage decision.

https://mzl.la/2wzJxLP

Recommendation: review bugs you are responsible for
([*
https://bugzilla.mozilla.org/page.cgi?id=triage\_owners.html*](https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html)
)
and make triage decision, or RESOLVE.

*Untriaged Bugs in Current Cycle (57) Affecting Next Release (56)*

Bugs marked status\_firefox56 = affected and untriaged.

https://mzl.la/2wzjHaH

*Enhancements in Release Cycle*

Bugs filed in the release cycle which are enhancement requests, severity
= enhancement, and untriaged.

https://mzl.la/2wzCBy8

​Recommendation: ​product managers should review and mark as P3, P5, or
RESOLVE as WONTFIX.

*High Priority Bugs without Owners*

Bugs with a priority of P1, which do not have an assignee, have not been
modified in the past two weeks, and do not have pending needinfos.

https://mzl.la/2u1VLem

Recommendation: review priorities and assign bugs, re-prioritize to P2,
P3, P5, or RESOLVE.

*Stalled High Priority Bugs*

There 159 bugs with a priority of P1, which have an assignee, but have
not been modified in the past two weeks.

https://mzl.la/2u2poMJ

Recommendation: review assignments, determine if the priority should be
changed to P2, P3, P5 or RESOLVE.

On Mon, Aug 21, 2017 at 4:01 PM, Emma Humphries <e...@mozilla.com> wrote:

> It's the weekly report on the state of triage in Firefox-related
> components. I apologize for missing last week’s report. I was travelling
> and did not have a chance to sit down and focus on this.
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Triage Summary 2017-08-21

[Emma Humphries]

It's the weekly report on the state of triage in Firefox-related
components. I apologize for missing last week’s report. I was travelling
and did not have a chance to sit down and focus on this.

Hotspots

The components with the most untriaged bugs remain the JavaScript Engine
and Build Config.

I discussed the JavaScript bugs with Naveed. What will happen is that the
JavaScript bugs which have not been marked as a priority for Quantum Flow
(the ‘\[qf:p[1:3]\]’ whiteboard tags) or existing work (the ‘\[js:p[1:3]\]’
whiteboard tags) will be moved to the backlog (P3) for review after the
Firefox 57 release. See https://bugzilla.mozilla.org/show_bug.cgi?id=1392436
.

Rank

Component

2017-08-07

This Week

1

Core: JavaScript Engine

449

471

2

Core: Build Config

429

450

3

Firefox for Android: General

411

406

4

Firefox: General

242

246

5

Core: General

234

235

6

Core: XPCOM

176

178

7

Core: JavaScript: GC

—

168

8

Core: Networking

—

161

All Components

8,373

8,703

Please make sure you’ve made it clear what, if anything will happen with
these bugs.

Not sure how to triage? Read
https://wiki.mozilla.org/Bugmasters/Process/Triage.

Next Release


Version

56

56

56

56

57

57

57


Date

7/10

7/17

7/24

7/31

8/7

8/14

8/14


Untriaged this Cycle

4,525

4,451

4,317

4,479

479

835

1,196


Unassigned Untriaged this Cycle

3,742

3,682

3,517

3,674

356

634

968


Affected this Upcoming Release (56)

111

126

139

125

123

119


Enhancements

102

107

91

103

3

5

11


Orphaned P1s

199

193

183

192

196

191

183


Stalled P1s

195

173

159

179

157

152

155





What should we do with these bugs? Bulk close them? Make them into P3s?
Bugs without decisions add noise to our system, cause despair in those
trying to triage bugs, and leaves the community wondering if we listen to
them.

Methods and Definitions

In this report I talk about bugs in Core, Firefox, Firefox for Android,
Firefox for IOs, and Toolkit which are unresolved, not filed from
treeherder using the intermittent-bug-filer account*, and have no pending
needinfos.

By triaged, I mean a bug has been marked as P1 (work on now), P2 (work on
next), P3 (backlog), or P5 (will not work on but will accept a patch).

A triage decision is not the same as a release decision (status and
tracking flags.)

https://mozilla.github.io/triage-report/#report

Age of Untriaged Bugs

The average age of a bug filed since June 1st of 2016 which has gone
without triage.

https://mozilla.github.io/triage-report/#date-report

Untriaged Bugs in Current Cycle

Bugs filed since the start of the Firefox 55 release cycle (March 6th,
2017) which do not have a triage decision.

https://mzl.la/2u1R7gA

Recommendation: review bugs you are responsible for (
https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html) and make
triage decision, or RESOLVE.

Untriaged Bugs in Current Cycle Affecting Next Release

Bugs marked status_firefox56 = affected and untriaged.

https://mzl.la/2u2GCcG

Enhancements in Release Cycle

Bugs filed in the release cycle which are enhancement requests, severity =
enhancement, and untriaged.

​Recommendation: ​product managers should review and mark as P3, P5, or
RESOLVE as WONTFIX.

High Priority Bugs without Owners

Bugs with a priority of P1, which do not have an assignee, have not been
modified in the past two weeks, and do not have pending needinfos.

https://mzl.la/2u1VLem

Recommendation: review priorities and assign bugs, re-prioritize to P2, P3,
P5, or RESOLVE.

Stalled High Priority Bugs

There 159 bugs with a priority of P1, which have an assignee, but have not
been modified in the past two weeks.

https://mzl.la/2u2poMJ

Recommendation: review assignments, determine if the priority should be
changed to P2, P3, P5 or RESOLVE.

* New intermittents are filed as P5s, and we are still cleaning up bugs
after this change, See  https://bugzilla.mozilla.org/show_bug.cgi?id=1381587
,
https://bugzilla.mozilla.org/show_bug.cgi?id=1381960, and
https://bugzilla.mozilla.org/show_bug.cgi?id=1383923

If you have questions or enhancements you want to see in this report,
please reply to me here, on IRC, or Slack and thank you for reading.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Triage Summary 2017-08-07

[Emma Humphries]

It's the weekly report on the state of triage in Firefox-related
components. I’m writing this from a cafe in Helsink where the sun just came
out.

Hotspots

The components with the most untriaged bugs remain the JavaScript Engine
and Build Config. It is great to see the number of untriaged bugs in Core:
Graphics drop by half. Thank you, Milan. But JavaScript Engine, y’all need
to do something with all your untriaged bugs. Are these bugs generated by
automation like the intermittent test failure bugs?

Rank

Component

Last Week

This Week

1

Core: JavaScript Engine

446

449

2

Core: Build Config

421

429

3

Firefox for Android: General

410

411

4

Core: General

239

234

5

Firefox: General

238

242

6

Core: XPCOM

178

176

7

Core: Disability Access APIs

162

159

8

Core: Graphics

194

91

All Components

8,543

8,373

Please make sure you’ve made it clear what, if anything will happen with
these bugs.

Not sure how to triage? Read
https://wiki.mozilla.org/Bugmasters/Process/Triage.

Next Release



Version

55

55

55

55

56

Date

2017-07-10

2017-07-17

2017-07-24

2017-07-31

2017-07-31

Untriaged this Cycle

4,525

4,451

4,317

4,479

479

Unassigned Untriaged this Cycle

3,742

3,682

3,517

3,674

356

Affected this Cycle

111

126

139

125

Enhancements

102

107

91

103

3

Orphaned P1s

199

193

183

192

196

Stalled P1s

195

173

159

179

157

What should we do with these bugs? Bulk close them? Make them into P3s?
Bugs without decisions add noise to our system, cause despair in those
trying to triage bugs, and leaves the community wondering if we listen to
them.

Note

I’m traveling from the 1st to the 17th. I plan to send out updates on the
7th and 14th, but they may be delayed.

Methods and Definitions

In this report I talk about bugs in Core, Firefox, Firefox for Android,
Firefox for IOs, and Toolkit which are unresolved, not filed from
treeherder using the intermittent-bug-filer account*, and have no pending
needinfos.

By triaged, I mean a bug has been marked as P1 (work on now), P2 (work on
next), P3 (backlog), or P5 (will not work on but will accept a patch).

A triage decision is not the same as a release decision (status and
tracking flags.)

https://mozilla.github.io/triage-report/#report

Age of Untriaged Bugs

The average age of a bug filed since June 1st of 2016 which has gone
without triage.

https://mozilla.github.io/triage-report/#date-report

Untriaged Bugs in Current Cycle

Bugs filed since the start of the Firefox 55 release cycle (March 6th,
2017) which do not have a triage decision.

https://mzl.la/2u1R7gA

Recommendation: review bugs you are responsible for (
https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html) and make
triage decision, or RESOLVE.

Untriaged Bugs in Current Cycle Affecting Next Release

Bugs marked status_firefox56 = affected and untriaged.

https://mzl.la/2u2GCcG

Enhancements in Release Cycle

Bugs filed in the release cycle which are enhancement requests, severity =
enhancement, and untriaged.

​Recommendation: ​product managers should review and mark as P3, P5, or
RESOLVE as WONTFIX.

High Priority Bugs without Owners

Bugs with a priority of P1, which do not have an assignee, have not been
modified in the past two weeks, and do not have pending needinfos.

https://mzl.la/2u1VLem

Recommendation: review priorities and assign bugs, re-prioritize to P2, P3,
P5, or RESOLVE.

Stalled High Priority Bugs

There 159 bugs with a priority of P1, which have an assignee, but have not
been modified in the past two weeks.

https://mzl.la/2u2poMJ

Recommendation: review assignments, determine if the priority should be
changed to P2, P3, P5 or RESOLVE.

* New intermittents are filed as P5s, and we are still cleaning up bugs
after this change, See  https://bugzilla.mozilla.org/show_bug.cgi?id=1381587
,
https://bugzilla.mozilla.org/show_bug.cgi?id=1381960, and
https://bugzilla.mozilla.org/show_bug.cgi?id=1383923

If you have questions or enhancements you want to see in this report,
please reply to me here, on IRC, or Slack and thank you for reading.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Status of Closing Intermittents

[Emma Humphries]

Two Sundays ago I went through and closed the first batch of intermittent
bugs with no new OrangeFactor (or other) comments. That was 5,000 bugs and
cause an bugmail storm.

I'm holding off on closing the next batch, because we need to run a script
to do this.

https://bugzilla.mozilla.org/show_bug.cgi?id=1381567

is tracking it.

Intermittent bugs don't count against totals in my reports, but I'd still
like to get these cleaned up.

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

Re: Bulk Closing Intermittents

[Emma Humphries]

Yes, my query for bugs to close filters for "leave-open".

Thanks!

-- Emma

On Wed, Jul 12, 2017 at 6:18 AM,  wrote:

> On Wednesday, 12 July 2017 04:09:52 UTC+1, Karl Tomlinson  wrote:
> > I assume this was integrated with OrangeFactor?
> >
> > That is the only way I know to determine whether an intermittent
> > failure has occurred, because failures are not necessarily
> > reported to bugzilla.
>
> This is no longer the case, see:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1372277
>
> > Is there a mechanism for tracking a failure that we intend to
> > addresss, even when it does not fail every 21 days?
> >
> > Would that be filing another bug without the intermittent-failure
> > keyword?
>
> I'd add the 'leave-open' keyword.
>
> Best wishes,
>
> Ed
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bulk Closing Intermittents

[Emma Humphries]

This was the first time we bulk closed these bugs, and there will be some
glitches. I don't consider this to be a blocker on continuing this work.

Next time we do this, it won't be 5,000+ bugs. OrangeBot runs on Sundays,
so we can do the cleanup on Monday.

The long term goal is to stop using Bugzilla to record every intermittent
test failure and only use it for test failures we intend to address.

-- Emma

On Mon, Jul 10, 2017 at 5:29 AM, Kartikaya Gupta <kgu...@mozilla.com> wrote:

> It might be a good idea to integrate this process with the
> OrangeFactor Robot, to avoid race conditions like what happened on bug
> 1328486 (it was bulk-closed, and then a couple of hours later the OF
> robot reported that there were two failures this week - but the bug
> remained closed).
>
> Cheers,
> kats
>
> On Fri, Jul 7, 2017 at 10:35 PM, Emma Humphries <e...@mozilla.com> wrote:
> > As discussed earlier, Joel and I have kicked off a process to close
> > intermittent test failures in Bugzilla.
> >
> > If a test associated with a bug does not fail in 21 days, we'll close the
> > bug as RESOLVED:INCOMPLETE.
> >
> > The first batch of intermittent bugs to close has 5,130 tickets. I have a
> > script to close these, but to close these without bug spam requires DBA
> > intervention.
> >
> > I'd like to run the closures over the weekend but that's going to create
> a
> > non-trivial amount of bug spam for some of you.
> >
> > There is a way to get rid of the bug spam!
> >
> > Every bug we close will have the keyword `bulk-close-intermittents` added
> > to it.
> >
> > If you search for messages from `bugzilla-dae...@mozilla.org` containing
> > `bulk-close-intermittents` you can isolate, review, and remove those
> > messages.
> >
> > Thank you for your patience while we all work to get the noise out of
> > Bugzilla so we can find the strong signals on what we must focus on to
> > deliver Firefox 57 in November.
> >
> > -- Emma
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bulk Closing Intermittents

[Emma Humphries]

Dylan,

Thank you for clarifying that difference. That was sloppy of me to describe
that as a DBA operation.

-- Emma

On Mon, Jul 10, 2017 at 7:25 AM, Dylan Hardison <dy...@mozilla.com> wrote:

>
> >
> > On Jul 7, 2017, at 19:35, Emma Humphries <e...@mozilla.com> wrote:
> >
> > The first batch of intermittent bugs to close has 5,130 tickets. I have a
> > script to close these, but to close these without bug spam requires DBA
> > intervention.
>
> This is not a correct statement. DBAs do not modify bugzilla data.
> Instead we have some functionality that directly manipulates the data
> model, which then updates the DB.
> We have batch processes that can make these changes without sending email,
> but this is far and away from
>  having a DBA intervention.
>
> I chose to point this out for two reasons -- the first being it would
> deeply concern me, if I was an outsider, to have an important
> production app subject to a process of "the DBA goes and changes some
> tables" and secondly because it would imply that responsibility
> of the contents to the database lies with operations. It should absolutely
> never be the case that we ask a DBA to change the contents of the bugzilla
> database
> without going through the application's model/business logic layer (and
> certainly not without the involvement of the bmo module owners).
>
>
> ___
> dev-tree-management mailing list
> dev-tree-managem...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tree-management
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Bulk Closing Intermittents

[Emma Humphries]

As discussed earlier, Joel and I have kicked off a process to close
intermittent test failures in Bugzilla.

If a test associated with a bug does not fail in 21 days, we'll close the
bug as RESOLVED:INCOMPLETE.

The first batch of intermittent bugs to close has 5,130 tickets. I have a
script to close these, but to close these without bug spam requires DBA
intervention.

I'd like to run the closures over the weekend but that's going to create a
non-trivial amount of bug spam for some of you.

There is a way to get rid of the bug spam!

Every bug we close will have the keyword `bulk-close-intermittents` added
to it.

If you search for messages from `bugzilla-dae...@mozilla.org` containing
`bulk-close-intermittents` you can isolate, review, and remove those
messages.

Thank you for your patience while we all work to get the noise out of
Bugzilla so we can find the strong signals on what we must focus on to
deliver Firefox 57 in November.

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

Re: QF bug whiteboard tags

[Emma Humphries]

This is Jean and Harold's work documented here:

https://docs.google.com/document/d/1Ka8eNAISQodT1mS_OXapFG-_kk94GoXyo4eKH1j7EV4/edit

-- Emma

On Wed, May 10, 2017 at 8:05 PM, Jim Mathies  wrote:

> Hey all,
>
> The quantum flow project has been filing a lot of bugs lately. I'm curious
> about two specific whiteboard tags I've seen - [qf:p1] and [qf], can
> someone explain the differences between these two tags and how this impact
> the priority of these bugs?
>
> Thanks,
> Jim
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: unowned module: Firefox::New Tab Page, help me find an owner

[Emma Humphries]

FYI, this was resolved yesterday. Peter DeHann's volunteered to triage the
component. Replies to FFx list please.

-- Emma

On Wed, Mar 22, 2017 at 6:22 AM,  wrote:

> I have not been able to find an owner for the Firefox::New Tab Page
> bugzilla component (bug 1346908).  There are 35 tests in the tree and
> without anyone to assume responsibility for them when they are intermittent
> (bug 1338848), I plan to delete them all if I cannot get an owner by the
> end of the month including someone who will sign up to be the triage owner
> for the bugzilla component.
>
> Thanks for helping me find owners for tests!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Pulsebot has been given a major game misconduct penalty

[Emma Humphries]

Also, thanks to :jld for alerting me to the situation. -- Emma

On Fri, Feb 3, 2017 at 12:52 PM, Emma Humphries <e...@mozilla.com> wrote:

> Pulsebot has been suspended when we found it was spamming 5-digit bmo bugs
> about GitHub issues.
>
> There's a ticket to clean up bmo https://bugzilla.mozilla.org/
> show_bug.cgi?id=1336563 and I'll work with that team to get it cleaned up.
>
> Please reach out to bmo-ad...@mozilla.org so we can work with everyone on
> merges of this sort in the future, because toaster shopping is not fun.
>
> -- Emma
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Pulsebot has been given a major game misconduct penalty

[Emma Humphries]

Pulsebot has been suspended when we found it was spamming 5-digit bmo bugs
about GitHub issues.

There's a ticket to clean up bmo
https://bugzilla.mozilla.org/show_bug.cgi?id=1336563 and I'll work with
that team to get it cleaned up.

Please reach out to bmo-ad...@mozilla.org so we can work with everyone on
merges of this sort in the future, because toaster shopping is not fun.

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

Re: Please don't abuse "No bug" in commit messages

[Emma Humphries]

Thanks for checking the developer guidelines and making sure they are
consistent.

I'd like to hear a little more about:

branch merges - … I personally wish that especially significant merges
*did* have bugs to make it a little easier to track problems back to a
branch landing and have a place for discussion of the reasons and risks.

There's a discussion I've been in with release mangement about what we can
be doing to improve these merges and how we are tracking them and the
regressions they may cause.

-- Emma

On Fri, Feb 3, 2017 at 11:01 AM, Steve Fink  wrote:

> On 02/03/2017 09:29 AM, Gijs Kruitbosch wrote:
>
>> On 03/02/2017 15:11, Ryan VanderMeulen wrote:
>>
>>> A friendly reminder that per the MDN commit rules, the use of "No bug"
>>> in the commit message is to be used sparingly - in general for minor things
>>> like whitespace changes/comment fixes/etc where traceability isn't as
>>> important.
>>> https://developer.mozilla.org/docs/Mozilla/Developer_guide/C
>>> ommitting_Rules_and_Responsibilities
>>>
>>> I've come across uses of "No bug" commits recently where entire upstream
>>> imports of vendored libraries were done. This is bad for multiple reasons:
>>> * If makes sheriffing difficult - if the patch is broken and needs
>>> backing out, where should the comment go? When it gets merged to
>>> mozilla-central, who gets notified?
>>>
>> As Greg said, the committer / pusher, via IRC and/or email.
>>
>>> * It makes tracking a pain - what happens if that patch ends up needing
>>> uplift?
>>>
>> Generally, the person committing it will know whether it needs uplift,
>> and would have filed a bug if it did - and would file one if it does after
>> the fact. We can already not rely on bugs being marked fixed/verified on a
>> trunk branch when searching bugzilla for uplift requests (cf. "disable
>> feature Y on beta" bugs) and so I don't see how this is relevant.
>>
>>> What about when that patch causes conflicts with another patch needing
>>> uplift?
>>>
>> That seems like it hardly ever happens in the example you gave (vendored
>> libraries and other wholesale "update this dir to match external canonical
>> version"), and if/when it does, the people who would be likely to be
>> involved in such changes (effectively changes to vendored deps that aren't
>> copied from the same canonical source!) are also likely to be aware of what
>> merged when.
>>
>>> What if it causes a regression and a blocking bug needs to be filed?
>>>
>> Then you file a bug and needinfo the person who landed the commit (which
>> one would generally do anyway, besides just marking it blocking the
>> regressor).
>>
>>
>> If there's an overwhelming majority of people who think using "no bug"
>> for landing 'sync m-c with repo X' commits is bad, we can make a more
>> explicit change in the rules here. But in terms of reducing development
>> friction, if we think bugs are necessary at this point, I would prefer
>> doing something like what Greg suggested, ie auto-file bugs for commits
>> that get pushed that don't have a bug associated with them.
>>
>>
>> More generally, I concur with Greg that we should pivot to having the
>> repos be our source of truth about what csets are present on which
>> branches. I've seen cases recently where e.g. we land a feature, then there
>> are regressions, and some of them are addressed in followup bugs, and then
>> eventually we back everything out of one of the trains because we can't fix
>> *all* the regressions in time. At that point, the original feature bug's
>> flags are updated ('disabled' on the branch with backouts), but not those
>> of the regression fix deps, and so if *those* have regressions, people
>> filing bugs make incorrect assumptions about what versions are affected.
>> Manually tracking branch fix state in bugzilla alone is a losing battle.
>>
>
> For the immediate term, I must respectfully disagree. Sheriffs are the
> people most involved with and concerned with the changeset management
> procedures, so if the sheriffs (and Ryan "I'm not a sheriff!" VM) are
> claiming that No Bug landings are being overused and causing issues, I'm
> inclined to adjust current practices first and hold off on rethinking our
> development process until the immediate pain is resolved. The fact is that
> our *current* changeset management *is* very bug-centric. I think gps and
> others have made a good argument for why another process may be superior
> (and I personally do not regard our current process as the pinnacle of
> efficiency), and I'm all for coming up with something better. But I really
> don't want some long drawn-out halfway state where the people who think the
> process should be A are doing it that way, the people who think it should
> be B are changing piecemeal to get something as close to B as is currently
> possible, and the people new to our community are completely baffled and
> getting contradictory advice depending on who they talk to.
>
> Can we clarify 

Adding CSP to bugzilla.mozilla.org

[Emma Humphries]

We're about to enable a Content Security Policy (CSP)(1) on
bugzilla.mozilla.org. CSP will mitigate several types of attack on our
users and our site, including Cross-Site Request Forgery (XSRF)(2) and
Cross-Site Scripting (XSS)(3).

The first place we're deploying this is in the bug detail page in the new
Modal view (which, you may recall, we're making the default view (4)) with
a goal for the site to have complete CSP coverage.

As a side-effect of this work, CSP may break add-ons that modify the bug
detail page. If we have broken something of yours, we can quickly fix it.
We're already enabling the Socorro Lens add-on(5). You can see how that was
addressed(6)
​​
.

Web Extensions can modify the DOM of a bug detail page through
`content.js`. You cannot load images, javascript, iframes, form actions, or
css from external sites
​, u​
nless we make an exception for you(7).

Long term, if you have a feature from an add-on you'd like to make part of
BMO, please seek me out on irc://irc.mozilla.org/bteam or open a new ticket
in the bugzilla.mozilla.org product in Bugzilla and set the severity to
'enhancement'(8).

Thank you,

Emma ()

1: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
2: https://www.owasp.org/index.php/CSRF
3: https://www.owasp.org/index.php/XSS
4: https://groups.google.com/forum/#!topic/mozilla.dev.platform/_AFaUi3JQhs
5: https://addons.mozilla.org/en-US/firefox/addon/bugzilla-socorro-lens/
6: https://github.com/ashughes1/bugzilla-socorro-lens/issues/19
7: https://wiki.mozilla.org/BMO/Add-on_Registry
8:
https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org_severity=enhancement
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Emoji and Bugzilla

[Emma Humphries]

As the BMO team announced earlier, we're going to be allowing emoji in user
inputs in Bugzilla.

https://bugzilla.mozilla.org/show_bug.cgi?id=1253535

We have not committed to a date to release this feature as it requires a
production database change which we haven't been able schedule yet.

Meanwhile, this change means that as an Bugzilla API consumer, you will
need to be ready to accept emoji in your systems.

In particular, if your client application uses MySQL, you'll need to update
your databases and tables to use utf8mb4 instead of utf8 encoding,
otherwise if you try writing strings containing emoji, they would be
truncated at the first emoji which would be a  situation. Adjust that
caveat as needed for other data stores such as Postgres.

If your application will need time to be able to support emoji, please
contact the bmo team. Otherwise we'll assume you're  with this change and
not .

Also, once we turn this feature on, some of our users will think themselves
clever and create bugs with  as the title. If the bug contains little
else than that, it's probably a  and can be closed as INVALID.

-- Emma ()
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

How To Tags Comments in Bugzilla So We Can Respond Appropriately

[Emma Humphries]

You might recall that if you have "editbugs" privileges, you can tag
comments in Bugzilla to mark abuse, off-topic discussion, and spam.

https://wiki.mozilla.org/BMO/comment_tagging

Please use the right tags when reporting comments that violate our
etiquette policies
so that site admins can take the right actions and keep Bugzilla a friendly
and spam-free place to report and track bugs.

'spam': comments that look like someone's trying to game search results by
adding links to unrelated sites to comments should be tagged as spam. Look
out for comments of the form "I see this happening on my site too," as they
may be spam and not additional information for a bug.

'off-topic', 'offtopic', 'me-too', or 'advocacy': "me too", "fix this
''now''!", "I can't believe this isn't important to Mozilla" and similar
comments should be tagged with one of these.

'abuse', 'abusive', or 'admin': Flames, threats, name-calling, and slurs
are abuse, and should be marked as such so they are brought to the
attention of an admin.

'obsolete' and 'typo' should only be use used to remove comments which are
no longer relevant, contain outdated or incorrect information, or ones the
author wishes to redact.

If you don't have "editbugs" privileges, ask for help on #
b...@irc.mozilla.org or email bugzilla-ad...@mozilla.org with the bug number
and a short description of the situation.

Our response to violations of Bugzilla etiquette depends on the type of
violation. We don't want to mark an eager new contributor, who just needs
some coaching, as a spammer, and we don't want to go uninformed about abuse.

Thanks!

-- Emma ‍♀️
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

On Fri, Oct 7, 2016 at 2:29 AM,  wrote:

> Hi I'm someone who is studying the triage process and workflow among OSS,
> Can anyone tell me does the new triage plan discussed here get adopted and
> what is the final version? I would also love to know where and could I
> follow your discussions on policies? I can't find other topics related to
> this thread in google groups.



​Hi John,

Thanks for your patience while I got back to you.

The triage plan we're using is
https://wiki.mozilla.org/Bugmasters/Process/Triage.

The Platform team is also using ​
https://wiki.mozilla.org/Platform#Bug_Triage to focus on regressions.

Several teams that develop on GitHub are using the P1-P3, P5 scheme in
their repos and using waffle.io to aggregate across projects.

Scoreboards are:

https://emceeaich.github.io/triage-report/ and
https://sql.telemetry.mozilla.org/dashboard/firefox-triage

My current reporting doesn't account for projects that exclusively track
bugs in GitHub issues.

There's a mailing-list, firefox-triage-le...@mozilla.org, but it's a low
volume list.

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

Re: Reorganization of Firefox-UI tests in mozilla-central

[Emma Humphries]

Henrik,

It's not clear to me if this is just moving the location of existing tests,
or if you're bringing in new tests.

If it's the later, I'm concerned that we're going to get more intermittents
filed in Bugzilla, which adds noise to the triage process.

If you are adding more tests, then would it be possible to back off from
filing intermittent bugs unless they become problematic, failing tests more
than a quarter to half the time?

Thanks!

Emma

On Thu, Sep 1, 2016 at 8:37 AM, Henrik Skupin  wrote:

> Hello,
>
> Via bug 1272145 we want to move our existing Firefox-UI tests from
> /testing/firefox-ui/ closer to the code which these are testing, so that
> the former location only contains the test harness and appropriate unit
> tests.
>
> Link to the current set of tests:
> https://dxr.mozilla.org/mozilla-central/source/testing/firefox-ui/tests
>
> For those of you who haven't heard about these tests yet, they are
> basically Marionette tests with an additional layer (firefox-puppeteer)
> on top to ease the test creation for ui specific checks. Benefits we
> have are restarting and quitting the browser, and running the tests in
> any localized build of Firefox.
>
> As listed below you can find the current type of tests and a proposed
> location:
>
> * locationbar tests:/browser/base/content/test/
> urlbar/firefox_ui/
> * private browsing tests:
> /browser/components/privatebrowsing/test/firefox_ui/
> * safe browsing tests:
> /browser/components/safebrowsing/content/test/firefox_ui/
> * session store tests:  /browser/components/
> sessionstore/test/firefox_ui/
> * update tests: /toolkit/mozapps/update/tests/firefox_ui/
>
> Do those locations sound good? I have heard at least once that
> "firefox_ui" might not be the best choice as folder name, but that's how
> the harness is called, and corresponds to what we have for other
> harnesses too.
>
> Locations for the following tests are not clear yet:
>
> * l10n tests (shortcuts):   not clear yet (maybe under
> /browser/base/content/test/)
> * security tests:   not clear yet
>
> L10n related tests mostly cover shortcuts and that the correct command
> is invoked to find failures like bug 1173735.
>
> Nearly all of the security tests are running checks against a real
> server with various SSL certificates (DV, OV, EV) and protocol versions.
> We will have a meeting soon to determine which of those tests are needed
> and which ones can be removed. So we might also be able to find the
> correct location for the tests.
>
> For now I would like to know if the proposal is fine or if we should go
> a completely different route.
>
> Thanks
>
> --
> Henrik
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visualizing Crash Data in Bugzilla

[Emma Humphries]

I love this, and it's encouraging me to try an experiment with web
extensions to help with triaging bugs.

-- Emma

On Tue, Aug 16, 2016 at 3:29 PM, Bob Clary  wrote:

> This is *way* cool! The historical feedback for the signatures is very
> compelling. I recommend everyone try it out and that we all make sure to
> populate the crash signature.
>
> /bc
>
> On 08/16/2016 02:47 PM, Anthony Hughes wrote:
>
>> Hi Platform team,
>>
>> In case you don't follow planet.mozilla.org I wanted to highlight that
>> I'm
>> releasing the initial version of my experimental Bugzilla Tweaks add-on,
>> dubbed Bugzilla Socorro Lens v0.3.
>>
>> https://ashughes.com/?p=360
>>
>> In a nutshell, this inserts a graph of aggregate crash data for signatures
>> listed in the Crash Signature field of a bug report. The visualization is
>> powered by MetricsGraphics.js and the data is coming from the Socorro
>> supersearch API.
>>
>> Feedback welcome!
>>
>> Cheers
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Triage for Component Leads

[Emma Humphries]

This afternoon I introduced the new triage process we've developed for bugs
in Firefox-related components.

My presentation is at
https://docs.google.com/presentation/d/1qlXlDsMnvcpA5ppJVJWIBaBDPEyw5hbjU-Q7wjjrZQM/edit?usp=sharing

The guide to the process is on the Mozilla wiki:
https://wiki.mozilla.org/Bugmasters/Process/Triage

If you are on this list,
https://wiki.mozilla.org/Bugmasters/Project/Bug_Handling/Triage_Leads, you
are on the hook to make decisions on bugs in the component. And I'll be
following up with you over the next two weeks to see how you are doing, and
what questions you have about this process.

After I return from London, I'll also put together a short video for Air
Mozilla introducing the process.

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

Re: The Whiteboard Tag Amnesty

[Emma Humphries]

The whiteboard field a text blob with no rules, only conventions on
separators (which are not used consistently.) If you misspell a tag,
there's no prompt to correct (unless the browser or os spell checker
recognizes it) and you can get inconsistencies that way.

As for "real tagging system" look, for instance, at Wordpress' tagging
system or Live Journal's before that.

-- Emma

On Wed, Jun 8, 2016 at 4:03 PM, Jason Duell <jdu...@mozilla.com> wrote:

> Emma,
>
> > it's not a indexed field or a real tag system, making it hard to parse,
> search, and update.
>
> Could we dig into details a little more here?  I assume we could add a
> database index for the whiteboard field if performance is an issue.
> Do we give keywords an enum value or something (so bugzilla can
> index/search them faster)?  I'm not clear on what a "real tag system" means
> concretely here.
>
> thanks!
>
> Jason
>
> On Wed, Jun 8, 2016 at 3:29 PM, Emma Humphries <e...@mozilla.com> wrote:
>
>> There is a ticket for a "proper" tag system,
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1266609 which given time,
>> I'd
>> like to get implemented, but with limited resources, this is what I can do
>> now.
>>
>> On Wed, Jun 8, 2016 at 2:08 PM, Patrick McManus <pmcma...@mozilla.com>
>> wrote:
>>
>> > as you note the whiteboard tags are permissionless. That's their killer
>> > property. Keywords as you note are not, that's their critical weakness.
>> >
>> > instead of fixing that situation in the "long term" can we please fix
>> that
>> > as a precondition of converting things? Mozilla doesn't need more
>> > centralized systems. If they can't be 100% automated to be
>> permissionless
>> > (e.g. perhaps because they don't scale) then the new arrangement of
>> things
>> > is definitely worse.
>> >
>> > I'll note that even for triage, our eventual system evolved rapidly and
>> > putting an administrator in the middle to add and drop keywords and
>> > indicies would have just slowed stuff down. Permissionless to me is a
>> > requirement.
>> >
>> >
>> > On Wed, Jun 8, 2016 at 2:43 PM, Kartikaya Gupta <kgu...@mozilla.com>
>> > wrote:
>> >
>> >> What happens after June 24? Is the whiteboard field going to be
>> removed?
>> >>
>> >> On Wed, Jun 8, 2016 at 4:32 PM, Emma Humphries <e...@mozilla.com>
>> wrote:
>> >> > tl;dr -- nominate whiteboard tags you want converted to keywords. Do
>> it
>> >> by
>> >> > 24 June 2016.
>> >> >
>> >> > We have a love-hate relationship with the whiteboard field in
>> bugzilla.
>> >> On
>> >> > one hand, we can add team-specific meta data to a bug. On the other
>> >> hand,
>> >> > it's not a indexed field or a real tag system, making it hard to
>> parse,
>> >> > search, and update.
>> >> >
>> >> > But creating keywords is a hassle since you have to request them.
>> >> >
>> >> > The long term solution is to turn whiteboard into proper tag system,
>> but
>> >> > the Bugzilla Team's offering to help with some bulk conversion of
>> >> > whiteboard tags your teams use into keywords.
>> >> >
>> >> > To participate:
>> >> >
>> >> > 1. Create a Bug in the bugzilla.mozilla.org::Administration
>> component
>> >> for each
>> >> > whiteboard tag you want to convert.
>> >> >
>> >> > 2. The bug's description should have the old keyword, the new keyword
>> >> you
>> >> > want to replace it with, and the description of this new keyword
>> which
>> >> will
>> >> > appear in the online help.
>> >> >
>> >> > 3. Make sure your keyword doesn't conflict with existing keywords,
>> so be
>> >> > prepared to rename it. If your keyword is semantically similar to an
>> >> > existing keyword or other existing bugzilla field we'll talk you
>> about a
>> >> > mass change to your bugs.
>> >> >
>> >> > 4. Make the parent bug,
>> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1279022,
>> >> > depend on your new bug.
>> >> >
>> >> > 5. CC Emma Humphries on the bug
>> >> >
>> >> > We will turn your whiteboard tag into a keyword and remove your old
>> tag
>> >> > from the whiteboard tags, so make sure your dashboards and other
>> tools
>> >> that
>> >> > consume Bugzilla's API are updated to account for this.
>> >> >
>> >> > Please submit your whiteboard fields to convert by Friday 24 June
>> 2016.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Emma Humphries
>> >> > ___
>> >> > dev-platform mailing list
>> >> > dev-platform@lists.mozilla.org
>> >> > https://lists.mozilla.org/listinfo/dev-platform
>> >> ___
>> >> firefox-dev mailing list
>> >> firefox-...@mozilla.org
>> >> https://mail.mozilla.org/listinfo/firefox-dev
>> >>
>> >
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>
> Jason
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The Whiteboard Tag Amnesty

[Emma Humphries]

There is a ticket for a "proper" tag system,
https://bugzilla.mozilla.org/show_bug.cgi?id=1266609 which given time, I'd
like to get implemented, but with limited resources, this is what I can do
now.

On Wed, Jun 8, 2016 at 2:08 PM, Patrick McManus <pmcma...@mozilla.com>
wrote:

> as you note the whiteboard tags are permissionless. That's their killer
> property. Keywords as you note are not, that's their critical weakness.
>
> instead of fixing that situation in the "long term" can we please fix that
> as a precondition of converting things? Mozilla doesn't need more
> centralized systems. If they can't be 100% automated to be permissionless
> (e.g. perhaps because they don't scale) then the new arrangement of things
> is definitely worse.
>
> I'll note that even for triage, our eventual system evolved rapidly and
> putting an administrator in the middle to add and drop keywords and
> indicies would have just slowed stuff down. Permissionless to me is a
> requirement.
>
>
> On Wed, Jun 8, 2016 at 2:43 PM, Kartikaya Gupta <kgu...@mozilla.com>
> wrote:
>
>> What happens after June 24? Is the whiteboard field going to be removed?
>>
>> On Wed, Jun 8, 2016 at 4:32 PM, Emma Humphries <e...@mozilla.com> wrote:
>> > tl;dr -- nominate whiteboard tags you want converted to keywords. Do it
>> by
>> > 24 June 2016.
>> >
>> > We have a love-hate relationship with the whiteboard field in bugzilla.
>> On
>> > one hand, we can add team-specific meta data to a bug. On the other
>> hand,
>> > it's not a indexed field or a real tag system, making it hard to parse,
>> > search, and update.
>> >
>> > But creating keywords is a hassle since you have to request them.
>> >
>> > The long term solution is to turn whiteboard into proper tag system, but
>> > the Bugzilla Team's offering to help with some bulk conversion of
>> > whiteboard tags your teams use into keywords.
>> >
>> > To participate:
>> >
>> > 1. Create a Bug in the bugzilla.mozilla.org::Administration component
>> for each
>> > whiteboard tag you want to convert.
>> >
>> > 2. The bug's description should have the old keyword, the new keyword
>> you
>> > want to replace it with, and the description of this new keyword which
>> will
>> > appear in the online help.
>> >
>> > 3. Make sure your keyword doesn't conflict with existing keywords, so be
>> > prepared to rename it. If your keyword is semantically similar to an
>> > existing keyword or other existing bugzilla field we'll talk you about a
>> > mass change to your bugs.
>> >
>> > 4. Make the parent bug,
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1279022,
>> > depend on your new bug.
>> >
>> > 5. CC Emma Humphries on the bug
>> >
>> > We will turn your whiteboard tag into a keyword and remove your old tag
>> > from the whiteboard tags, so make sure your dashboards and other tools
>> that
>> > consume Bugzilla's API are updated to account for this.
>> >
>> > Please submit your whiteboard fields to convert by Friday 24 June 2016.
>> >
>> > Cheers,
>> >
>> > Emma Humphries
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The Whiteboard Tag Amnesty

[Emma Humphries]

Yes, 'amnesty' is probably too strong a term, and 'cleanup' is probably
better.

-- Emma

On Wed, Jun 8, 2016 at 2:19 PM, Patrick McManus <pmcma...@mozilla.com>
wrote:

> that's useful thanks. I think the word amnesty implied the death penalty
> for existing whiteboard tags.
>
> what it sounds like is you're just offering (for a limited time) to do
> conversions on an opt-in basis? That's great.
>
> -P
>
>
> On Wed, Jun 8, 2016 at 3:11 PM, Emma Humphries <e...@mozilla.com> wrote:
>
>>
>>
>> > On Jun 8, 2016, at 1:43 PM, Kartikaya Gupta <kgu...@mozilla.com> wrote:
>> >
>> > What happens after June 24? Is the whiteboard field going to be removed?
>> >
>>
>> No, the whiteboard field remains, but any tags migrated will be deleted
>> from existing values.
>>
>> If a tag is used across teams, I'll work out a resolution such as both
>> teams using the new keyword, or specific keywords as long as they don't
>> semantically copy other existing fields.
>>
>>
>> >> On Wed, Jun 8, 2016 at 4:32 PM, Emma Humphries <e...@mozilla.com>
>> wrote:
>> >> tl;dr -- nominate whiteboard tags you want converted to keywords. Do
>> it by
>> >> 24 June 2016.
>> >>
>> >> We have a love-hate relationship with the whiteboard field in
>> bugzilla. On
>> >> one hand, we can add team-specific meta data to a bug. On the other
>> hand,
>> >> it's not a indexed field or a real tag system, making it hard to parse,
>> >> search, and update.
>> >>
>> >> But creating keywords is a hassle since you have to request them.
>> >>
>> >> The long term solution is to turn whiteboard into proper tag system,
>> but
>> >> the Bugzilla Team's offering to help with some bulk conversion of
>> >> whiteboard tags your teams use into keywords.
>> >>
>> >> To participate:
>> >>
>> >> 1. Create a Bug in the bugzilla.mozilla.org::Administration component
>> for each
>> >> whiteboard tag you want to convert.
>> >>
>> >> 2. The bug's description should have the old keyword, the new keyword
>> you
>> >> want to replace it with, and the description of this new keyword which
>> will
>> >> appear in the online help.
>> >>
>> >> 3. Make sure your keyword doesn't conflict with existing keywords, so
>> be
>> >> prepared to rename it. If your keyword is semantically similar to an
>> >> existing keyword or other existing bugzilla field we'll talk you about
>> a
>> >> mass change to your bugs.
>> >>
>> >> 4. Make the parent bug,
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1279022,
>> >> depend on your new bug.
>> >>
>> >> 5. CC Emma Humphries on the bug
>> >>
>> >> We will turn your whiteboard tag into a keyword and remove your old tag
>> >> from the whiteboard tags, so make sure your dashboards and other tools
>> that
>> >> consume Bugzilla's API are updated to account for this.
>> >>
>> >> Please submit your whiteboard fields to convert by Friday 24 June 2016.
>> >>
>> >> Cheers,
>> >>
>> >> Emma Humphries
>> >> ___
>> >> dev-platform mailing list
>> >> dev-platform@lists.mozilla.org
>> >> https://lists.mozilla.org/listinfo/dev-platform
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The Whiteboard Tag Amnesty

[Emma Humphries]

> On Jun 8, 2016, at 1:43 PM, Kartikaya Gupta <kgu...@mozilla.com> wrote:
> 
> What happens after June 24? Is the whiteboard field going to be removed?
> 

No, the whiteboard field remains, but any tags migrated will be deleted from 
existing values. 

If a tag is used across teams, I'll work out a resolution such as both teams 
using the new keyword, or specific keywords as long as they don't semantically 
copy other existing fields. 


>> On Wed, Jun 8, 2016 at 4:32 PM, Emma Humphries <e...@mozilla.com> wrote:
>> tl;dr -- nominate whiteboard tags you want converted to keywords. Do it by
>> 24 June 2016.
>> 
>> We have a love-hate relationship with the whiteboard field in bugzilla. On
>> one hand, we can add team-specific meta data to a bug. On the other hand,
>> it's not a indexed field or a real tag system, making it hard to parse,
>> search, and update.
>> 
>> But creating keywords is a hassle since you have to request them.
>> 
>> The long term solution is to turn whiteboard into proper tag system, but
>> the Bugzilla Team's offering to help with some bulk conversion of
>> whiteboard tags your teams use into keywords.
>> 
>> To participate:
>> 
>> 1. Create a Bug in the bugzilla.mozilla.org::Administration component for 
>> each
>> whiteboard tag you want to convert.
>> 
>> 2. The bug's description should have the old keyword, the new keyword you
>> want to replace it with, and the description of this new keyword which will
>> appear in the online help.
>> 
>> 3. Make sure your keyword doesn't conflict with existing keywords, so be
>> prepared to rename it. If your keyword is semantically similar to an
>> existing keyword or other existing bugzilla field we'll talk you about a
>> mass change to your bugs.
>> 
>> 4. Make the parent bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1279022,
>> depend on your new bug.
>> 
>> 5. CC Emma Humphries on the bug
>> 
>> We will turn your whiteboard tag into a keyword and remove your old tag
>> from the whiteboard tags, so make sure your dashboards and other tools that
>> consume Bugzilla's API are updated to account for this.
>> 
>> Please submit your whiteboard fields to convert by Friday 24 June 2016.
>> 
>> Cheers,
>> 
>> Emma Humphries
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

The Whiteboard Tag Amnesty

[Emma Humphries]

tl;dr -- nominate whiteboard tags you want converted to keywords. Do it by
24 June 2016.

We have a love-hate relationship with the whiteboard field in bugzilla. On
one hand, we can add team-specific meta data to a bug. On the other hand,
it's not a indexed field or a real tag system, making it hard to parse,
search, and update.

But creating keywords is a hassle since you have to request them.

The long term solution is to turn whiteboard into proper tag system, but
the Bugzilla Team's offering to help with some bulk conversion of
whiteboard tags your teams use into keywords.

To participate:

1. Create a Bug in the bugzilla.mozilla.org::Administration component for each
whiteboard tag you want to convert.

2. The bug's description should have the old keyword, the new keyword you
want to replace it with, and the description of this new keyword which will
appear in the online help.

3. Make sure your keyword doesn't conflict with existing keywords, so be
prepared to rename it. If your keyword is semantically similar to an
existing keyword or other existing bugzilla field we'll talk you about a
mass change to your bugs.

4. Make the parent bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1279022,
depend on your new bug.

5. CC Emma Humphries on the bug

We will turn your whiteboard tag into a keyword and remove your old tag
from the whiteboard tags, so make sure your dashboards and other tools that
consume Bugzilla's API are updated to account for this.

Please submit your whiteboard fields to convert by Friday 24 June 2016.

Cheers,

Emma Humphries
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: Error Console

[Emma Humphries]

That works for me. If you'd make the ticket to remove the component from
bmo dependent on the ticket to remove the code from moz-central and cc me
on the latter as we discussed, that'd be awesome. Thanks.

On Mon, Jun 6, 2016 at 1:48 PM, Brian Grinstead <bgrinst...@mozilla.com>
wrote:

>
> > On Jun 6, 2016, at 1:20 PM, Emma Humphries <e...@mozilla.com> wrote:
> >
> > There's 77 open bugs in the component, http://mzl.la/1YbBKto, how would
> you like to handle those?
>
> The majority of these look like frontend-related bugs and feature requests
> which could be closed once the code is removed.  I suggest a mass-closure
> with a comment to re-categorize it into Developer Tools: Console if they
> are also applicable to the Browser Console.
>
> > -- Emma
> >
> > On Mon, Jun 6, 2016 at 1:04 PM, Brian Grinstead <bgrinst...@mozilla.com>
> wrote:
> > There is an Error Console feature in toolkit that's been replaced by the
> Browser Console.  We'd like to remove associated code in
> toolkit/components/console/ and the component in bugzilla (Toolkit: Error
> Console).  This will also remove the —jsconsole command line flag for
> consumers that don’t use devtools.
> >
> > The code isn't used at all in Firefox, as discussed in
> https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/XYPqQ58ndX4/discussion.
> It’s also now possible to migrate usages to the Browser Console i.e.
> Seamonkey is no longer using it as of bug 1223341.
> >
> > Brian
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: Error Console

[Emma Humphries]

There's 77 open bugs in the component, http://mzl.la/1YbBKto, how would you
like to handle those?

-- Emma

On Mon, Jun 6, 2016 at 1:04 PM, Brian Grinstead 
wrote:

> There is an Error Console feature in toolkit that's been replaced by the
> Browser Console.  We'd like to remove associated code in
> toolkit/components/console/ and the component in bugzilla (Toolkit: Error
> Console).  This will also remove the —jsconsole command line flag for
> consumers that don’t use devtools.
>
> The code isn't used at all in Firefox, as discussed in
> https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/XYPqQ58ndX4/discussion.
> It’s also now possible to migrate usages to the Browser Console i.e.
> Seamonkey is no longer using it as of bug 1223341.
>
> Brian
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Readable Bug Statuses in Bugzilla

[Emma Humphries]

I also recommend reading through the tests in the GitHub repo because that
documents the behavior of the module.

The demo code will also grab a stack of recent bugs and generate statuses
for them.

-- Emma

On Tue, May 24, 2016 at 9:47 AM, Gijs Kruitbosch <gijskruitbo...@gmail.com>
wrote:

> On 24/05/2016 16:54, Ted Mielczarek wrote:
>
>> On Tue, May 24, 2016, at 11:45 AM, Emma Humphries wrote:
>>
>>> Last week the bugzilla.mozilla.org team had a work week in the San
>>> Francisco office. They were finishing the work on the modal edit view in
>>> Bugzilla, and joined them to land another new feature: Readable Statuses.
>>>
>>> Bugs in bugzilla.mozilla.org have a lot of metadata, and it's often not
>>> immediately obvious what the state of a bug is. To help with that, I've
>>> written an *opinionated* package for npm that looks at the bug's metadata
>>> and returns a readable status message.
>>>
>>
>> Hi Emma,
>>
>> This sounds interesting! I looked at the npm page and the github repo,
>> but I didn't see any example output. I'm interested to know what the
>> readable statuses look like. Do you have a pointer to examples?
>>
>> Thanks,
>> -Ted
>>
>
> You can see this in bmo if you have the new/modal/experimental UI enabled
> (
> https://bugzillatips.wordpress.com/2015/08/07/new-modal-ui-for-show_bug-on-bmo/
> ) . Here's an example:
>
> "Status (ASSIGNED regression bug found in Firefox 47 with no priority
> awaiting an answer on a request for information)"
>
> ~ Gijs
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Readable Bug Statuses in Bugzilla

[Emma Humphries]

Also, if you see something, file something.

Please report bugs and feature requests in the bugzilla.mozilla.com::User
Interface:Modal component.

I'll create tracking issues in the GitHub repo. If you have a pull request,
I'll open a bugzilla ticket to pick up changes in bmo.

On Tue, May 24, 2016 at 8:45 AM, Emma Humphries <e...@mozilla.com> wrote:

> Last week the bugzilla.mozilla.org team had a work week in the San
> Francisco office. They were finishing the work on the modal edit view in
> Bugzilla, and joined them to land another new feature: Readable Statuses.
>
> Bugs in bugzilla.mozilla.org have a lot of metadata, and it's often not
> immediately obvious what the state of a bug is. To help with that, I've
> written an *opinionated* package for npm that looks at the bug's metadata
> and returns a readable status message.
>
> This message is displayed in the modal version of the bug view (which
> becomes the new default view.)
>
> We incorporated this module, using some magic from browserify, into
> Bugzilla, and *enabled it for bugs in Firefox-related products*. It went
> out this morning. We've done the work in JS so that we can iterate fast.
>
> I've published the module on npmjs.org [1] and encourage you to install
> and try it out from the command line, or browserify it and drop it in a web
> page such as any dashboards you currently use. I use the node version of
> fetch with it in my test and demo app, but you can also try Canukstani's
> node module for the bugzilla API.
>
> It's opinionated in the metadata it considers important to a bug's status:
> the regression keyword, target release, status flags, and release flags.
>
> The module also has a strong opinion about the meaning of the priority
> field, and uses it to describe the decision of what to do with bugs that
> haven't been nominated by the release team.
>
> There's a GitHub repo for the module [2] for pull requests, and of course,
> a bugzilla bug [3].
>
> The package come with extensive mocha/chai tests, and I encourage you to
> read those to understand what the module's doing.
>
> If you have questions, please ask in #bteam or #bugmasters on irc.
>
> 1. https://www.npmjs.com/package/bugzilla-readable-status
> 2. https://github.com/emceeaich/bugzilla-readable-status
> 3. https://bugzilla.mozilla.org/show_bug.cgi?id=1271685
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Readable Bug Statuses in Bugzilla

[Emma Humphries]

Yes, the plan is that the 'Modal' view will become the default, and the bmo
team is working on that.

Meanwhile, you can beat the rush and switch over to the view in preferences.

-- Emma

On Tue, May 24, 2016 at 9:55 AM, J. Ryan Stinnett  wrote:

> On Tue, May 24, 2016 at 11:47 AM, Gijs Kruitbosch
>  wrote:
> > You can see this in bmo if you have the new/modal/experimental UI
> enabled (
> >
> https://bugzillatips.wordpress.com/2015/08/07/new-modal-ui-for-show_bug-on-bmo/
> > ) .
>
> Kind of a side note, but do we intend to make the "experimental" UI
> the site default? If we're adding features that only appear there, we
> may want to do that so they make the most impact.
>
> - Ryan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Readable Bug Statuses in Bugzilla

[Emma Humphries]

Last week the bugzilla.mozilla.org team had a work week in the San
Francisco office. They were finishing the work on the modal edit view in
Bugzilla, and joined them to land another new feature: Readable Statuses.

Bugs in bugzilla.mozilla.org have a lot of metadata, and it's often not
immediately obvious what the state of a bug is. To help with that, I've
written an *opinionated* package for npm that looks at the bug's metadata
and returns a readable status message.

This message is displayed in the modal version of the bug view (which
becomes the new default view.)

We incorporated this module, using some magic from browserify, into
Bugzilla, and *enabled it for bugs in Firefox-related products*. It went
out this morning. We've done the work in JS so that we can iterate fast.

I've published the module on npmjs.org [1] and encourage you to install and
try it out from the command line, or browserify it and drop it in a web
page such as any dashboards you currently use. I use the node version of
fetch with it in my test and demo app, but you can also try Canukstani's
node module for the bugzilla API.

It's opinionated in the metadata it considers important to a bug's status:
the regression keyword, target release, status flags, and release flags.

The module also has a strong opinion about the meaning of the priority
field, and uses it to describe the decision of what to do with bugs that
haven't been nominated by the release team.

There's a GitHub repo for the module [2] for pull requests, and of course,
a bugzilla bug [3].

The package come with extensive mocha/chai tests, and I encourage you to
read those to understand what the module's doing.

If you have questions, please ask in #bteam or #bugmasters on irc.

1. https://www.npmjs.com/package/bugzilla-readable-status
2. https://github.com/emceeaich/bugzilla-readable-status
3. https://bugzilla.mozilla.org/show_bug.cgi?id=1271685
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: HTML microdata API

[Emma Humphries]

> On May 19, 2016, at 10:55 AM, Boris Zbarsky  wrote:
> 
> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909633
> 
> Target release: 49
> 
> I believe I've removed all our in-browser dependencies on this stuff.  I 
> haven't really checked addons because unfortunately the property names 
> this thing uses (e.g. "properties", "itemId") are way too common.  :(

Should I remove the component from Bugzilla and mark remaining bugs incomplete?

-- Emma


> 
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> Summary: The HTML Microdata API was removed from the spec due to lack of 
> implementor interest.  See 
> .  Our 
> implementation of it breaks some pages (due to the itemId attributes it 
> adds) and is a bunch of code.  I would like to remove it.
> 
> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909633
> 
> Target release: 49
> 
> I believe I've removed all our in-browser dependencies on this stuff.  I 
> haven't really checked addons because unfortunately the property names 
> this thing uses (e.g. "properties", "itemId") are way too common.  :(
> 
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a OSS project!

[Emma Humphries]

I want to point out that the bug in question had 48 Mozillians CC'ed on it,
so any comments on the bug which are extraneous to the subject of the bug
add noise to the signal.

Comments are a place to make a case for a fix, but not indulging in a
jeremiad if a decision is made not to fix.

-- Emma

On Mon, May 9, 2016 at 1:59 PM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:

> K, I wait till Mozilla hit the bottom because marking my opinions to
> problems as "Offtopic" and removing my rights because I get p*ssed that my
> thinking about it is "off topic" is getting to much for me!
>
> But I'm pretty sure that it wouldn't take anymore long till Mozilla is on
> the ground...
>
> Seems Mozilla still don't get it, that Windows have a market share from
> around 90%...
>
> https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10=0
>
> ...while OS X have <10%...
> http://gs.statcounter.com/#desktop-os-ww-monthly-201504-201604
>
> And Firefox have now - depending on the sources you watch - <9% market
> share...
> ...while Google Chrome (with some parts be the same as FF and have started
> much later) is now on ~57%...
> https://www.w3counter.com/globalstats.php
> http://gs.statcounter.com/
> http://www.w3schools.com/browsers/browsers_stats.asp
>
> ...the bottom seems no more far, because - even if geeks try to help - FF
> lose ~2% market share per year...
> http://www.sitepoint.com/browser-trends-august-2015-chrome-exceeds-50/
>
> ...and have lost - even with the help of geeks - in the last 2,5 years
> ~8%...
>
> https://www.netmarketshare.com/browser-market-share.aspx?qprid=1=0=2014=3=Y
>
> ...even if FF supports much more features/standard as every browser else...
> https://en.wikipedia.org/wiki/Comparison_of_web_browsers
> http://www.webdevout.net/browser-support
> https://html5test.com/
>
> Maybe some people will get some enlightenment, if they read this:
>
> http://thenextweb.com/entrepreneur/2015/06/24/9-questions-ask-softwares-beta-testers/
> Especially point 9. ...
>
>
> Greets, Tobias.
>
> P.S.: And happy programming for yourself!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Emma Humphries]

Andrew, can you do a pass over the bugs since Jan 1st and, and let's rename
this FFx::Add Ons Compatablity so that it's clear it's not plugins.

On Mon, May 2, 2016 at 2:56 PM, Andrew McKay <amc...@mozilla.com> wrote:

> Looks like that would fall on me. After a quick look at some of the
> bugs, its seems like its a holding pen for bugs that need to be passed
> on to other areas or back to the add-on developer themselves (which
> often means closing them).
>
> On Mon, May 2, 2016 at 2:01 PM, Emma Humphries <e...@mozilla.com> wrote:
> > Pasting what I mentioned in #fx-team
> >
> >
> > Regarding FFx::Extension Compatibility componen
> > t.
> > 702 bugs total, 282 of which are not marked against a particular version
> > . There are
> > 11 in FFx 44, 10 in FFx 45, 9 in FFx 46, 7 in FFx 47, 3 in FFx 48
> > ,
> > 1 tracking FFx 47
> > ,
> > and only 44 bugs since the first of the year
> >
> > I'd like to get those into the right component, and make a decision
> > on disposing
> > of
> > the rest?
> >
> > --
> > Emma
> >
> >
> >
> > On Mon, May 2, 2016 at 1:37 PM, Emma Humphries <e...@mozilla.com> wrote:
> >>
> >> Let me take a look at those.
> >>
> >> On Mon, May 2, 2016 at 1:01 PM, Justin Dolske <dol...@mozilla.com>
> wrote:
> >>>
> >>> Will Firefox :: Extension Compatibility also be rolled into this new ::
> >>> Other component?
> >>>
> >>> (There are ~700 open bugs there still, most of which look pretty
> stale.)
> >>>
> >>> Justin
> >>>
> >>> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg
> >>> <benja...@smedbergs.us> wrote:
> >>>>
> >>>> There used to be a bugzilla.mozilla.org product called "Plugins".
> This
> >>>> product has been renamed "External Software Affecting Firefox" and its
> >>>> component structure has been greatly simplified.
> >>>>
> >>>> It is usually not helpful to track defects in 3rd-party software in
> the
> >>>> Mozilla bug tracker. The only time we want to track those defects is
> when we
> >>>> want to make explicit outreach efforts because those defects affect
> Firefox
> >>>> users.
> >>>>
> >>>> There were previously almost a hundred different "components" for fine
> >>>> classification of these bugs. This was not producing good results and
> caused
> >>>> confusion for many people filing bugs. So I've asked for most of these
> >>>> components to be retired, and now there will be just three components:
> >>>>
> >>>> "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
> >>>> working with Adobe when necessary.
> >>>> "OpenH264" - I believe Maire Reavy's team triages this component for
> >>>> bugs that affect our deployment of OpenH264 with Cisco.
> >>>> "Other" - For defects in basically all other 3rd-party software,
> >>>> including other NPAPI and GMP plugins, Firefox extensions, and other
> >>>> software such as antivirus tools, that may affect Firefox. I am
> triaging
> >>>> these bugs as necessary.
> >>>>
> >>>> --BDS
> >>>>
> >>>> ___
> >>>> firefox-dev mailing list
> >>>> firefox-...@mozilla.org
> >>>> https://mail.mozilla.org/listinfo/firefox-dev
> >>>>
> >>>
> >>>
> >>> ___
> >>> firefox-dev mailing list
> >>> firefox-...@mozilla.org
> >>> https://mail.mozilla.org/listinfo/firefox-dev
> >>>
> >>
> >
> >
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Emma Humphries]

MattN mentioned there's also a "Tech Evangelism :: Addons" which is for
bugs from add-ons where we aren't going to change anything in the product
but we may contact the author or blog about the addon-compatablty change. I
need to see how busy that one is (I would imagine that it it's being used
for e10s related changes?)

-- Emma

On Mon, May 2, 2016 at 2:56 PM, Andrew McKay <amc...@mozilla.com> wrote:

> Looks like that would fall on me. After a quick look at some of the
> bugs, its seems like its a holding pen for bugs that need to be passed
> on to other areas or back to the add-on developer themselves (which
> often means closing them).
>
> On Mon, May 2, 2016 at 2:01 PM, Emma Humphries <e...@mozilla.com> wrote:
> > Pasting what I mentioned in #fx-team
> >
> >
> > Regarding FFx::Extension Compatibility componen
> > t.
> > 702 bugs total, 282 of which are not marked against a particular version
> > . There are
> > 11 in FFx 44, 10 in FFx 45, 9 in FFx 46, 7 in FFx 47, 3 in FFx 48
> > ,
> > 1 tracking FFx 47
> > ,
> > and only 44 bugs since the first of the year
> >
> > I'd like to get those into the right component, and make a decision
> > on disposing
> > of
> > the rest?
> >
> > --
> > Emma
> >
> >
> >
> > On Mon, May 2, 2016 at 1:37 PM, Emma Humphries <e...@mozilla.com> wrote:
> >>
> >> Let me take a look at those.
> >>
> >> On Mon, May 2, 2016 at 1:01 PM, Justin Dolske <dol...@mozilla.com>
> wrote:
> >>>
> >>> Will Firefox :: Extension Compatibility also be rolled into this new ::
> >>> Other component?
> >>>
> >>> (There are ~700 open bugs there still, most of which look pretty
> stale.)
> >>>
> >>> Justin
> >>>
> >>> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg
> >>> <benja...@smedbergs.us> wrote:
> >>>>
> >>>> There used to be a bugzilla.mozilla.org product called "Plugins".
> This
> >>>> product has been renamed "External Software Affecting Firefox" and its
> >>>> component structure has been greatly simplified.
> >>>>
> >>>> It is usually not helpful to track defects in 3rd-party software in
> the
> >>>> Mozilla bug tracker. The only time we want to track those defects is
> when we
> >>>> want to make explicit outreach efforts because those defects affect
> Firefox
> >>>> users.
> >>>>
> >>>> There were previously almost a hundred different "components" for fine
> >>>> classification of these bugs. This was not producing good results and
> caused
> >>>> confusion for many people filing bugs. So I've asked for most of these
> >>>> components to be retired, and now there will be just three components:
> >>>>
> >>>> "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
> >>>> working with Adobe when necessary.
> >>>> "OpenH264" - I believe Maire Reavy's team triages this component for
> >>>> bugs that affect our deployment of OpenH264 with Cisco.
> >>>> "Other" - For defects in basically all other 3rd-party software,
> >>>> including other NPAPI and GMP plugins, Firefox extensions, and other
> >>>> software such as antivirus tools, that may affect Firefox. I am
> triaging
> >>>> these bugs as necessary.
> >>>>
> >>>> --BDS
> >>>>
> >>>> ___
> >>>> firefox-dev mailing list
> >>>> firefox-...@mozilla.org
> >>>> https://mail.mozilla.org/listinfo/firefox-dev
> >>>>
> >>>
> >>>
> >>> ___
> >>> firefox-dev mailing list
> >>> firefox-...@mozilla.org
> >>> https://mail.mozilla.org/listinfo/firefox-dev
> >>>
> >>
> >
> >
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Emma Humphries]

​Pasting what I mentioned in #fx-team​


Regarding FFx::Extension Compatibility componen
​t.
​
702 bugs total, 282 of which are not marked against a particular version
​. There are ​
11 in FFx 44, 10 in FFx 45, 9 in FFx 46, 7 in FFx 47, 3 in FFx 48
​, ​
1 tracking FFx 47
​, ​
and only 44 bugs since the first of the year

I'd like to get those into the right component, and make a decision
​ on disposing ​
​of ​
the rest?

--
​ Emma​



On Mon, May 2, 2016 at 1:37 PM, Emma Humphries <e...@mozilla.com> wrote:

> Let me take a look at those.
>
> On Mon, May 2, 2016 at 1:01 PM, Justin Dolske <dol...@mozilla.com> wrote:
>
>> Will Firefox :: Extension Compatibility also be rolled into this new ::
>> Other component?
>>
>> (There are ~700 open bugs there still, most of which look pretty stale.)
>>
>> Justin
>>
>> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg <benja...@smedbergs.us
>> > wrote:
>>
>>> There used to be a bugzilla.mozilla.org product called "Plugins". This
>>> product has been renamed "External Software Affecting Firefox" and its
>>> component structure has been greatly simplified.
>>>
>>> It is usually not helpful to track defects in 3rd-party software in the
>>> Mozilla bug tracker. The only time we want to track those defects is when
>>> we want to make explicit outreach efforts because those defects affect
>>> Firefox users.
>>>
>>> There were previously almost a hundred different "components" for fine
>>> classification of these bugs. This was not producing good results and
>>> caused confusion for many people filing bugs. So I've asked for most of
>>> these components to be retired, and now there will be just three components:
>>>
>>> "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
>>> working with Adobe when necessary.
>>> "OpenH264" - I believe Maire Reavy's team triages this component for
>>> bugs that affect our deployment of OpenH264 with Cisco.
>>> "Other" - For defects in basically all other 3rd-party software,
>>> including other NPAPI and GMP plugins, Firefox extensions, and other
>>> software such as antivirus tools, that may affect Firefox. I am triaging
>>> these bugs as necessary.
>>>
>>> --BDS
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Emma Humphries]

Let me take a look at those.

On Mon, May 2, 2016 at 1:01 PM, Justin Dolske  wrote:

> Will Firefox :: Extension Compatibility also be rolled into this new ::
> Other component?
>
> (There are ~700 open bugs there still, most of which look pretty stale.)
>
> Justin
>
> On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg 
> wrote:
>
>> There used to be a bugzilla.mozilla.org product called "Plugins". This
>> product has been renamed "External Software Affecting Firefox" and its
>> component structure has been greatly simplified.
>>
>> It is usually not helpful to track defects in 3rd-party software in the
>> Mozilla bug tracker. The only time we want to track those defects is when
>> we want to make explicit outreach efforts because those defects affect
>> Firefox users.
>>
>> There were previously almost a hundred different "components" for fine
>> classification of these bugs. This was not producing good results and
>> caused confusion for many people filing bugs. So I've asked for most of
>> these components to be retired, and now there will be just three components:
>>
>> "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
>> working with Adobe when necessary.
>> "OpenH264" - I believe Maire Reavy's team triages this component for bugs
>> that affect our deployment of OpenH264 with Cisco.
>> "Other" - For defects in basically all other 3rd-party software,
>> including other NPAPI and GMP plugins, Firefox extensions, and other
>> software such as antivirus tools, that may affect Firefox. I am triaging
>> these bugs as necessary.
>>
>> --BDS
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

This is probably a field that could stand to be re-labled, as I was
blithely thinking (and I would guess others are) that it was for features,
only.

-- Emma

On Tue, Apr 12, 2016 at 1:01 PM, Mark Côté  wrote:

> On 2016-04-07 2:50 AM, L. David Baron wrote:
> > (I'd much rather a bug report be editable text, with history
> > available, for answers to these or similar questions -- rather than
> > a stream of permanent comments.  But we seem stuck with the horrid
> > stream-of-comments Bugzilla format, which means I try to ignore the
> > comments as much as I can.  Then again, a 200 character summary is
> > often good enough to answer the above 5 questions.  As with the rest
> > of the Internet, don't read the comments.)
>
> Meant to reply to this earlier... BMO has a User Story field that sounds
> like it does exactly what you want.  It's an editable field that keeps
> history (admittedly not in an easy-to-read way, but that could be
> improved).  Despite the name of the field, I've found it useful for
> summarizing the current state of the discussion in the bug (sometimes
> along with the "obsolete" comment tag).
>
> Mark
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

[Emma Humphries]

Sent them an email.


On Mon, Apr 11, 2016 at 3:26 PM, Emma Humphries <e...@mozilla.com> wrote:

> Ah, I was looking at open bugs.
>
> Okay, he's either got a script running or something similar.
>
> On Mon, Apr 11, 2016 at 3:04 PM, Mats Palmgren <m...@mozilla.com> wrote:
>
>> On 2016-04-11 23:32, Emma Humphries wrote:
>>
>>> Here's the open bugs they have touched http://mzl.la/1Q3w24o
>>>
>>
>> He touched 283 bugs in the last 48 hours, most of which are FIXED.
>>
>> Many comments are identical, for example:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1240762
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1240778
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1240670
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1240682
>>
>> All four have identical comments, added in a time span of 15 seconds.
>>
>> /Mats
>>
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

[Emma Humphries]

Ah, I was looking at open bugs.

Okay, he's either got a script running or something similar.

On Mon, Apr 11, 2016 at 3:04 PM, Mats Palmgren <m...@mozilla.com> wrote:

> On 2016-04-11 23:32, Emma Humphries wrote:
>
>> Here's the open bugs they have touched http://mzl.la/1Q3w24o
>>
>
> He touched 283 bugs in the last 48 hours, most of which are FIXED.
>
> Many comments are identical, for example:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240762
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240778
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240670
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240682
>
> All four have identical comments, added in a time span of 15 seconds.
>
> /Mats
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

[Emma Humphries]

Here's the open bugs they have touched http://mzl.la/1Q3w24o

I realized this morning at the Project Meeting that we still have Monday's
listed as bug triage days and I think there's some supporting structure
around it that we need to give it.

Let me think about that, so we can keep y'all from getting noise in your
bugmail.

-- Emma

On Mon, Apr 11, 2016 at 2:23 PM, Jim Blandy  wrote:

> Has anyone contacted the commenter and found out what he's trying to do?
>
> I've received bugmail for a lot of comments like the one below today; I
> assume others have too. They're not very helpful, especially given their
> length. It seems like he's intending to be helpful, but got some bad
> advice. The "bugday" reference makes me think he might have been
> participating in a Mozilla event. It would be sad if he was attempting to
> contribute to the project and ended up wasting both his own and our time.
>
> -- Forwarded message --
> From: Bugzilla@Mozilla 
> Date: Sun, Apr 10, 2016 at 9:15 AM
> Subject: [Bug 1224726] High memory consumption when opening and searching a
> large Javascript file in debugger.
> To: j...@mozilla.com
>
>
> *Comment # 21 
> on
> Bug 1224726  from
> Mayur Patil  at 2016-04-10 09:15:44 PDT *
>
> [bugday-20160323]
>
> Status: RESOLVED,FIXED -> UNVERIFIED
>
> Comments:
> STR:
> File is not present on Dropbox.
>
> Component:
> Name Firefox
> Version 46.0b9
> Build ID 20160322075646
> Update Channel beta
> User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0)
> Gecko/20100101
> Firefox/46.0
> OS  Windows 7 SP1 x86_64
>
> Expected Results:
> Memory based test depends on index.html
>
> Actual Results:
> No zip file has found on dropbox.
>
>
> --
> Product/Component: Firefox :: Developer Tools: Debugger
> --
> *Tracking Flags:*
>
>- status-firefox45:affected
>- status-firefox46:fixed
>
> --
> *You are receiving this mail because:*
>
>- You are watching the component for the bug.
>
> X-Bugzilla-Reason: None
> X-Bugzilla-Type: changed
> X-Bugzilla-Watch-Reason: Component-Watcher
> X-Bugzilla-Classification: Client Software
> X-Bugzilla-ID: 1224726
> X-Bugzilla-Product: Firefox
> X-Bugzilla-Component: Developer Tools: Debugger
> X-Bugzilla-Version: 45 Branch
> X-Bugzilla-Keywords:
> X-Bugzilla-Severity: normal
> X-Bugzilla-Who: ram.nath241...@gmail.com
> X-Bugzilla-Status: RESOLVED
> X-Bugzilla-Resolution: FIXED
> X-Bugzilla-Priority: P1
> X-Bugzilla-Assigned-To: bgrinst...@mozilla.com
> X-Bugzilla-Target-Milestone: Firefox 46
> X-Bugzilla-OS: Windows 8.1
> X-Bugzilla-Changed-Fields: Comment Created
> X-Bugzilla-Changed-Field-Names: comment
> X-Bugzilla-URL: https://bugzilla.mozilla.org/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

On Wed, Apr 6, 2016 at 6:47 PM, Emma Humphries <e...@mozilla.com> wrote:

>
> I'd like to finish up feedback on by the end of the working day Thursday
> the 6th (PST.)
>
> Then we'll get to work on a solid specification for the work so we can
> start implementation sometime in Q2.
>


​Okay, closing off discussion for now. If you need to follow up, contact me
on #bugmasters or email.

I'm working on a gdoc with the updated proposal.

-- Emma​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

And yes, that's what I mean by Platform.

Thanks.

On Fri, Apr 8, 2016 at 11:24 AM, Andrew McCreight 
wrote:

> Emma can correct me if I'm wrong, but I think she is using "Firefox" in
> the non-jargony sense of the entire thing we're shipping in Firefox,
> including Gecko. We've been using this system for a month or so in DOM. I
> think it has been going well. Anybody who is interested can ask Andrew
> Overholt or I for details.
>
> Andrew
>
> On Fri, Apr 8, 2016 at 10:52 AM, Douglas Turner  wrote:
>
>> Emma,
>>
>> Thanks for doing this.
>>
>> I'm not sure whether something like this would work for platform
>> engineering, but we'll keep an eye how things develop with Firefox and
>> might consider it once we have some experience there.  I encourage you to
>> report back here when Firefox starts using this system and has some lessons
>> learned.
>>
>> I also want to thank all of the people that participated in this
>> conversation.
>>
>> Doug
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

First: there's that Bugzilla Anthropology project (
https://wiki.mozilla.org/Bugzilla_Anthropology) thanks. I'd heard mention
of it and asked around.

What we found during the pilot, and the Platform Team has found in their
triage, is that list of bugs with needinfo? is

I'm worried that multiple queues in a component would be adding complexity,
but this is something I'm willing experiment with.

I don't think that picking a component or group of components we could try
that style of triage on would block implementing the Triaged:Yes|No flag
and UX improvements in Bugzilla.

Would you be up for helping me run a short pilot of the multi-queue system
you're describing?

-- Emma


On Wed, Apr 6, 2016 at 11:50 PM, L. David Baron <dba...@dbaron.org> wrote:

> On Wednesday 2016-04-06 18:47 -0700, Emma Humphries wrote:
> > Following up on yesterday's email: I put together a draft second proposal
> > and shopped it around some, and now I want to bring that back into the
> main
> > discussion.
> >
> > The bullet point version of this is:
> >
> > * Add a binary field that components can use, TRIAGED (Y/N, T/F, +,-)
> > * In the case of Firefox related components, have a consistent definition
> > of P1-P5 and make sure that triaged bugs have a Priority assigned
>
> > > On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries <e...@mozilla.com>
> wrote:
> > >> Today I’m asking for feedback on the plan which is posted at:
> > >>
> > >>
> > >>
> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
>
> I'm assuming the above URL represents the current proposal, although
> given the "draft second proposal" wording above, I'm not sure if
> that's the case.
>
>
> I don't think the idea that a bug belongs in the triage queue if it
> is untriaged and without a needinfo? is the right process.  I think,
> instead, that there should be less emphasis on needinfo? to a
> specific person, and more emphasis on grouping bugs into a small
> number of categories of information that is needed, and allowing
> people to triage those separate queues.
>
> Explaining why I think that requires a little bit of a digression:
>
> There are a number of separate things we want to understand in a bug
> report, as I described in http://dbaron.org/log/20120816-bug-system :
>
> Understand description
> Do the developers or triagers reading the bug understand
> what the reporter is saying?
>
> Agree it's a bug
> Do the module owners or peers or other authority agree that
> the problem is a bug?
>
> Can reproduce
> Can others reproduce the problem described?
>
> Why it's important
> What makes this problem important or urgent to fix?
>
> How to fix
> What should be done to fix the problem?
>
> (I'd much rather a bug report be editable text, with history
> available, for answers to these or similar questions -- rather than
> a stream of permanent comments.  But we seem stuck with the horrid
> stream-of-comments Bugzilla format, which means I try to ignore the
> comments as much as I can.  Then again, a 200 character summary is
> often good enough to answer the above 5 questions.  As with the rest
> of the Internet, don't read the comments.)
>
> Determining answers to any or all of the above might require
> multiple rounds of dialog, and some of them need to be understood in
> sequence rather than in parallel.  They also require very different
> sets of expertise to determine.  (Some of them require people with a
> bit of domain knowledge; some require detailed knowledge of relevant
> specifications.)  But they also don't require expertise from one
> person in particular, so needinfo? is not generally appropriate.  So
> the idea that bugs are in a queue unless they have a needinfo? seems
> wrong to me; I think a good triage process should involve queues
> representing the type of knowledge that's needed, rather than queues
> for a particular person to answer -- and people should be able to
> triage those queues (e.g., bugs that are untriaged because they lack
> information that allows others to reproduce, bugs that are untriaged
> because they require an expert in the relevant standard to decide
> whether our current behavior is correct or not -- state that could
> also be reflected in the bug) or the general queue of
> next-step-unknown bugs.
>
> While we can't get very far at all if we don't understand the
> description, it's often hard to make a decision about the priority
> until we understand how many users are affected (which sometimes
> requires the ability to reproduce), and about whether the bug
> described is act

Re: Triage Plan for Firefox Components

[Emma Humphries]

On Fri, Apr 1, 2016 at 9:45 AM, James Graham  wrote:

> But once we have picked something, can we at least try to remove any UI
> that is more-or-less vestigial given that decision and, at least briefly,
> fight entropy by making things simpler and more consistent, rather than the
> reverse.



​Yes. I do want to do this as I work on the implementation of the changes
for triage.

-- Emma​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

It's been a week since I asked for your comments on the plan for triage,
thank you.

I'm going reply to some general comments on the plan, and outline next
steps.

Ekt and others said that up to now, individual teams have owned how they
triage and prioritized bugs. Mozilla has made commitments to how we are
going to follow up with people filing bugs. Thus we need consistent
decisions across all the components that go into Firefox about bugs that we
can share back to non-Mozillans on bugs they file, so that we can get them
to contribute more high-quality bugs, and participate in other efforts in
support of the project and the Open Web. I'm aware I'm asking teams with
existing process to make a change, but it's for a global gain.

Several people pointed out all the fields in Bugzilla that have and could
be used to manage priorities, such as priority and rank. But we don't use
the priority field consistently across the project. I've asked for teams to
document how they use Priority,
https://wiki.mozilla.org/Bugmasters/Projects/Folk_Knowledge/Priority_Field,
and you'll see how that varies.

When I checked how the Priority field was used in Firefox-related
components, that distribution was:

--- 460,362
P1   14,304
P2   15,971
P3   37,933
P44,204
P52,913

The bulk of bugs in Firefox-related components are P3, most likely because
we have a bug filing form that defaults to P3 and that needs to be fixed if
it's still in use.

Having to make what seemed like snap-decisions on bugs was also a point of
concern, but that's something the proposal had a work around for, using
needinfo? to defer a triage decision on a bug until enough questions were
answered. And since we made a commitment to make decisions on bugs, we need
back pressure on untriaged bugs.

But from what I read, y'all are amenable to standardizing the priority
flag's use in Triage. Doing that would create a discontinuity in historical
data, but that's not an insurmountable problem, and we can document that
breakage for researchers using historical data.

So next step is a second proposal, simplified, using Priority to represent
triage decisions.

In addition, I'll want to remove several fields which are not useful, or
superfluous from the bug entry wizards. Priority is a field that should be
set by people triaging bugs, not entering them. We have a keyword
vocabulary which is more expressive than severity. And our bug entry forms
don't show the version affected, or the STR (steps to reproduce) flags
which means it's an extra edit to get the information relman needs into a
bug.

Thank you again for your time and consideration as we make Bugzilla and
Firefox better for everyone.

-- Emma Humphries


On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries <e...@mozilla.com> wrote:

> tl;dr
>
> In Quarter Two I'm implementing the work we’ve been doing to improve
> triage, make actionable decisions on new bugs, and prevent us from shipping
> regressions in Firefox.
>
> Today I’m asking for feedback on the plan which is posted at:
>
>
> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
>
> Allowing bugs to sit around without a decision on what we will do about
> them sends the wrong message to Mozillans about how we treat bugs, how we
> value their involvement, and reduces quality.
>
> The Firefox quality team (myself, Mike Hoye, Ryan VanderMeulen, Mark Cote,
> and Benjamin Smedberg) want to make better assertions about the quality of
> our releases by giving you tools to make clear decisions about which bugs
> must be fixed for each release (urgent) and actively tracking those bugs.
> What We Learned From The Pilot Program
>
> During the past 6 weeks, we have prototyped and tested a triage process
> with the DOM, Hello, and Developer Tools teams.
>
> Andrew Overholt, who participated in the pilot for the DOM team, said, “A
> consistent bug triage process can help us spread the load of watching
> incoming bugs and help avoid issues falling through the cracks."
>
> During the pilot, the DOM team uncovered critical bugs quickly so that
> people could be assigned to them.
>
> The pilot groups also found that the triage process needs to be fast and
> have tooling to make going through bugs fast. It’s easy to fall behind on
> triage for a component, but if you stay up to date it will take no more
> than 15 minutes a day.
>
> You can find the bugs we triaged during the pilot by looking for
> whiteboard tags containing ‘btpp-’.
>
> It is also important to have consistent, shared definitions for regression
> across components so triagers do not waste effort on mis-labeled bugs.
> Comments?
>
> I am posting this plan now for comment over the next week. I intend to
> finalize the triage plan for implementation by Tuesday, April 5th. Feedback
> and questions are welcome on the documen

Re: Triage Plan for Firefox Components

[Emma Humphries]

While we're on the topic of how teams use the Priority Flag, could I ask
y'all do to something for me?

Could you add how your team maps the the priority flag, or link to a page
describing it?

https://wiki.mozilla.org/index.php?title=Bugmasters/Projects/Folk_Knowledge/Priority_Field=edit=1

Thank you!

On Fri, Apr 1, 2016 at 10:46 AM, Mats Palmgren  wrote:

> On 04/01/2016 10:35, Marco Bonardo wrote:
>
>> Fwiw, we (Awesome Search Team) also use Priority for the backlog, and we
>> consider P1, P2 and P5 the same as Media Playback team. So there is some
>> convergence about the meaning of those.
>> Though we also use P3 for "we care about this and will fix it, provided
>> there's no major priority bug to fix first".
>>
>
> This is roughly how we use P1-P5 in Layout as well:
> http://dbaron.org/log/20090120-bug-priorities
>
> /Mats
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

What to call these has been a long thread in the document comments, but I'm
starting to lean towards:

FIX-FOR-RELEASE
FIX-SOON
and
BACKLOG

as well as adding (see the proposed edit) a FEATURE resolution for bugs
which are feature tracking and individual features. I'd consider adding a
consistency rule requiring a User Story field for bugs in that status.


On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic <msrecko...@mozilla.com>
wrote:

> This may be somewhat long winded.  I will make it in the context of Gecko
> graphics, because that’s where I have the most data and experience.  It may
> or may not apply to other components.
>
> Reviewing all the incoming bugs, in a timely matter, is very important to
> us.  Over the past few years, the graphics team fixed about half the bugs
> that came in (roughly, we fix a thousand out of the two thousand that come
> in.)  The main goal of any kind of a bug triage process is thus to choose
> the right half of the bugs to fix, and spend as little time as possible on
> the rest.
>
> With that in mind we started a much less documented and much more minimal
> process in 2015.  I don’t know that we have the data to back the “avoid
> issues falling between the cracks”, but it certainly seems that way.  One
> data point we do have - the average amount of time it took to fix the bugs
> triaged in 2015 was almost half of that for 2014 and the previous four
> years.
>
> This to illustrate that I believe in the bug triage, looking at bugs as
> they come in, and making some quick decisions how to proceed.
>
> I’m also a big believer in lightweight processes and minimal
> documentation, so there are a few comments I have on what the document
> below describes, and in general.
>
> The more states we have, the more not-so-useful conversation we’ll have
> about assigning those states.  I’m glad to see that we have a small number,
> currently named fix-now, non-urgent and wishlist (the naming is in flux and
> being argued in the document.)  I’m mentally mapping these to “blocking the
> release”, “can’t ship too many releases with this” and “I hope we
> eventually fix this”, but perhaps there is a different interpretation.
>
> I would expect to see the majority of the graphics bugs end up in the last
> group.  Why?  Since you never plan for the full capacity, as that actually
> reduces your throughput, and since we only fix half the bugs that come in,
> it stands to reason that we should not have even close to half of the bugs
> in the first two categories.  In other words, we want to be fixing some of
> the “wishlist” bugs.  And we need to be very careful about not making the
> fix-now turn into “we really should fix this”, and only allow the “team
> works on nothing else while there are fix-now bugs open”.  Otherwise, well,
> it loses its value.
>
> Step aside - my thoughts on the “How Triage Will Work in Bugzilla”
> section.  I would stick with the definition of the states and have
> dashboards that show the bug counts in different categories for different
> teams.  The current description is a bit too detailed and inflexible.  It
> suggests that we can figure out the best way to do this before we’ve even
> started doing it (the pilot program non-withstanding), and it mixes the
> mechanics with the goals.
>
> I’m going to start and keep arguing that we do not want to have an
> explicit name for that largest bucket of “wishlist” bugs, and should
> instead have it marked by the absence of a tag.  This is not about the
> heavily involved community, those that will stick around regardless of what
> we do to them, and anybody that reads this e-mail.  This is about people
> that are reporting their first bugs, that are occasionally involved, who
> are vital to our success.  If I was one of those, and I started seeing that
> most, if not all, of my bugs are marked as wishlist or deferred or
> in-copious-spare-time, I’m going to get discouraged and stop doing it.
> After all, I don’t seem to be valuably contributing, because I’m just
> telling you things you don’t care about.  Or, I could start arguing in the
> bug, that this should be higher priority, and fill up the comments with
> non-technical information.
>
> Getting close to a full page, I’ll stop now.  I’m available for live
> conversations on the topic :)
>
> —
> - Milan
>
>
>
> > On Mar 29, 2016, at 16:07 , Emma Humphries <e...@mozilla.com> wrote:
> >
> > tl;dr
> >
> > In Quarter Two I'm implementing the work we’ve been doing to improve
> > triage, make actionable decisions on new bugs, and prevent us from
> shipping
> > regressions in Firefox.
> >
> > Today I’m asking for feedback on the plan which is posted at:
> >
> >
> https:/

Re: Triage Plan for Firefox Components

[Emma Humphries]

On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic 
wrote:

> Or, I could start arguing in the bug, that this should be higher priority,
> and fill up the comments with non-technical information.



​This reminds me, we have filtering tools to mute abusive and unproductive
comments in bugs.

https://wiki.mozilla.org/BMO/comment_tagging

-- Emma

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

Re: Triage Plan for Firefox Components

[Emma Humphries]

I've responded to a similar comment in the google doc, but I'll repeat it
here.

Priority sounds like a great choice, but given that everyone's using the
Priority field their own way, there's enough heterogeneity in how it's used
to make it difficult.

If I was to take that approach, I'm concerned about what it would do with
historical data. We'd also have the P3, and P4 values hanging round like
vestigial limbs.

FYI, in FFx related components.

--- 460,362
P1   14,304
P2   15,971
P3   37,933
P44,204
P52,913

The bulk of bugs in FFx related components are P3.

-- Emma

On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson 
wrote:

> On 3/31/16 3:22 PM, Daniel Veditz wrote:
>
>> ​We get that now, with no marker at all. The only real difference I see
>> with a marker is that people will catch on sooner whereas now it takes a
>> while until they realize they are being ignored. They eventually get
>> discouraged​ or upset either way. Might even be better with a marker (for
>> some people) because at least they have some acknowledgement that someone
>> has looked at the bug even if they disagree about the importance. We may
>> have misunderstood, and thus mis-triaged, the bug and an explicit marker
>> might trigger the attempt to clarify sooner.
>>
>
> Anthony's Media Playback team has been using a simple and effective triage
> system without special tags. All open bugs in the Audio/Video Playback
> component are in one of four states at all times:
>
> * Priority P1 bugs should be fixed ASAP.
> * Priority P2 bugs are real bugs or features we want to fix soon.
> * Priority P5 bugs are "patches accepted" bugs.
> * Bugs without a priority are untriaged.
>
> P3 and P4 are not used. :) P5 sends a pretty clear message to people that
> we will not fix that issue any time soon. However, the P5 list is pretty
> clean because we aggressively WONTFIX bugs we truly don't want to fix
> instead of letting them linger.
>
> Bugzilla already has a lot of fields. It seems like new workflows could be
> built with a streamlined frontend UI without changing Bugzilla's database
> schema. The advantage of codifying existing workflows instead of adding new
> fields is that existing bugs will be compatible with the new system.
>
> IIRC, the Fennec team also tracked the "Someone is working on this"
> proposed in Emma's plan by assigning owners to all bugs, but developers
> would change their bug's status from NEW to ASSIGNED only when they began
> actively working on the bug.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

On Tue, Mar 29, 2016 at 5:09 PM, Eric Rescorla  wrote:

> On a more substantive, less procedural note, this seems to be designed for
> a particular workflow in which there is an assumption that bugs are for
> immediate processing. However, in may cases we use bugs as placeholders or
> assemble big dependency trees of all the bugs that are needed to do a large
> complex feature. From this perspective, a three-tier system of "urgent",
> "non-urgent", and "wishlist" is either a regression from more fine-grained
> systems such as dependency trees/priorities or is redundant with them. This
> is especially true for long-running efforts. In other words, this may be a
> useful change for some components while not being useful for others. For
> the specific case of NSS (where I currently do a lot of my work) this
> doesn't seem like it would be a helpful change.


​This is where it would be nice to have a way of saying, feature vs. bug as
part of the triage process, even it that's not a clean separation to make,
because that could get long running feature work out of the triage process,
but I don't have an immediate answer for this. It may be that we change the
scope of components this applies to.

I'll follow up with Doug Turner to see if changing the scope of this for
platform related bugs is warranted.

​
 --
​ Emma​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Emma Humphries]

Components that feed into FFx, so that's Core, Toolbox, Firefox, Fennec and
the pieces of platform we're using to ship.

While there's not a 'Gecko' component in bugzilla, it does cover the
components there which are Gecko.

-- Emma

On Tue, Mar 29, 2016 at 3:16 PM, Eric Rescorla <e...@rtfm.com> wrote:

> I'm trying to figure out the scope of this proposal. Are you expecting it
> to apply merely to Firefox or to Gecko as well?
>
> -Ekr
>
>
> On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries <e...@mozilla.com> wrote:
>
>> tl;dr
>>
>> In Quarter Two I'm implementing the work we’ve been doing to improve
>> triage, make actionable decisions on new bugs, and prevent us from shipping
>> regressions in Firefox.
>>
>> Today I’m asking for feedback on the plan which is posted at:
>>
>>
>> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
>>
>> Allowing bugs to sit around without a decision on what we will do about
>> them sends the wrong message to Mozillans about how we treat bugs, how we
>> value their involvement, and reduces quality.
>>
>> The Firefox quality team (myself, Mike Hoye, Ryan VanderMeulen, Mark
>> Cote, and Benjamin Smedberg) want to make better assertions about the
>> quality of our releases by giving you tools to make clear decisions about
>> which bugs must be fixed for each release (urgent) and actively tracking
>> those bugs.
>> What We Learned From The Pilot Program
>>
>> During the past 6 weeks, we have prototyped and tested a triage process
>> with the DOM, Hello, and Developer Tools teams.
>>
>> Andrew Overholt, who participated in the pilot for the DOM team, said, “A
>> consistent bug triage process can help us spread the load of watching
>> incoming bugs and help avoid issues falling through the cracks."
>>
>> During the pilot, the DOM team uncovered critical bugs quickly so that
>> people could be assigned to them.
>>
>> The pilot groups also found that the triage process needs to be fast and
>> have tooling to make going through bugs fast. It’s easy to fall behind on
>> triage for a component, but if you stay up to date it will take no more
>> than 15 minutes a day.
>>
>> You can find the bugs we triaged during the pilot by looking for
>> whiteboard tags containing ‘btpp-’.
>>
>> It is also important to have consistent, shared definitions for
>> regression across components so triagers do not waste effort on mis-labeled
>> bugs.
>> Comments?
>>
>> I am posting this plan now for comment over the next week. I intend to
>> finalize the triage plan for implementation by Tuesday, April 5th. Feedback
>> and questions are welcome on the document, privately via email or IRC
>> (where I’m emceeaich) or on the bugmast...@mozilla.org mailing list.
>> Timeline
>>
>> January: finish finding component responsible parties
>>
>> February: pilot review of NEW bugs with four groups of components, draft
>> new process
>>
>> Now: comment period for new process, finalize process
>>
>> Q2: implement new process across all components involved in shipping
>> Firefox
>> Q3: all newly triaged bugs following the new process
>>
>> -- Emma Humphries, Bugmaster
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform