Re: Moving away from autoconf

[Aaron Klotz]

Giggity

On 2/24/2016 3:28 PM, Mike Hommey wrote:

Hi,

We are, officially, and starting today with the landing of bug 1250294,
moving away from autoconf. This is not going to happen overnight, and it
is going to be painful, but the first step has just been made, and we're
not turning back.

The autoconf scripts are however still there and are used, but were
renamed to old-configure.in. If you have pending patches against
configure.in or js/src/configure.in, your changes will need to be
applied to old-configure.in or js/src/old-configure.in.

Cheers,

Mike
___
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: Moving away from autoconf

[Mike Hommey]

On Wed, Feb 24, 2016 at 03:38:35PM -0800, Ralph Giles wrote:
> Where do new changes go?

The answer to this question will change in the coming days, and vary
depending on what you want to change. Please ask build system peers.
I should have mentioned this in the original message, sorry.

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

Re: Moving away from autoconf

[Tom Schuster]

This is so great. Thank you!
On Feb 25, 2016 12:35 AM, "Mike Hommey"  wrote:

> Hi,
>
> We are, officially, and starting today with the landing of bug 1250294,
> moving away from autoconf. This is not going to happen overnight, and it
> is going to be painful, but the first step has just been made, and we're
> not turning back.
>
> The autoconf scripts are however still there and are used, but were
> renamed to old-configure.in. If you have pending patches against
> configure.in or js/src/configure.in, your changes will need to be
> applied to old-configure.in or js/src/old-configure.in.
>
> Cheers,
>
> Mike
> ___
> 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: Moving away from autoconf

[Ralph Giles]

Where do new changes go?

 -r

On Wed, Feb 24, 2016 at 2:28 PM, Mike Hommey  wrote:
> Hi,
>
> We are, officially, and starting today with the landing of bug 1250294,
> moving away from autoconf. This is not going to happen overnight, and it
> is going to be painful, but the first step has just been made, and we're
> not turning back.
>
> The autoconf scripts are however still there and are used, but were
> renamed to old-configure.in. If you have pending patches against
> configure.in or js/src/configure.in, your changes will need to be
> applied to old-configure.in or js/src/old-configure.in.
>
> Cheers,
>
> Mike
> ___
> 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

Moving away from autoconf

[Mike Hommey]

Hi,

We are, officially, and starting today with the landing of bug 1250294,
moving away from autoconf. This is not going to happen overnight, and it
is going to be painful, but the first step has just been made, and we're
not turning back.

The autoconf scripts are however still there and are used, but were
renamed to old-configure.in. If you have pending patches against
configure.in or js/src/configure.in, your changes will need to be
applied to old-configure.in or js/src/old-configure.in.

Cheers,

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

Re: HTML-based chrome and

[J. Ryan Stinnett]

We'll soon have access to  in desktop Firefox (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1238160).

I realize you are proposing a different API than mozbrowser, but I
just wanted to point out that there will be some HTML-based approach
for browser chrome available on desktop soon.

- Ryan

On Wed, Feb 24, 2016 at 2:19 PM, Benjamin Francis  wrote:
> Hi,
>
> I've been thinking about working towards deprecating "Open Web Apps" (aka
> mozApps
> )
> in Gecko.
>
> For the most part I think mozApps should eventually be replaced by
> standards-based web apps using Web Manifest, Service Workers etc. I'd love
> to see a standalone display mode for Firefox which supports these web apps
> on desktop and mobile to replace the now defunct web runtime, but that's
> not what this email is about.
>
> For the most privileged pieces of UI like the browser chrome of the
> browser.html project and the Firefox OS system app I think we may need
> another solution. I'd like us to be able to split Gaia
>  into chrome (the system pieces) and
> standard web content (everything else). (I'd also like to see a lot of the
> current mozApps-only DOM APIs become web services).
>
>- In the past we had XULRunner but this has recently been removed and it
>seems the continued use of XUL is being discouraged in favour of HTML.
>- There was an attempt at rebooting the Chromeless project
> but it looks like that was
>still based on XULRunner.
>- The browser.html  project
>currently uses Graphene
>
> ,
>a build of Gecko/Servo which runs locally hosted web content as browser
>chrome, but that's based on certified mozApps and the mozBrowser API.
>
> After chatting with members of the browser.html team I'd like to propose a
> solution inspired by Electron  (which they
> already proposed 
> before ). This would involve a
> new type of HTML-based chrome including a new  element.
>
> Kan-Ru previously did a comparison
>  of Mozilla's
> mozBrowser API, Google's  and Microsoft's  and I started
> to spec something out  with a view
> to potentially standardising this, but the web lacks the security model
> needed to expose this API and there's currently not much interest in a
> standard. So my proposal is a chrome-only  element for Gecko which
> would replace the mozApps-only mozBrowser API
> ,
> along the lines of Electron's  element
> , to allow you to
> safely embed web content in an application with HTML-based chrome.
>
> We could also potentially emulate other parts of Electron's APIs too, see
> their quick start tutorial
>  to get an idea
> of how their embedding works.
>
> Initially this would be used by the browser.html and Firefox OS projects,
> but I think it could be a possible route away from XUL for Firefox in the
> future too.
>
> I've chatted with a few people working on browser.html and Firefox OS about
> this, but I'd like to get broader feedback. Vivien told me he's already
> prototyping a similar solution  to
> the same problem so I'd like to kick off some discussion here about which
> direction we should take.
>
> Thanks
>
> Ben
> ___
> 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

