Re: Running source code analysis on Try

[Nicholas Alexander]

Bastien, others,

On Tue, May 7, 2019 at 9:38 AM Bastien Abadie  wrote:

> TL;DR: We are leveraging the try infrastructure to perform source code
> analysis (linters, static analyzers, etc). You can take advantage of this
> to trigger other try jobs on Phabricator revisions.
>

What is the status of this work?  I want to take advantage of the new
infrastructure to finally turn certain Android analysis tasks into proper
lints (see Bug 1512487 [1]) but the "Plan 4 Source Code Analysis" build
plan appears to both instantly fail and be opaque (see, for example [2]).
I believe that "reviewbot" was very unhappy last night; perhaps that is
related?

Even with setbacks, I'm excited for these changes to make it easier to
build analysis tasks!
Nick

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1512487
[2] https://phabricator.services.mozilla.com/harbormaster/build/89310/


>
> For more than a year, the Release Management & Quality team has been
> running the Code review bot
>  using several
> Mozilla in-house projects: Taskcluster  &
> release-services .
>
> Our process was simple at first: for every new patch on Mozreview, then
> Phabricator, we would run a few analyzers in a Taskcluster task. It worked
> well for some time, but did not provide the flexibility nor the performance
> needed to support more analyzers (clang-format, Infer, Coverity, …)
>
> So we decided to experiment with a more scalable architecture, using
> Treeherder/Try to run all necessary analyzers for your patches, in
> parallel.
>
> This move will give us a lot of benefits:
>
>-
>
>The analyzers themselves are well defined and exposed in
>mozilla-central, allowing us to use the exact same tools as our usual CI
>and the developers on their computers.
>-
>
>Better overall performance and stability (from mercurial clones to
>running analyzers safely in parallel)
>-
>
>A standard analyzer output in JSON will allow us to easily add new
>analyzers. These new implementations could even come from you!
>
>
> Over the last few months, we have been building the different pieces needed
> to move the bot on the Try infrastructure, and today, I’m glad to announce
> it’s running in production, on your revisions!
>
> Any new Diff on Phabricator should now have a build plan named Source Code
> Analysis .
> Phabricator triggers a code review as soon as the diff is published,
> automatically creating a new try job. You’ll get a “Treeherder Jobs” link
> next to the build plan when it’s created by the bot, allowing you to check
> on the analysis progress, and dive into the issues.
>
>
> You will also be able to use Treeherder to add new jobs, effectively making
> it possible to run try tests for Phabricator revisions in just a few
> clicks. On a Treeherder push, open its action menu on the right side (right
> after the Pin button). The "Add new jobs" options shows all the available
> jobs grouped by platform and test suite, and you can click to select and
> then submit. "Add new jobs (Search)" allows you to search in the job names
> like mach try fuzzy and add them.
>
> If the patch contains any issues, they will be reported as before, through
> inline comments. You can now restart a build if it fails (click on the
> Build, there is a “Restart Build” link in the right sidebar). Please note
> that secure revisions are not supported for now, but we are actively
> working on that (a build failure will be shown for secure revisions for the
> time being).
>
> We would like to thank the different people and teams involved in this
> effort: Andrew from the Automation team; Tom, Rail, Chris and Rok from
> Release Engineering; Dustin and Peter from the Taskcluster team; Steven,
> glob and David from the Engineering Workflow team.
>
> If you have any questions regarding this move or the code review bot, feel
> free to contact us by mail or on IRC #static-analyzers.
>
> Bastien, on the behalf of the Release Management and Quality team.
> ___
> 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: Change to preferences via StaticPrefs, tremoval of gfxPrefs

[Jean-Yves Avenard]

On 16/05/2019 9:02 am, Botond Ballo wrote:

Will SpecialPowers.pushPrefEnv(), which currently does propagate the
prefs at least between the content and parent processes, continue to
work? A lot of tests rely on this.


Yes of course.

The changes was to add changes so that process other than the content 
process are synced. I didn't check the necko process, but reading Kris 
message it seems that it does already.


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

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

[Kris Maglione]

On Wed, May 15, 2019 at 07:02:58PM -0400, Botond Ballo wrote:

On Wed, May 15, 2019 at 6:54 PM Jean-Yves Avenard  wrote:

