In mozilla/bugbot#992, Sheriffs asked us to denote intermittent test failure bugs by keyword instead of the bug's filer. We need AWTY to use the same definition.

Same as https://github.com/mozilla/triage-center/issues/46 but in yet another triage query. Can we please settle on one tool? The current state of triage is quite frustrating.

Add DevTools

Move the versions array out of the configuration object and extend it with a year's worth of releases, then pick the slice to use based on date.

Currently the list of P1 does not make much sense:

1. We check the status flag against ---,?, while these are the values of the tracking flags.
   Problem: This condition will always be false.
2. We include any bug which has a creation date newer than the mergedate, which corresponds to the day the branch is created.
   Problem: This might be what the "may affect" is meant to be, but it causes to filter out any P1 affecting previous version. i.e. P1 affecting 60 will not be listed in the list of P1 affecting 61, because the status flags are not automatically propagated from one version to the next.

I suggest to modify this search such that we include any P1 opened before branching to beta. Thus converting the condition to:

ANY(
  ${"cf_status_" + versionStr} == affected
  ALL(
    ${"cf_status_" + versionStr} is-empty
    creation_ts <= ${betadate}
  )
)

This will remove the "may affect" aspect of the query, but this will include all P1 affecting a given version.

It took me a while to find this github repo, could we get a link to it from the main page please?

Per https://bugzilla.mozilla.org/show_bug.cgi?id=1480097 adding "stalled" keyword so need to filter this out of triage queries.

This is a proxy for non-Mozillians

Untriaged query for a release is:

• bug filed on or after branch date
• bug is not an enhancement or meta-bug
• priority is --
• status for release is ? or ---

Should the status field be equal to ?, ---, or affected?

@sylvestre should we add this product?

STR:

1. open https://are-we-triaged-yet.glitch.me/ with a window width < 1440px

EB:

• Site fits the width of the screen.

AB:

• The x-axe is scroll-able.

Due to w3c/csswg-drafts#1766 the scrollbar is calculated in the viewport, which is causing an overflow on the x-axe.

https://github.com/emceeaich/are-we-triaged-yet/blob/master/public/style.css#L10
This can be fixed for some win / linux by changing the width: 100vw to width: 100%.

There is also the issue of the grid is getting sized against the padding box of the body, which is what causes the weirdness for the other use case.

I'm running OSX 10.13.3, FF 64 latest build (also happens on Chrome 69) with a 13" display (width: 1440px).

@MatsPalmgren Maybe you have an idea why this happens?

No longer needed now that Build System is its own product.

https://bugzilla.mozilla.org/show_bug.cgi?id=1494645 lets us add custom titles to buglists as query string parameters.

Let's add:

• Report title bugs in X:Y
• Report title bugs in X:Y less than one week old
• Report title bugs in X:Y less than one month old
• Report title bugs in X:Y more than one month old

Ritu said that Release Management uses a broader scope for uplifts. Not just the Firefox ones.

These are the queries to use.

https://bugzilla.mozilla.org/rest/bug?include_fields=id,summary,status&chfield=cf_status_firefox59&chfieldfrom=2018-01-22&chfieldto=Now&chfieldvalue=fixed&f2=flagtypes.name&f5=attachments.ispatch&o2=equals&v2=approval-mozilla-beta%2B

https://bugzilla.mozilla.org/buglist.cgi?list_id=14029532&o2=equals&chfieldto=Now&query_format=advanced&chfield=cf_status_firefox59&chfieldfrom=2018-01-22&f2=flagtypes.name&chfieldvalue=fixed&f5=attachments.ispatch&v2=approval-mozilla-beta%2B

Bugs older than a month
Bugs older than a week
Bugs less than a week old
All Bugs

The second column includes the first, so call it out

via @hildjj

This Mozilla repository has been identified as lacking a license. Consistent with Mozilla's Licensing Policy an open source license should be applied to the code in this repository.

Please add an appropriate LICENSE.md file to the root directory of the project. In general, Mozilla's licensing policies are as follows:

• Client-side products created by Mozilla employees or contributors should use the Mozilla Public License, Version 2.0 (MPL).

• Server-side products or utilities that support Mozilla products may use either the MPL or the Apache License 2.0 (Apache 2.0).

In special cases, another license might be appropriate. If the repository is a fork of another repository it must apply the license of the original. Similarly, another license might be appropriate to match that of a broader project (for example Rust crates that Firefox depends on are published under an Apache 2.0 / MIT dual license, as that is the dual license used by the Rust programming language and projects).

