Changes to numbering of Versions and Milestones fields in Bugzilla

/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

New Triage Process: Triage Center Updated

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

Re: Tooling and reporting changes

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 t

Re: Tooling and reporting changes

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 cha

Tooling and reporting changes

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

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

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

Identifying bugs affecting people working and learning from home

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

Requesting SUMO docs from Bugzilla

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

Fwd: happy bmo push day!

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

Upcoming Bugzilla API and Bot Changes

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

Bugzilla Bugmail Powertip: preventing bounces

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

Bug Handling in Bugzilla over the End of the Year

* 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

New home for Firefox Bughandling Docs

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

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.

Updates to Bugzilla components for Bugzilla

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

[notice] Bugzilla Errors

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.

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

[ Intent to change ] Updates to Are We Triaged Yet

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

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

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

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

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

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

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

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: > He

Re: Inbound change to Are We Triaged Yet?

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

Inbound change to Are We Triaged Yet?

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

Intent to Change: Marking Up Regressions in Bugzilla

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

Re: Disabling the UINEEDED keyword

icular 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, Da

Re: Changes to how we track regressions in Bugzilla

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

Re: Changes to how we track regressions in Bugzilla

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 confus

Changes to how we track regressions in Bugzilla

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

Re: Disabling the UINEEDED keyword

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 n

Disabling the UINEEDED keyword

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

Update to "Are We Triaged Yet" for Bug Types

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

Writing JS preference observers? Help us test feature gate.

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

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 (

Intent to Disable Metadata:

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. *

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

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

Intent to disable 'backlog' tracking flag in Bugzilla

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

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

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. &g

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

is. 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?

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

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

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

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

. -- 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

> 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

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

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%2

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

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

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

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:

[no subject]

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

Triage Report 2017-08-28

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

Re: Triage Summary 2017-08-21

, 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 t

Triage Summary 2017-08-21

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.

Triage Summary 2017-08-07

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

Status of Closing Intermittents

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.

Re: Bulk Closing Intermittents

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

Re: Bulk Closing Intermittents

e 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.

Re: Bulk Closing Intermittents

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> wro

Bulk Closing Intermittents

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

Re: QF bug whiteboard tags

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.

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

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

Re: Pulsebot has been given a major game misconduct penalty

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

Pulsebot has been given a major game misconduct penalty

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

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

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

Adding CSP to bugzilla.mozilla.org

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

Emoji and Bugzilla

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.

How To Tags Comments in Bugzilla So We Can Respond Appropriately

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

Re: Triage Plan for Firefox Components

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 >

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

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

Re: Visualizing Crash Data in Bugzilla

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

Triage for Component Leads

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:

Re: The Whiteboard Tag Amnesty

tem" 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 w

Re: The Whiteboard Tag Amnesty

ing 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 th

Re: The Whiteboard Tag Amnesty

gt; 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, Kartik

Re: The Whiteboard Tag Amnesty

s 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 tag

The Whiteboard Tag Amnesty

/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

Re: Intent to remove: Error Console

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 > w

Re: Intent to remove: Error Console

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

Re: Readable Bug Statuses in Bugzilla

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 >

Re: Readable Bug Statuses in Bugzilla

, 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 Sta

Re: Readable Bug Statuses in Bugzilla

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

Readable Bug Statuses in Bugzilla

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

Re: Intent to unship: HTML microdata API

> 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

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

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

Re: Changes to bugzilla "plugins" product

he > 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: > >

Re: Changes to bugzilla "plugins" product

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 compone

Re: Changes to bugzilla "plugins" product

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, Jus

Re: Changes to bugzilla "plugins" product

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,

Re: Triage Plan for Firefox Components

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

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

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> wrot

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

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

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

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

Re: Triage Plan for Firefox Components

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 s

Re: Triage Plan for Firefox Components

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.

Re: Triage Plan for Firefox Components

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

Re: Triage Plan for Firefox Components

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

Re: Triage Plan for Firefox Components

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.

Re: Triage Plan for Firefox Components

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

Re: Triage Plan for Firefox Components

g, 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 > conversatio

Re: Triage Plan for Firefox Components

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

Re: Triage Plan for Firefox Components

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

Re: Triage Plan for Firefox Components

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

Re: Triage Plan for Firefox Components

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

  1   2   >