It is then up to each process to handle preference modifications and
pass that change. There's no automatic or universal method on how this
is done unfortunately.


Will SpecialPowers.pushPrefEnv(), which currently does propagate the
prefs at least between the content and parent processes, continue to
work? A lot of tests rely on this.


Preference changes in the parent process are automatically 
propagated to any child processes that handle preference 
changes. Currently, I believe that does not include GPU and VR 
processes. It does include web content processes and the necko 
process.


But for processes that do propagate preference changes, it 
doesn't matter whether they use StaticPrefs or another 
preference access API.

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

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

[Botond Ballo]

On Wed, May 15, 2019 at 6:54 PM Jean-Yves Avenard  wrote:
> It is then up to each process to handle preference modifications and
> pass that change. There's no automatic or universal method on how this
> is done unfortunately.

Will SpecialPowers.pushPrefEnv(), which currently does propagate the
prefs at least between the content and parent processes, continue to
work? A lot of tests rely on this.

Thanks,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

[Jean-Yves Avenard]

Hi

On 16/05/2019 1:54 am, Nicholas Alexander wrote:
Forgive my rank ignorance here, but as an outsider this surprises me: 
I expect "Gecko preferences" to be (eventually) consistent across 
processes.  Is this just not the case, and it's common for prefs to 
vary between the main and content/gfx processes?  Is there a `user.js` 
equivalent for main and child processes?



The whole handling of the preferences across processes is a bit fishy.

Today, preference are fully available only on the main and content 
processes with the limitation that modifying a preference must be done 
on the main thread, and if you modify one outside the main process, the 
change will be local to that process and won't propagate to the others.


On the RDD process (used for media decoding), preferences values are 
passed at the process creation only.


There's no preference support at all on the VR and GPU process.

If you modify a preference on the main thread, the change will propagate 
to process that specifically handle the update with custom code.


Following bug 1550422, Preference will be available on the other 
processes, and will be synced from the main process up. So the 
restrictions that you must modify the preference on the main process for 
them to propagate will remain.


When a new process is created, Preferences value are passed via command 
line arguments except on Windows. On Windows a shared memory object is 
created and the handle to that object is passed via the command line.


It is then up to each process to handle preference modifications and 
pass that change. There's no automatic or universal method on how this 
is done unfortunately.


Jean-Yves


___
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: Outline of a plan to remove all XUL documents from mozilla-central

[Brian Grinstead]

> On May 14, 2019, at 2:43 PM, Dave Townsend  wrote:
> 
> Which test files are we talking about here? If they are testing UI widgets, 
> and our long-term goal is to use html and not xhtml for the UI then those 
> tests should, at some point, be in html.

It's worth breaking the tests down into groups to consider separately. After 
going through this in more detail and based on discussion coming out of this 
post, it makes me think the variation where we do a blanket rename of all .xul 
files to .xhtml might be a better option - it'd certainly be less work at least.

Here are some of the groups of tests I see:

"Reftests" (Number: 364)

These are probably mostly safe to migrate, but there could be different CSS 
applying on elements (for instance if the root node is  and not 
). For that reason I think we could go straight to .xhtml (step 4) 
and then selectively apply the step 5 cleanups as long as they don't break 
tests.

"Crashtests" (Number: 147)

I think I'd go straight to .xhtml (step 4), and probably not even do any step 5 
cleanups. The reasoning is we don't want to go through each test one by one and 
decide if we are losing test coverage by making those changes.

“Mochitests that are specifically testing XML features” (Number: ???)

These would need to go straight to .xhtml (step 4) and then selectively apply 
the step 5 cleanups as long as they don't break tests.

"Mochitests that test built-in widgets" (Number: ~160)

I'm using tests in the `toolkit/content/tests/chrome` folder as a proxy for 
this. As you mention, we might want these to live in the same document the 
browser does (which will be xhtml, at least for now). Though in general 
something a widget that works in .xhtml should also work in .html - the 
breakage would mostly go the other way (i.e. if a widget relied on the 
prototype cache parser ignoring whitespace could work in xhtml but not in 
html). So I think you could argue either way - going straight to .xhtml would 
maintain the status quo.

"Mochitests that don't care about the test document" (Number: ???)