HTML-based chrome and

[Benjamin Francis]

Hi,

I've been thinking about working towards deprecating "Open Web Apps" (aka
mozApps
)
in Gecko.

For the most part I think mozApps should eventually be replaced by
standards-based web apps using Web Manifest, Service Workers etc. I'd love
to see a standalone display mode for Firefox which supports these web apps
on desktop and mobile to replace the now defunct web runtime, but that's
not what this email is about.

For the most privileged pieces of UI like the browser chrome of the
browser.html project and the Firefox OS system app I think we may need
another solution. I'd like us to be able to split Gaia
 into chrome (the system pieces) and
standard web content (everything else). (I'd also like to see a lot of the
current mozApps-only DOM APIs become web services).

   - In the past we had XULRunner but this has recently been removed and it
   seems the continued use of XUL is being discouraged in favour of HTML.
   - There was an attempt at rebooting the Chromeless project
    but it looks like that was
   still based on XULRunner.
   - The browser.html  project
   currently uses Graphene
   
,
   a build of Gecko/Servo which runs locally hosted web content as browser
   chrome, but that's based on certified mozApps and the mozBrowser API.

After chatting with members of the browser.html team I'd like to propose a
solution inspired by Electron  (which they
already proposed 
before ). This would involve a
new type of HTML-based chrome including a new  element.

Kan-Ru previously did a comparison
 of Mozilla's
mozBrowser API, Google's  and Microsoft's  and I started
to spec something out  with a view
to potentially standardising this, but the web lacks the security model
needed to expose this API and there's currently not much interest in a
standard. So my proposal is a chrome-only  element for Gecko which
would replace the mozApps-only mozBrowser API
,
along the lines of Electron's  element
, to allow you to
safely embed web content in an application with HTML-based chrome.

We could also potentially emulate other parts of Electron's APIs too, see
their quick start tutorial
 to get an idea
of how their embedding works.

Initially this would be used by the browser.html and Firefox OS projects,
but I think it could be a possible route away from XUL for Firefox in the
future too.

I've chatted with a few people working on browser.html and Firefox OS about
this, but I'd like to get broader feedback. Vivien told me he's already
prototyping a similar solution  to
the same problem so I'd like to kick off some discussion here about which
direction we should take.

Thanks

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

cloud-mirror – Platform Engineering Operations Project of the Month

[John Ford]

Hello from Platform Engineering Operations! Once a month we highlight one
of our projects to help the Mozilla community discover a useful tool or an
interesting contribution opportunity. This month's project is our
cloud-mirror.

The cloud-mirror is something that we've written to reduce costs and time
of inter-region S3 transfers. Cloud-mirror was designed for use in the
Taskcluster system, but is possible to run independently. Taskcluster,
which is the new automation environment for Mozilla, can support passing
artifacts between dependent tasks. An example of this is that when we do a
build, we want to make the binaries available to the test machines. We
originally hosted all of our artifacts in a single AWS region. This meant
that every time a test was done in a region outside of the main region, we
would incur an inter-region transfer for each test run. This is expensive
and slow compared to in-region transfers.

We decided that a better idea would be to transfer the data from the main
region to the other regions the first time it was requested in that region
and then have all subsequent requests be inside of the region. This means
that for the small overhead of an extra in-region copy of the file, we lose
the cost and time overhead of doing inter-region transfers every single
time.

Here's an example. We use us-west-2 as our main region for storing
artifacts. A test machine in eu-central-1 requires "firefox-50.tar.bz2" for
use in a test. The test machine in eu-central-1 will ask cloud mirror for
this file. Since this is the first test to request this artifact in
eu-central-1, cloud mirror will first copy "firefox-50.tar.bz2" into
eu-central-1 then redirect to the copy of that file in eu-central-1. The
second test machine in eu-central-1 will then ask for a copy of
"firefox-50.tar.bz2" and because it's already in the region, the cloud
mirror will immediately redirect to the eu-central-1 copy.

We expire artifacts from the destination regions so that we don't incur too
high storage costs. We also use a redis cache configured to expire keys
which have been used least recently first. Cloud mirror is written with
Node 5 and uses Redis for storage. We use the upstream aws-sdk library for
doing our S3 operations.

We're in the process of deploying this system to replace our original
implementation called 's3-copy-proxy'. This earlier version was a much
simpler version of this idea which we've been using in production. One of
the main reasons for the rewrite was to be able to abstract the core
concepts to allow anyone to write a backend for their storage type as well
as being able to support more aws regions and move towards a completely
HTTPS based chain.

If this is a project that's interesting to you, we have lots of ways that
you could contribute! Here are some:


   - switch polling for pending copy operations to use redis's pub/sub
   features
   - write an Azure or GCE storage backend
   - Modify the API to determine which cloud storage pool a request should
   be redirected to instead of having to encode that into the route
   - Write a localhost storage backend for testing that serves content on
   127.0.0.1


If you have any ideas or find some bugs in this system, please open an issue
https://github.com/taskcluster/cloud-mirror/issues. For the time being, you
will need to have an AWS account to run our integration tests (`npm test`).
We would love to have a storage backend that allows running the non-service
specific portions of the system without any extra permissions.

If you're interested in contributing, please ping me (jhford) in
#taskcluster on irc.mozilla.org.

For more information about all Platform Ops projects, visit our wiki. If
you're interested in helping out,
http://ateam-bootcamp.readthedocs.org/en/latest/guide/index.html has
resources for getting started.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform