Re: build complexity vs kbuild

[Enrico Weigelt, metux IT consult]

On 23.07.2017 01:19, Gregory Szorc wrote:


Yes, the build system is complex. It has evolved organically for over 20
years, accumulating tons of cruft and complexity along the way. Much of
the existing complexity can be simplified.


Yeah, I'm already trying some experiments here. IMHO, the underlying
problem is the lack of an strict moduarity (lots of interdependencies
between different areas - media stuff is one example).


Kbuild is not a viable long-term solution because it is tied to Make,


Sorry, I was a bit imprecise. I'm thinking of Kconfig. And this is
quite independent of the actual build system.

OTOH, even for large project I'm usually fine w/ plain (g)make.
But my projects tend to be strictly modularized, and I take care that
they don't grow so huge in the first place.

I believe, we could reduce the (actually used) mozilla source size
radically and make things much easier. There's a also lot that wouldn't
like to have in the browser itself, but entirely separate programs.
Well, that's another story ...

By the way: I've read some rumors that the whole b2g stuff is going
to be dropped - is that correct ?


Bazel is one such modern tool.


hmm, according to the intro, looks pretty much like something I did
over 15 years ago (it was called "treebuild", as it modeled the whole
project in a tree structure) ... suggested it to several large projects
like moz, ooffice, etc - the reaction were, hmm, not entirely friendly.


By the way: xorg/xf86 used to have similar problems (anyone still
remembers xmkmf ? *b*), but due to modularization, things became
quite simple today (okay, Xserver itself is still ugly, but's a whole
story of its own :o).

That's the way I would like to go.


--mtx

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

Re: git mirror

[Kartikaya Gupta]

https://github.com/mozilla/gecko-dev is generally pretty up-to-date. It
should have a branch for ESR as well.

Cheers,
kats

On Jul 22, 2017 15:43, "Enrico Weigelt, metux IT consult" <
enrico.weig...@gr13.net> wrote:

Hi folks,


are there any official git mirrors (at least for the esr branches),
that are regularily updated ?

The repos is *really* huge - import really takes a long time (started
about 10hrs ago, still just not much over 10%). Github even gives up.
Even hg clone runs for hours.

I'm looking for an git repo, where I can do a (shallow) clone from,
that also receives updates from the hg master.


thx

-- 

mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
___
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: build complexity vs kbuild

[Gregory Szorc]