One example that I had envisioned going straight to .html are the 
mochitest-chrome tests in xpfe: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1548152. I picked this folder as a 
starting point because there are only two tests there 
(https://searchfox.org/mozilla-central/source/xpfe/appshell/test/test_hiddenPrivateWindow.xul
 and 
https://searchfox.org/mozilla-central/source/xpfe/appshell/test/test_windowlessBrowser.xul),
 and as far as I can tell there's nothing in them that cares whether the test 
document itself is xul, xhtml, or html.

This is primarily the type of test I had in mind for (3).  My suspicion is that 
there are a lot of tests of that type across the tree. The trick will be 
finding them - Brendan has a script to find the most common DOM patterns across 
all the tests, and there are 32 other tests that match that exact DOM 
structure: 
https://gist.github.com/bgrins/22a448034748340042bdbf499e219a71#file-25-top-repeated-structures-txt-L426.
 It's not a guarantee that all of them would be safe to migrate, but 
spot-checking other tests there it seems to be the case. There are a bunch of 
other shared DOM structures that seem to be in a similar boat.

Brian

> On Tue, May 14, 2019 at 1:48 PM Brian Grinstead  
> wrote:
> There isn't any particular reason functionally to go to one vs the other but 
> I think we still generally prefer to get to plain .html if possible. The 
> reasoning is that it's more common and understood by engineers and tooling. 
> It also doesn't have XML-specific additions like CDATA in script tags.
> 
> That said, after talking through this again with Brendan we realized it may 
> not end up being worth the effort for existing test files. If we were able to 
> apply some of the incremental changes from step 5 to test .xhtml files that 
> may be good enough. If the cost was low to include step 3 (like, if we had a 
> tool that mostly automated away the process) then I’d prefer to do it. But it 
> could be pragmatic to skip step 3 (at least for test documents). We’ll be 
> working on some tooling anyway for step 5, so will spend a bit of time seeing 
> how hard it looks to be to automate the html doc conversion.
> 
> Brian
> 
> > On May 14, 2019, at 12:37 PM, Boris Zbarsky  wrote:
> > 
> > On 5/14/19 11:32 AM, Brian Grinstead wrote:
> >>>3. For files where there are no (important) XUL elements in the
> >>>markup, rename .xul->.html.
> > 
> > Brian,
> > 
> > Could you expand on why this is preferable (when possible) to renaming them 
> > to .xhtml?  Are there benefits to .html over .xhtml for our purposes here?  
> > Is this mostly around how we deal with our tests, as opposed to actual 
> > parts of the UI?
> > 
> > In general, the plan sounds great!
> > 
> > -Boris
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > 

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

[Nicholas Alexander]

On Wed, May 15, 2019 at 6:03 AM Jean-Yves Avenard 
wrote:

> Dear all.
>




> /Possibility to dynamically set a StaticPref on any threads (however,
> the changes aren't propagated to other processes; doing otherwise is
> certainly doable, I'm not convinced of the use case however)./
>

Forgive my rank ignorance here, but as an outsider this surprises me: I
expect "Gecko preferences" to be (eventually) consistent across processes.
Is this just not the case, and it's common for prefs to vary between the
main and content/gfx processes?  Is there a `user.js` equivalent for main
and child processes?

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

Re: Outline of a plan to remove all XUL documents from mozilla-central

[Gijs Kruitbosch]

This was linked already - but comment #0 and the deps of that bug only 
mention no longer relying on the XULDocument interface. That's different 
from "detect and parse .xul files as XHTML" (at least, I think it is). 
I'd expect a separate dependency for that, but I don't see any.


~ Gijs

On 15/05/2019 16:42, Brendan Dahl wrote:

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


On Wed, May 15, 2019 at 6:30 AM Gijs Kruitbosch 
wrote:


On 14/05/2019 16:32, Brian Grinstead wrote:

 1. Load all XUL documents as XHTML using the prototype cache. This
 doesn’t require any file renaming, we will just detect a .xul file

and act

 like it’s .xhtml. This is tracked in bug 1550801
 .


There doesn't seem to be a bug on file listed in that tracking bug for
actually doing the "detect a .xul file and act like it's .xhtml" bit. Is
there one already on file?

I think this step makes me the most nervous - we need to make sure that
we don't change web-observable behaviour, and that the "no remote XUL"
prohibitions continue to apply. In theory, that should all be fine
because of XHTML and namespaces, but I figured it was worth flagging up.

~ 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: Outline of a plan to remove all XUL documents from mozilla-central

[Brendan Dahl]

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


On Wed, May 15, 2019 at 6:30 AM Gijs Kruitbosch 
wrote:

> On 14/05/2019 16:32, Brian Grinstead wrote:
> >> 1. Load all XUL documents as XHTML using the prototype cache. This
> >> doesn’t require any file renaming, we will just detect a .xul file
> and act
> >> like it’s .xhtml. This is tracked in bug 1550801
> >> .
>
> There doesn't seem to be a bug on file listed in that tracking bug for
> actually doing the "detect a .xul file and act like it's .xhtml" bit. Is
> there one already on file?
>
> I think this step makes me the most nervous - we need to make sure that
> we don't change web-observable behaviour, and that the "no remote XUL"
> prohibitions continue to apply. In theory, that should all be fine
> because of XHTML and namespaces, but I figured it was worth flagging up.
>
> ~ 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: Change to preferences via StaticPrefs, tremoval of gfxPrefs

[Jonathan Kew]

Great to see this consolidation happening; it's going to be a great 
improvement on the current situation.


Just to check, would it be correct to assume this won't be landing on 
central until after the current Fx68 soft-freeze period? It seems like 
the sort of wide-ranging change that probably shouldn't be hitting the 
tree just now.


Thanks for cleaning things up for us!

JK

On 15/05/2019 14:02, Jean-Yves Avenard wrote:

Dear all.

/TLDR; Wherever you used to use gfxPrefs, soon you will have to use 
StaticPrefs./


In a couple of days, once /Bug 1550422 
//lands I will be 
retiring gfxPrefs. All features originally found in gfxPrefs are now 
available in StaticPrefs with some extra bonuses./




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

Re: Outline of a plan to remove all XUL documents from mozilla-central

[Gijs Kruitbosch]

On 14/05/2019 16:32, Brian Grinstead wrote:

1. Load all XUL documents as XHTML using the prototype cache. This
doesn’t require any file renaming, we will just detect a .xul file and act
like it’s .xhtml. This is tracked in bug 1550801
.


There doesn't seem to be a bug on file listed in that tracking bug for 
actually doing the "detect a .xul file and act like it's .xhtml" bit. Is 
there one already on file?


I think this step makes me the most nervous - we need to make sure that 
we don't change web-observable behaviour, and that the "no remote XUL" 
prohibitions continue to apply. In theory, that should all be fine 
because of XHTML and namespaces, but I figured it was worth flagging up.


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

Change to preferences via StaticPrefs, tremoval of gfxPrefs

[Jean-Yves Avenard]

Dear all.

/TLDR; Wherever you used to use gfxPrefs, soon you will have to use 
StaticPrefs./


In a couple of days, once /Bug 1550422 
//lands I will be 
retiring gfxPrefs. All features originally found in gfxPrefs are now 
available in StaticPrefs with some extra bonuses./


//For the background, StaticPrefs gives you the ability to access a 
preference via a thread-safe accessor.

//

/StaticPrefs and Preferences will now be available on all processes (not 
just main and content, this includes GPU, VR and RDD process)/


//

/3 levels of update policies: Skip, Once and Live:/

/* Skip policy will ignore all user overrides.
* Once will read the preference once and will never be updated again
* Live is the original behaviour, the values will be updated across all 
processes whenever the preference change.

/

/Possibility to dynamically set a StaticPref on any threads (however, 
the changes aren't propagated to other processes; doing otherwise is 
certainly doable, I'm not convinced of the use case however)./


/There are few more options, to know more I invite you to read the 
StaticPrefList.h file

/

/The desire to gfxPrefs came from yet another misuse of StaticPrefs in 
the GPU process. In addition gfxPrefs turned out to not be thread-safe./


/It became rather tiring to always juggle between gfxPrefs and 
StaticPrefs depending on which process the code could run./


/And as Mr MacLeod used to say: There can be only one/

/Jean-Yves
/

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

Re: Disabling the UINEEDED keyword

[Dão Gottwald]

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: Disabling the UINEEDED keyword

[Dão Gottwald]

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 :

> 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