Please ensure that any license added to the LICENSE.md file matches other licensing information in the repository (for example, it should match any license indicated in a setup.py or package.json file).

Mozilla staff can access more information in our Software Licensing Runbook – search for “Licensing Runbook” in Confluence to find it.

If you have any questions you can contact Daniel Nazer who can be reached at dnazer on Mozilla email or Slack.

OPENLIC-2023-01

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

STR

1. Visit https://are-we-triaged-yet.herokuapp.com/?report=untriaged&version=61&all
2. Search for "Bookmarks & History"
3. Open the bug link.

Link is: https://bugzilla.mozilla.org/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=2018-03-12&chfieldto=Now&f2=cf_status_firefox61&f3=bug_severity&f4=short_desc&f5=component&o2=anywords&o3=notequals&o4=notsubstring&o5=nowordssubstr&priority=--&resolution=---&short_desc=%5E%5C%5Bmeta&short_desc_type=notregexp&v2=%3F%2C---&v3=enhancement&v4=%5Bmeta%5D&v5=%2Cbuild%20conf%2Cca%20cert&order=bug_id&limit=0&product=Firefox&component=Bookmarks%20&%20History

It should have the '&' encoded as well.

Limit untriaged report to defects

This bug in the BMO API affected tracking flags.

Currently AWTY shows results broken down by version. e.g. for a specific version or all versions (where the all-versions page just shows the nightly/beta/release reports concatenated together.)

I think this breakdown ends up not working well -- many of the bugs are repeated across lists, it makes it difficult to get an overview of the state of overall triage, and it makes triagers work more difficult.

The current queries break out "versions" by using the date of when the bug was filed. e.g. Firefox 60 started on m-c on Jan 22, so the query filters for any bug filtered after that date. Firefox 62 started on m-c on May 7th, so the Fx62 query similarly filters. But that means the Fx60 query includes all Fx62 bugs. This alone is not technically wrong (since most bugs lack more detailed metadata about exactly what versions they affect), but it means there can be a lot of duplication across "versions".

For example, at the moment AWTY says that for Firefox::Untriaged, there are 136 untriaged bugs for Fx60, and 127 for Fx62. (The actual numbers, upon clicking the number, are 127 for Fx60 and 117 for Fx62. Caching I assume.) But the vast majority of those bugs are the same -- diffing the list, there are just 10 bugs different between those two queries. If you look at those Fx60 bugs, all but 10 were filed after May 7th. This also means you can't just add up the untriaged count, by version, to get a total number of untriaged bugs, because you'd be double-counting.

But since the queries for 60/61/62 are all slightly different (because of the status-firefoxXX flag checks) this is a pain for triaging (as I've noted before) because the lists can be slightly different, and thus triage owners need to go through each component they own 3 times. (Firefox::Untriaged is a bad example for this case, because status-firefoxXX flags are rarely going to be set in this component.) Triagers should, ideally, have a single link and a single number to monitor.

IMO, the simplest thing is to just collapse this all down to a single query that doesn't try to show status by version. It can still use the bug-filed-after cutoff date of the current Release, and should filter on "(status-firefox60 == ?/---/affected OR status-firefox61 == ?/---/affected OR status-firefox62 == ?/---/affected)".

In other words, a bug filed since date X that is/may be affecting a current release, and will show up on the list unless it's explicitly marked as (say) "wontfix" for all of nightly/beta/release. [There might even be an argument for removing this entirely – for triagers – since the goal is to to be assigning a priority to bugs within a week or two of it being filed. At that point, it's not terribly useful to get bugs off the radar by kicking the can down the road with status-firefoxXX flags.]

I suppose release-drivers will still want something more limited by version (and that's definitely checking status-firefoxXX flags) to monitor bugs that may affect something heading out the door, but that feels like a different use-case than basic triage.

which is because there are no uplifts to nightly

Currently it looks like the dashboards are filtering on "status-firefox61: ?, ---", I'm wondering if that should possibly include "affected" as well, e.g. bug 1453545 was moved to the Bookmarks & History component from Untriaged, with its status flag set to "affected", however it hadn't been analysed or given a priority.

This is 14:00 UTC

Get out of the templating business.

Update on heroku.

• update at midnight UTC
• easier to update a DB/table
• less surprise when triaging