On Sat, Jul 22, 2017 at 1:11 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> Hi folks,
>
>
> the whole build seems to be very complex.
>
> Not just the huge configure.in, but also the complexity in moz.build
> files, many ifdef's, etc, etc. Many orthogonal things are twisted
> together (eg. widget toolkits influence lots of other things)
>
> I'm thinking of having a deeper look at Kbuild. It's really nice to
> handle complex dependencies. In the kernel we also use that for
> automatically switch hidden settings by higher level ones
> (eg. combination of a and b can activate c, certain things automatically
> happen based on platform/cpu type, etc, etc.
>
> Could it be an option for moz ?
>

Yes, the build system is complex. It has evolved organically for over 20
years, accumulating tons of cruft and complexity along the way. Much of the
existing complexity can be simplified. In fact, the build system today with
moz.build files is much simpler than it was 5 years ago.

Kbuild is not a viable long-term solution because it is tied to Make, which
has fundamental shortcomings that make it not suitable for large, complex,
and cross-platform projects like Firefox. The future of the build system
will involve tools that incorporate modern technologies and wisdom and
don't have their underpinnings based on 1970's technology (like Make does).
Bazel is one such modern tool.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: removing "the old way" of signing add-ons

[Andrew Swan]

On Fri, Jul 21, 2017 at 12:32 AM, Jörg Knobloch  wrote:

> Since you're saying that we're still using the old interface, in fact
> Andrew said: "old add-on install
> confirmation dialog, that dialog includes a note about the certificate",
> would you be able to give us some exact DXR references which would save us
> a lot of searching.
>

The dialog I mentioned is:
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallConfirm.xul

The listbox in that dialog holds instances of:
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallItem.xml

The label in those items with the class "xpinstallItemSigned" ends up
holding either certificate details or some default message like "Author not
verified"

While we're on the topic, Thunderbird and Seamonkey should look at moving
over to the doorhanger addon install flow that Firefox uses -- that xul
dialog and everything that supports it are unused in Firefox and its days
are numbered.

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

Re: Keyboard APZ has landed on Inbound

[Ryan Hunt]

> Just curious, is there data about how often this happens? Does it affect
> to key event listeners added to the document only, or do we disable this
> also for other event listeners in any element?

I'm not aware of any data on this. From my testing, it can be quite common.

We disable this when there are keydown, keypress, keyup listeners that would
be triggered by a key event. So when nothing is focused we check for listeners
on the document. If the focus is on an element, we check for key listeners up to
and on the element.

> Also, I assume this affects only to keypress events? Or also to other
> kind of key events?

This affects the other kinds of key events too.

For keyboard APZ we need to track the focus/selection of a page in order to
know what frame to scroll. This can change at any moment from JS. Either
in response to user input with event listeners, or at any other moment in
setTimeout or rAF.

We made the decision to be conservative and respect
synchronous changes in response to user input, but not from setTimeout
and rAF. So to do this we need to use the synchronous code path when
there are key event listeners.

> Also, is bug 1352654 the right tracking bug? Doesn't seem related at a
> glance.

Whoops, the correct tracking bug is bug 1376525. Copied the wrong one.

From: dev-platform  on 
behalf of Emilio Cobos Álvarez 
Sent: Saturday, July 22, 2017 12:43:31 PM
To: Ryan Hunt; dev-platform@lists.mozilla.org
Subject: Re: Keyboard APZ has landed on Inbound

On 07/22/2017 08:05 AM, Ryan Hunt wrote:
> Keyboard APZ can't be used in every case. Currently it's disabled in the
> presense of key event listeners, as they can preventDefault scrolling and that
> is a non-negotiable part of the web.

Just curious, is there data about how often this happens? Does it affect
to key event listeners added to the document only, or do we disable this
also for other event listeners in any element?

Also, I assume this affects only to keypress events? Or also to other
kind of key events?

I would expect quite a few pages to use them...

> There may be issues with this enabled. Please test this out, and if you find
> any regressions please file bugs blocking bug 1352654.

Also, is bug 1352654 the right tracking bug? Doesn't seem related at a
glance.

 -- Emilio
___
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

build complexity vs kbuild

[Enrico Weigelt, metux IT consult]

Hi folks,


the whole build seems to be very complex.

Not just the huge configure.in, but also the complexity in moz.build
files, many ifdef's, etc, etc. Many orthogonal things are twisted
together (eg. widget toolkits influence lots of other things)

I'm thinking of having a deeper look at Kbuild. It's really nice to
handle complex dependencies. In the kernel we also use that for
automatically switch hidden settings by higher level ones
(eg. combination of a and b can activate c, certain things automatically
happen based on platform/cpu type, etc, etc.

Could it be an option for moz ?


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

Re: git mirror

[Enrico Weigelt, metux IT consult]

On 22.07.2017 19:49, Jörg Knobloch wrote:

On 22/07/2017 21:42, Enrico Weigelt, metux IT consult wrote:

Even hg clone runs for hours.


Best to use a bundle:

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial/Bundles


according to hg output, it already uses them.

(devuan)nekrad@orion:~/src/thunderbird/hg$ hg clone 
https://hg.mozilla.org/releases/mozilla-esr52/

destination directory: mozilla-esr52
applying clone bundle from 
https://hg.cdn.mozilla.net/releases/mozilla-esr52/5dd82ab194b9f8c82b94cbf20e2dc5f1975b2788.gzip-v2.hg

adding changesets
adding manifests 

adding file changes 

files 
[> 
  ] 200892/269670 14m50s


Same for git side. But the bottleneck seems to be importing the bundle
into local repo (git import is magnitudes slower, probably because it
has to process rev by rev).

--mtx

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

make media stuff optional

[Enrico Weigelt, metux IT consult]

Hi folks,


I'm trying to build tbird with minimal dependencies, and therefore
switched off various codecs. Unfortunately it causes the whole
media stuff to break.

As I don't need that at all in the mail client, I've added ifdefs
to disable it (introducing a new MOZ_MEDIA flag). Unfortunately
idl compiler doesnt seem to support ifdef's, but several idl's
directly reference media stuff.


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

Re: git mirror

[Jörg Knobloch]

On 22/07/2017 21:42, Enrico Weigelt, metux IT consult wrote:
Even hg clone runs for hours. 


Best to use a bundle:

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial/Bundles

Jörg.

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

git mirror

[Enrico Weigelt, metux IT consult]

Hi folks,


are there any official git mirrors (at least for the esr branches),
that are regularily updated ?

The repos is *really* huge - import really takes a long time (started
about 10hrs ago, still just not much over 10%). Github even gives up.
Even hg clone runs for hours.

I'm looking for an git repo, where I can do a (shallow) clone from,
that also receives updates from the hg master.


thx

--

mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

IDL vs ifdef

[Enrico Weigelt, metux IT consult]

Hi folks,


I'm currently in process of making the media stuff optional.
(dont need/want it within mail client).

Unfortunately, it idl files are referenced by lot of others.
Just adding some #ifdef's around these places doesn't work.

Any idea to achieve this ?


--mtx


mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Keyboard APZ has landed on Inbound

[Emilio Cobos Álvarez]

On 07/22/2017 08:05 AM, Ryan Hunt wrote:
> Keyboard APZ can't be used in every case. Currently it's disabled in the
> presense of key event listeners, as they can preventDefault scrolling and that
> is a non-negotiable part of the web.

Just curious, is there data about how often this happens? Does it affect
to key event listeners added to the document only, or do we disable this
also for other event listeners in any element?

Also, I assume this affects only to keypress events? Or also to other
kind of key events?

I would expect quite a few pages to use them...

> There may be issues with this enabled. Please test this out, and if you find
> any regressions please file bugs blocking bug 1352654.

Also, is bug 1352654 the right tracking bug? Doesn't seem related at a
glance.

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

Re: Announcing MozillaBuild 3.0 Release

[Ryan VanderMeulen]

It does not use msys2. Those plans were dropped in favor of WSL.

On Sat, Jul 22, 2017 at 5:03 AM, 施賀傑  wrote:

> Thanks for the new version of mozbuild!
>
> Is it including msys2? Then, it will be easier to include the
> bash-completion.
>
> -Jerry
>
> > On 22 Jul 2017, at 06:02, Ryan VanderMeulen 
> wrote:
> >
> > I am pleased to announce the final release of MozillaBuild 3.0! Sorry in
> > advance for the length of this message, but there's a lot of changes in
> > this release worth calling out.
> >
> > https://ftp.mozilla.org/pub/mozilla/libraries/win32/
> MozillaBuildSetup-Latest.exe
> >  MozillaBuildSetup-Latest.exe>
> >
> > Important changes since version 2.2.0:
> >
> >   -
> >
> >   MozillaBuild now requires Windows 7+ 64-bit to install.
> >   -
> >
> >   Removed the start-shell-msvc*.bat files. See below for more information
> >   on this change.
> >   -
> >
> >   Updated Python to version 2.7.13 and switched to the 64-bit version.
> >   -
> >
> >   Added Python 3.6.2.
> >   -
> >
> >   Added nodejs 8.1.4 & npm 5.3.0.
> >   -
> >
> >  ESLint is now a first-class citizen on Windows! Things should Just
> >  Work when using the |./mach eslint| command.
> >  -
> >
> >   Other updates to various included components.
> >   -
> >
> >  Mercurial updated to version 4.2.2.
> >  -
> >
> >  NSIS updated to version 3.01 (and older versions removed).
> >  -
> >
> >  Some MSYS components were updated.
> >  -
> >
> >   Behind the scenes, MozillaBuild packaging was completely overhauled so
> >   that anyone can now generate an installer package simply by running the
> >   packageit.py script from the source checkout. This should in turn make
> it
> >   much easier for new contributors to test their work.
> >
> >
> > Full changelog:
> >
> > https://hg.mozilla.org/mozilla-build/pushloghtml?
> fromchange=MOZILLABUILD_2_2_0_RELEASE=MOZILLABUILD_3_0_0_RELEASE
> >  fromchange=MOZILLABUILD_2_2_0_RELEASE=MOZILLABUILD_3_0_0_RELEASE>
> >
> > It is strongly advised that you not install this over a previous
> > installation!
> >
> > Upgrade instructions:
> >
> >   1.
> >
> >   Pull down and update to a modern revision of any trunk repo
> >   (mozilla-central, inbound, or autoland).
> >   2.
> >
> >   Run |./mach mercurial-setup --update-only| to ensure the
> >   version-control-tools repository is current. Extension bustage after
> >   upgrade is likely if you don’t do this.
> >   3.
> >
> >   Run |./mach clobber| to remove the object directory of any trees you
> >   have. Build errors are pretty much guaranteed to occur otherwise.
> >   4.
> >
> >   Assuming you’ve previously installed Rust via |./mach bootstrap|,
> backup
> >   msys/etc/profile.d/profile-rustup.sh from your current MozillaBuild
> >   installation.
> >   5.
> >
> >   Remove your current installation. If you can't remove the existing
> >   installation, you probably have a terminal open or ssh-agent running.
> >   Terminate it and try again.
> >   6.
> >
> >   Install MozillaBuild 3.0.
> >   7.
> >
> >   Copy profile-rustup.sh to your new msys/etc/profile.d directory. You
> can
> >   also just re-run |./mach bootstrap| if you don’t want to deal with
> copying
> >   files around.
> >   8.
> >
> >   If you previously enabled minTTY, you will need to do so again by
> >   setting USE_MINTTY=1 at the top of start-shell.bat.
> >
> >
> > Please file any problems you come across in mozilla.org::MozillaBuild.
> >
> > Where did start-shell-msvc*.bat go?
> >
> > Since the release of MozillaBuild 2.2.0, much has changed with how we
> build
> > Firefox and in how Microsoft distributes their compiler and SDK
> toolchains.
> > In order to make things more flexible for both our build automation as
> well
> > as people building locally, MSVC and Platform SDK detection was moved
> into
> > the build system where it’s now detected when configure runs. Both MSVC
> > 2015 and 2017 detection is supported, as well as Windows SDK 8.1+.
> >
> > If you have both MSVC 2015 and 2017 installed, 2017 will be chosen by
> > default. This can be overridden by adding the following line to your
> > mozconfig
> >  Instructions/Configuring_Build_Options>
> > :
> >
> > ac_add_options --with-visual-studio-version=2015
> >
> > Windows builds currently default to 32-bit. This can cause problems with
> a
> > mismatched Rust toolchain because it’ll try to use the 64-bit one by
> > default and then error out. To create a 64-bit build instead, add the
> > following two lines to your mozconfig:
> >
> > ac_add_options --host=x86_64-pc-mingw32
> >
> > ac_add_options --target=x86_64-pc-mingw32
> >
> > Otherwise, you’ll need to manually install the i686 toolchain by running
> > the |rustup install stable-i686-pc-windows-msvc| command.
> >
> > If you 

Re: Announcing MozillaBuild 3.0 Release

[施賀傑]

Thanks for the new version of mozbuild!

Is it including msys2? Then, it will be easier to include the bash-completion.

-Jerry

> On 22 Jul 2017, at 06:02, Ryan VanderMeulen  wrote:
> 
> I am pleased to announce the final release of MozillaBuild 3.0! Sorry in
> advance for the length of this message, but there's a lot of changes in
> this release worth calling out.
> 
> https://ftp.mozilla.org/pub/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe
> 
> 
> Important changes since version 2.2.0:
> 
>   -
> 
>   MozillaBuild now requires Windows 7+ 64-bit to install.
>   -
> 
>   Removed the start-shell-msvc*.bat files. See below for more information
>   on this change.
>   -
> 
>   Updated Python to version 2.7.13 and switched to the 64-bit version.
>   -
> 
>   Added Python 3.6.2.
>   -
> 
>   Added nodejs 8.1.4 & npm 5.3.0.
>   -
> 
>  ESLint is now a first-class citizen on Windows! Things should Just
>  Work when using the |./mach eslint| command.
>  -
> 
>   Other updates to various included components.
>   -
> 
>  Mercurial updated to version 4.2.2.
>  -
> 
>  NSIS updated to version 3.01 (and older versions removed).
>  -
> 
>  Some MSYS components were updated.
>  -
> 
>   Behind the scenes, MozillaBuild packaging was completely overhauled so
>   that anyone can now generate an installer package simply by running the
>   packageit.py script from the source checkout. This should in turn make it
>   much easier for new contributors to test their work.
> 
> 
> Full changelog:
> 
> https://hg.mozilla.org/mozilla-build/pushloghtml?fromchange=MOZILLABUILD_2_2_0_RELEASE=MOZILLABUILD_3_0_0_RELEASE
> 
> 
> It is strongly advised that you not install this over a previous
> installation!
> 
> Upgrade instructions:
> 
>   1.
> 
>   Pull down and update to a modern revision of any trunk repo
>   (mozilla-central, inbound, or autoland).
>   2.
> 
>   Run |./mach mercurial-setup --update-only| to ensure the
>   version-control-tools repository is current. Extension bustage after
>   upgrade is likely if you don’t do this.
>   3.
> 
>   Run |./mach clobber| to remove the object directory of any trees you
>   have. Build errors are pretty much guaranteed to occur otherwise.
>   4.
> 
>   Assuming you’ve previously installed Rust via |./mach bootstrap|, backup
>   msys/etc/profile.d/profile-rustup.sh from your current MozillaBuild
>   installation.
>   5.
> 
>   Remove your current installation. If you can't remove the existing
>   installation, you probably have a terminal open or ssh-agent running.
>   Terminate it and try again.
>   6.
> 
>   Install MozillaBuild 3.0.
>   7.
> 
>   Copy profile-rustup.sh to your new msys/etc/profile.d directory. You can
>   also just re-run |./mach bootstrap| if you don’t want to deal with copying
>   files around.
>   8.
> 
>   If you previously enabled minTTY, you will need to do so again by
>   setting USE_MINTTY=1 at the top of start-shell.bat.
> 
> 
> Please file any problems you come across in mozilla.org::MozillaBuild.
> 
> Where did start-shell-msvc*.bat go?
> 
> Since the release of MozillaBuild 2.2.0, much has changed with how we build
> Firefox and in how Microsoft distributes their compiler and SDK toolchains.
> In order to make things more flexible for both our build automation as well
> as people building locally, MSVC and Platform SDK detection was moved into
> the build system where it’s now detected when configure runs. Both MSVC
> 2015 and 2017 detection is supported, as well as Windows SDK 8.1+.
> 
> If you have both MSVC 2015 and 2017 installed, 2017 will be chosen by
> default. This can be overridden by adding the following line to your
> mozconfig
> 
> :
> 
> ac_add_options --with-visual-studio-version=2015
> 
> Windows builds currently default to 32-bit. This can cause problems with a
> mismatched Rust toolchain because it’ll try to use the 64-bit one by
> default and then error out. To create a 64-bit build instead, add the
> following two lines to your mozconfig:
> 
> ac_add_options --host=x86_64-pc-mingw32
> 
> ac_add_options --target=x86_64-pc-mingw32
> 
> Otherwise, you’ll need to manually install the i686 toolchain by running
> the |rustup install stable-i686-pc-windows-msvc| command.
> 
> If you run into any problems with MSVC or Windows SDK detection, please
> file a bug in Core::Build Config.
> 
> Thanks for reading and enjoy!
> 
> -Ryan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list

Re: Announcing MozillaBuild 3.0 Release

[Frank-Rainer Grahl]

Personally I find this a bad idea. Windows 7 and 8.1 are still supported till 
2020 and 2023. As long as the compilers are supported too on them these should 
also be fully supported as a build environment. Windows 10 is buggy and worse 
than 8.1 in many aspects.  I usually do not wear a tin head but the data 
siphoning Microsoft is doing and which can't be disabled on non enterprise 
versions together with the other "features" like forced updates of the OS 
every once in a while makes it unsuiteable for my use. I could have smashed 
something when after a Windows 10 Pro install 8 GB of useless game demos where 
downloaded and presented to me. And that is not the only example. I never 
thought I would prefer 8.1 over anything but this is currently the case. Not 
sure what I do after 2023 but probably switch to Linux and run anything I need 
Windows for in a vm.

FRG

Gregory Szorc wrote:

Thanks for all your work on this, Ryan!

So everyone knows, this is hopefully the last major overhaul of
MozillaBuild.

The plan from build system land is to attempt to go "all in" on Windows
Subsystem for Linux (WSL). That's the feature in Windows 10 (and even in
Server additions now) that implements Linux syscalls inside the Windows
kernel and allows you to run Linux binaries "natively" on Windows. The
performance is pretty good and it is a better Linux-on-Windows approach
than msys ever will be. Assuming we can pull it off, the goal is to ditch
MozillaBuild and support building Firefox from WSL. You'll then be able to
develop on Windows from the comfort of a Linux command line with access to
the full power of your favorite Linux distro. We will likely maintain some
support for building in non-WSL environments for automation, etc. But for
the average developer, we want to focus on WSL because we perceive that to
be the best opportunity for a more pleasant development experience on
Windows.






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

Keyboard APZ has landed on Inbound

[Ryan Hunt]

The patch to enable async keyboard scrolling in nightly (for all platforms
except Android) has landed on inbound.

Once this is merged to central, key scrolling will be done by the compositor
instead of on the main thread in most cases. This should bring the
responsiveness of key scrolling in line with other input methods like mouse
wheel, scroll bar, and touch dragging which have already converted to APZ.

Keyboard APZ can't be used in every case. Currently it's disabled in the
presense of key event listeners, as they can preventDefault scrolling and that
is a non-negotiable part of the web.

There may be issues with this enabled. Please test this out, and if you find
any regressions please file bugs blocking bug 1352654.

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