Re: Intent to ship: Service Workers with FetchEvent

2015-12-01 Thread Ehsan Akhgari 
To close the loop here, I just enabled service workers on Firefox 44
(currently on Aurora.)

Thanks to everyone who helped make this happen.  It was a lng ride.  :-)

On Fri, Nov 20, 2015 at 5:24 PM, Robert O'Callahan 
wrote:

> On Sat, Nov 21, 2015 at 9:42 AM, Ben Kelly  wrote:
>
> > I think the best thing we can do right now is get a second implementation
> > into wide circulation.  This will highlight compat issues yes, but also
> > help avoid baking chrome specific behavior into all the sites using
> service
> > workers.
> >
>
> Yes. This is incredibly important. Just look at the messaging in
>
> http://recode.net/2015/11/09/indias-flipkart-google-launch-chrome-mobile-website-replicate-apps/
>
> Rob
> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



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

Faster Windows builds everywhere!

2015-12-01 Thread Chris AtLee 
A few weeks ago I posted about switching our Windows builds on Try over to
EC2, resulting in a 30 minute speed improvement.

Last week we made the same change to the rest of the Windows build
infrastructure. All our Windows builds are now running in AWS. We're seeing
good performance gains there too. On mozilla-inbound, we've reduced opt
build times by at least 45 minutes, and nearly two hours (!!) off of our
PGO build times.

Big thanks again to Rob Thijssen (:grenade), Mark Cornmesser (:markco) and
the rest of our Release Engineering and Operations team for getting this
done. Please send your kudos and thanks to them on #releng, or in person at
Orlando next week!

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

Re: Faster Windows builds everywhere!

2015-12-01 Thread Justin Dolske 

On 12/1/15 12:41 PM, Chris AtLee wrote:


Last week we made the same change to the rest of the Windows build
infrastructure. All our Windows builds are now running in AWS. We're seeing
good performance gains there too. On mozilla-inbound, we've reduced opt
build times by at least 45 minutes, and nearly two hours (!!) off of our
PGO build times.


Nice!

What builds/tests have _not_ moved to the cloud? AIUI the two biggies 
are OS X (can't move because OS licensing), and perf tests... How close 
are we to transitioning everything else off MoCo metal?


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

Re: Faster Windows builds everywhere!

2015-12-01 Thread Chris AtLee 
Right now we've got debug OSX builds in the cloud on Try in parallel with
the regular builds. There's a bunch more work to be done there to be able
to switch over, but we're definitely making progress.

All Windows / OSX unit tests are currently done on our own infra. Q Fortier
is working on getting Windows unittests stood up in AWS, and the results
are very promising. I'm not sure when we'll be able to switch over yet
though. There are no obvious solutions for OSX test infrastructure other
than maintaining our own racks of minis.

Perf tests on all platforms will stay on hardware for now. Some people have
done experiments on EC2 to see how talos performs, but I don't think we
know enough about the impact of this to decide if we can move these off
bare metal or not.

We also run some tests for mobile on panda boards, but those are going away
eventually.

On Tue, Dec 1, 2015 at 4:52 PM, Justin Dolske  wrote:

> On 12/1/15 12:41 PM, Chris AtLee wrote:
>
> Last week we made the same change to the rest of the Windows build
>> infrastructure. All our Windows builds are now running in AWS. We're
>> seeing
>> good performance gains there too. On mozilla-inbound, we've reduced opt
>> build times by at least 45 minutes, and nearly two hours (!!) off of our
>> PGO build times.
>>
>
> Nice!
>
> What builds/tests have _not_ moved to the cloud? AIUI the two biggies are
> OS X (can't move because OS licensing), and perf tests... How close are we
> to transitioning everything else off MoCo metal?
>
> Justin
>
> ___
> 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: Faster Windows builds everywhere!

2015-12-01 Thread Chris AtLee 
On Tue, Dec 1, 2015 at 5:27 PM, Gregory Szorc  wrote:

>
> On Tue, Dec 1, 2015 at 2:21 PM, Chris AtLee  wrote:
>
>> Right now we've got debug OSX builds in the cloud on Try in parallel with
>> the regular builds. There's a bunch more work to be done there to be able
>> to switch over, but we're definitely making progress.
>>
>> All Windows / OSX unit tests are currently done on our own infra. Q
>> Fortier
>> is working on getting Windows unittests stood up in AWS, and the results
>> are very promising. I'm not sure when we'll be able to switch over yet
>> though. There are no obvious solutions for OSX test infrastructure other
>> than maintaining our own racks of minis.
>>
>> Perf tests on all platforms will stay on hardware for now. Some people
>> have
>> done experiments on EC2 to see how talos performs, but I don't think we
>> know enough about the impact of this to decide if we can move these off
>> bare metal or not.
>>
>
> Amazon now supports dedicated instances, which means you fully control
> what runs on the machine and other random tenants aren't fighting you for
> CPU and I/O. Assuming the performance variance from other tenants is what
> was preventing us from moving Talos to AWS, that blocker may no longer
> exist.
>

I think you probably want Dedicated Hosts rather than dedicated instances,
otherwise multiple of your own workloads could end up on the same physical
box I think. https://aws.amazon.com/ec2/dedicated-hosts/

I have two main concerns with dedicated infra on AWS:
* You're still running under a hypervisor of some kind; will it introduce
too much noise into the results? Seems like a worthwhile experiment!

* Dedicated host pricing is quite a bit more expensive than what we're
paying now for test infrastructure.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster Windows builds everywhere!

2015-12-01 Thread Gregory Szorc 
On Tue, Dec 1, 2015 at 2:21 PM, Chris AtLee  wrote:

> Right now we've got debug OSX builds in the cloud on Try in parallel with
> the regular builds. There's a bunch more work to be done there to be able
> to switch over, but we're definitely making progress.
>
> All Windows / OSX unit tests are currently done on our own infra. Q Fortier
> is working on getting Windows unittests stood up in AWS, and the results
> are very promising. I'm not sure when we'll be able to switch over yet
> though. There are no obvious solutions for OSX test infrastructure other
> than maintaining our own racks of minis.
>
> Perf tests on all platforms will stay on hardware for now. Some people have
> done experiments on EC2 to see how talos performs, but I don't think we
> know enough about the impact of this to decide if we can move these off
> bare metal or not.
>

Amazon now supports dedicated instances, which means you fully control what
runs on the machine and other random tenants aren't fighting you for CPU
and I/O. Assuming the performance variance from other tenants is what was
preventing us from moving Talos to AWS, that blocker may no longer exist.


>
> We also run some tests for mobile on panda boards, but those are going away
> eventually.
>
> On Tue, Dec 1, 2015 at 4:52 PM, Justin Dolske  wrote:
>
> > On 12/1/15 12:41 PM, Chris AtLee wrote:
> >
> > Last week we made the same change to the rest of the Windows build
> >> infrastructure. All our Windows builds are now running in AWS. We're
> >> seeing
> >> good performance gains there too. On mozilla-inbound, we've reduced opt
> >> build times by at least 45 minutes, and nearly two hours (!!) off of our
> >> PGO build times.
> >>
> >
> > Nice!
> >
> > What builds/tests have _not_ moved to the cloud? AIUI the two biggies are
> > OS X (can't move because OS licensing), and perf tests... How close are
> we
> > to transitioning everything else off MoCo metal?
> >
> > Justin
> >
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using the Taskcluster index to find builds

2015-12-01 Thread Chris AtLee 
One approach we've taken when considering changes to the routes used is to
play in the 'garbage.' prefix. You can see the results of earlier
experiments there:

https://tools.taskcluster.net/index/#garbage/garbage

Regarding your proposal, I find the word 'nightly' overloaded, and it needs
more context to make sense. There are lots of 'nightly' builds, but only
one 'nightly' channel (for Firefox anyway). So
"gecko.v2.firefox.win64-opt.nightly.latest" isn't clear to me at first
glance.

I'm curious what others think though.

On Tue, Dec 1, 2015 at 11:46 AM, Julien Wajsberg 
wrote:

> hi,
>
> Because we have an index, it's now very easy to add new routes. I think
> it would be a lot more user-friendly to have an index that starts with
> the product name ("firefox" for example).
>
> For example: "gecko.v2.firefox.win64-opt.nightly.latest" instead of
> "gecko.v2.mozilla-central.nightly.latest.firefox.win64-opt
> <
> https://tools.taskcluster.net/index/artifacts/#gecko.v2.mozilla-central.nightly.latest.firefox/gecko.v2.mozilla-central.nightly.latest.firefox.win64-opt
> >".
> Going from the most general to the most specific.
> Using an index that starts with "mozilla-central" is really technical
> and does not make things easy to find :/ Even if it can be good for
> automated tools.
>
> Fortunately now it's not either one or the other, we can have both. But
> before filing a bug, I'd like to know if the general population thinks
> it's a good idea.
>
> --
> Julien
>
> Le 30/11/2015 21:43, Chris AtLee a écrit :
> > The RelEng, Cloud Services and Taskcluster teams have been doing a lot of
> > work behind the scenes over the past few months to migrate the backend
> > storage for builds from the old "FTP" host to S3. While we've tried to
> make
> > this as seamless as possible, the new system is not a 100% drop-in
> > replacement for the old system, resulting in some confusion about where
> to
> > find certain types of builds.
> >
> > At the same time, we've been working on publishing builds to the
> > Taskcluster Index [1]. This service provides a way to find a build given
> > various different attributes, such as its revision or date it was built.
> > Our plan is to make the index be the primary mechanism for discovering
> > build artifacts. As part of the ongoing buildbot to Taskcluster migration
> > project, builds happening on Taskcluster will no longer upload to
> > https://archive.mozilla.org (aka https://ftp.mozilla.org). Once we shut
> off
> > platforms in buildbot, the index will be the only mechanism for
> discovering
> > new builds.
> >
> > I posted to planet Mozilla last week [2] with some more examples and
> > details. Please explore the index, and ask questions about how to find
> what
> > you're looking for!
> >
> > Cheers,
> > Chris
> >
> > [1] http://docs.taskcluster.net/services/index/
> > [2]
> http://atlee.ca/blog/posts/firefox-builds-on-the-taskcluster-index.html
> > ___
> > 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
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: FIDO U2F API

2015-12-01 Thread Richard Barnes 
The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1].  Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to create open standards using FIDO as a starting
point. We are proposing to implement the FIDO U2F API in Firefox in its
current form and then track the evolving W3C standard.

Background: The FIDO Alliance has been developing a standard for
hardware-based user authentication known as “Universal Two-Factor” or U2F
[2].  This standard allows a website to verify that a user is in possession
of a specific device by having the device sign a challenge with a private
key that is held on the hardware device.  The browser’s role is mainly (1)
to route messages between the website and the token, and (2) to add the
origin of the website to the message signed by the token (so that the
signature is bound to the site).

Several major websites now support U2F for authentication, including Google
[3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
for U2F support in Gecko [6].  The W3C has  begun the process of forming a
“WebAuthentication” working group that will work on a standard for enhanced
authentication using FIDO as a starting point [7].

Proposed: To implement the high-level U2F API described in the FIDO JS API
specification, with support for the USB HID token interface.

Please send comments on this proposal to the list no later than Monday,
December 14, 2015.

-

Personally, I have some reservations about implementing this, but I still
think it’s worth doing, given the clear need for something to augment
passwords.

It’s unfortunate that the initial FIDO standards were developed in a closed
group, but there is good momentum building toward making FIDO more open.  I
have some specific concerns about the U2F API itself, but they’re
relatively minor.  For example, the whole system is highly vertically
integrated, so if we want to change any part of it (e.g., to use a curve
other than P-256 for signatures), we’ll need to build a whole new API.  But
these are issues that can be addressed in the W3C process.

We will continue to work on making standards for secure authentication more
open.  In the meantime, U2F is what’s here now, and there’s demonstrated
developer interest, so it makes sense for us to work on implementing it.

Thanks,
--Richard

[1] https://fidoalliance.org/
[2] https://fidoalliance.org/specifications/download/
[3] https://support.google.com/accounts/answer/6103523?hl=en
[4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
[5]
https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
[7] http://w3c.github.io/websec/web-authentication-charter
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-01 Thread Jonas Sicking 
Any chance that the API can be made a little more JS friendly? First
thing that stands out is the use of success/error callbacks rather
than the use of Promises.

Also the use of numeric codes, rather than string values, is a pattern
that the web has generally moved away from.

/ Jonas

On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes  wrote:
> The FIDO Alliance has been developing standards for hardware-based
> authentication of users by websites [1].  Their work is getting significant
> traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
> Work has begun in the W3C to create open standards using FIDO as a starting
> point. We are proposing to implement the FIDO U2F API in Firefox in its
> current form and then track the evolving W3C standard.
>
> Background: The FIDO Alliance has been developing a standard for
> hardware-based user authentication known as “Universal Two-Factor” or U2F
> [2].  This standard allows a website to verify that a user is in possession
> of a specific device by having the device sign a challenge with a private
> key that is held on the hardware device.  The browser’s role is mainly (1)
> to route messages between the website and the token, and (2) to add the
> origin of the website to the message signed by the token (so that the
> signature is bound to the site).
>
> Several major websites now support U2F for authentication, including Google
> [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
> for U2F support in Gecko [6].  The W3C has  begun the process of forming a
> “WebAuthentication” working group that will work on a standard for enhanced
> authentication using FIDO as a starting point [7].
>
> Proposed: To implement the high-level U2F API described in the FIDO JS API
> specification, with support for the USB HID token interface.
>
> Please send comments on this proposal to the list no later than Monday,
> December 14, 2015.
>
> -
>
> Personally, I have some reservations about implementing this, but I still
> think it’s worth doing, given the clear need for something to augment
> passwords.
>
> It’s unfortunate that the initial FIDO standards were developed in a closed
> group, but there is good momentum building toward making FIDO more open.  I
> have some specific concerns about the U2F API itself, but they’re
> relatively minor.  For example, the whole system is highly vertically
> integrated, so if we want to change any part of it (e.g., to use a curve
> other than P-256 for signatures), we’ll need to build a whole new API.  But
> these are issues that can be addressed in the W3C process.
>
> We will continue to work on making standards for secure authentication more
> open.  In the meantime, U2F is what’s here now, and there’s demonstrated
> developer interest, so it makes sense for us to work on implementing it.
>
> Thanks,
> --Richard
>
> [1] https://fidoalliance.org/
> [2] https://fidoalliance.org/specifications/download/
> [3] https://support.google.com/accounts/answer/6103523?hl=en
> [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
> [5]
> https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> [7] http://w3c.github.io/websec/web-authentication-charter
> ___
> 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: Intent to implement and ship: FIDO U2F API

2015-12-01 Thread Jonas Sicking 
Oh well. Bummer.

/ Jonas

On Tue, Dec 1, 2015 at 5:36 PM, Richard Barnes  wrote:
> It's my understanding that U2F qua U2F is considered pretty much baked by
> the developer community, and there's already code written to it.  But these
> concerns will be great for the W3C group and the successor API.  I've got a
> similar list started related to crypto and future-proofing.
>
>
> On Tue, Dec 1, 2015 at 8:29 PM, Jonas Sicking  wrote:
>>
>> Any chance that the API can be made a little more JS friendly? First
>> thing that stands out is the use of success/error callbacks rather
>> than the use of Promises.
>>
>> Also the use of numeric codes, rather than string values, is a pattern
>> that the web has generally moved away from.
>>
>> / Jonas
>>
>> On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes 
>> wrote:
>> > The FIDO Alliance has been developing standards for hardware-based
>> > authentication of users by websites [1].  Their work is getting
>> > significant
>> > traction, so the Mozilla Foundation has decided to join the FIDO
>> > Alliance.
>> > Work has begun in the W3C to create open standards using FIDO as a
>> > starting
>> > point. We are proposing to implement the FIDO U2F API in Firefox in its
>> > current form and then track the evolving W3C standard.
>> >
>> > Background: The FIDO Alliance has been developing a standard for
>> > hardware-based user authentication known as “Universal Two-Factor” or
>> > U2F
>> > [2].  This standard allows a website to verify that a user is in
>> > possession
>> > of a specific device by having the device sign a challenge with a
>> > private
>> > key that is held on the hardware device.  The browser’s role is mainly
>> > (1)
>> > to route messages between the website and the token, and (2) to add the
>> > origin of the website to the message signed by the token (so that the
>> > signature is bound to the site).
>> >
>> > Several major websites now support U2F for authentication, including
>> > Google
>> > [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
>> > for U2F support in Gecko [6].  The W3C has  begun the process of forming
>> > a
>> > “WebAuthentication” working group that will work on a standard for
>> > enhanced
>> > authentication using FIDO as a starting point [7].
>> >
>> > Proposed: To implement the high-level U2F API described in the FIDO JS
>> > API
>> > specification, with support for the USB HID token interface.
>> >
>> > Please send comments on this proposal to the list no later than Monday,
>> > December 14, 2015.
>> >
>> > -
>> >
>> > Personally, I have some reservations about implementing this, but I
>> > still
>> > think it’s worth doing, given the clear need for something to augment
>> > passwords.
>> >
>> > It’s unfortunate that the initial FIDO standards were developed in a
>> > closed
>> > group, but there is good momentum building toward making FIDO more open.
>> > I
>> > have some specific concerns about the U2F API itself, but they’re
>> > relatively minor.  For example, the whole system is highly vertically
>> > integrated, so if we want to change any part of it (e.g., to use a curve
>> > other than P-256 for signatures), we’ll need to build a whole new API.
>> > But
>> > these are issues that can be addressed in the W3C process.
>> >
>> > We will continue to work on making standards for secure authentication
>> > more
>> > open.  In the meantime, U2F is what’s here now, and there’s demonstrated
>> > developer interest, so it makes sense for us to work on implementing it.
>> >
>> > Thanks,
>> > --Richard
>> >
>> > [1] https://fidoalliance.org/
>> > [2] https://fidoalliance.org/specifications/download/
>> > [3] https://support.google.com/accounts/answer/6103523?hl=en
>> > [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
>> > [5]
>> >
>> > https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
>> > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
>> > [7] http://w3c.github.io/websec/web-authentication-charter
>> > ___
>> > 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: Intent to implement and ship: FIDO U2F API

2015-12-01 Thread Richard Barnes 
It's my understanding that U2F qua U2F is considered pretty much baked by
the developer community, and there's already code written to it.  But these
concerns will be great for the W3C group and the successor API.  I've got a
similar list started related to crypto and future-proofing.


On Tue, Dec 1, 2015 at 8:29 PM, Jonas Sicking  wrote:

> Any chance that the API can be made a little more JS friendly? First
> thing that stands out is the use of success/error callbacks rather
> than the use of Promises.
>
> Also the use of numeric codes, rather than string values, is a pattern
> that the web has generally moved away from.
>
> / Jonas
>
> On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes 
> wrote:
> > The FIDO Alliance has been developing standards for hardware-based
> > authentication of users by websites [1].  Their work is getting
> significant
> > traction, so the Mozilla Foundation has decided to join the FIDO
> Alliance.
> > Work has begun in the W3C to create open standards using FIDO as a
> starting
> > point. We are proposing to implement the FIDO U2F API in Firefox in its
> > current form and then track the evolving W3C standard.
> >
> > Background: The FIDO Alliance has been developing a standard for
> > hardware-based user authentication known as “Universal Two-Factor” or U2F
> > [2].  This standard allows a website to verify that a user is in
> possession
> > of a specific device by having the device sign a challenge with a private
> > key that is held on the hardware device.  The browser’s role is mainly
> (1)
> > to route messages between the website and the token, and (2) to add the
> > origin of the website to the message signed by the token (so that the
> > signature is bound to the site).
> >
> > Several major websites now support U2F for authentication, including
> Google
> > [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
> > for U2F support in Gecko [6].  The W3C has  begun the process of forming
> a
> > “WebAuthentication” working group that will work on a standard for
> enhanced
> > authentication using FIDO as a starting point [7].
> >
> > Proposed: To implement the high-level U2F API described in the FIDO JS
> API
> > specification, with support for the USB HID token interface.
> >
> > Please send comments on this proposal to the list no later than Monday,
> > December 14, 2015.
> >
> > -
> >
> > Personally, I have some reservations about implementing this, but I still
> > think it’s worth doing, given the clear need for something to augment
> > passwords.
> >
> > It’s unfortunate that the initial FIDO standards were developed in a
> closed
> > group, but there is good momentum building toward making FIDO more
> open.  I
> > have some specific concerns about the U2F API itself, but they’re
> > relatively minor.  For example, the whole system is highly vertically
> > integrated, so if we want to change any part of it (e.g., to use a curve
> > other than P-256 for signatures), we’ll need to build a whole new API.
> But
> > these are issues that can be addressed in the W3C process.
> >
> > We will continue to work on making standards for secure authentication
> more
> > open.  In the meantime, U2F is what’s here now, and there’s demonstrated
> > developer interest, so it makes sense for us to work on implementing it.
> >
> > Thanks,
> > --Richard
> >
> > [1] https://fidoalliance.org/
> > [2] https://fidoalliance.org/specifications/download/
> > [3] https://support.google.com/accounts/answer/6103523?hl=en
> > [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
> > [5]
> >
> https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
> > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> > [7] http://w3c.github.io/websec/web-authentication-charter
> > ___
> > 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: ESLint is now available in the entire tree

2015-12-01 Thread Kris Maglione 

On Fri, Nov 27, 2015 at 02:53:35PM -0800, Dave Townsend wrote:

Going forwards we'd like to enable it in more directories and turn on
more rules. You can help! If there is a directory you work in a lot
try removing it from the top-level .eslintignore file and see what
fails, then fix it. Mostly it will be simple fixes.


Fun fact: The document for .eslintignore suggests that rules 
beginning with "!" should unignore files matching that pattern. 
What it actually does is ignore all files not matching that 
pattern. Just in case anyone else was wasting their time trying 
to figure out why it wasn't working.

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

Re: Using the Taskcluster index to find builds

2015-12-01 Thread Julien Wajsberg 
hi,

Because we have an index, it's now very easy to add new routes. I think
it would be a lot more user-friendly to have an index that starts with
the product name ("firefox" for example).

For example: "gecko.v2.firefox.win64-opt.nightly.latest" instead of
"gecko.v2.mozilla-central.nightly.latest.firefox.win64-opt
".
Going from the most general to the most specific.
Using an index that starts with "mozilla-central" is really technical
and does not make things easy to find :/ Even if it can be good for
automated tools.

Fortunately now it's not either one or the other, we can have both. But
before filing a bug, I'd like to know if the general population thinks
it's a good idea.

-- 
Julien

Le 30/11/2015 21:43, Chris AtLee a écrit :
> The RelEng, Cloud Services and Taskcluster teams have been doing a lot of
> work behind the scenes over the past few months to migrate the backend
> storage for builds from the old "FTP" host to S3. While we've tried to make
> this as seamless as possible, the new system is not a 100% drop-in
> replacement for the old system, resulting in some confusion about where to
> find certain types of builds.
>
> At the same time, we've been working on publishing builds to the
> Taskcluster Index [1]. This service provides a way to find a build given
> various different attributes, such as its revision or date it was built.
> Our plan is to make the index be the primary mechanism for discovering
> build artifacts. As part of the ongoing buildbot to Taskcluster migration
> project, builds happening on Taskcluster will no longer upload to
> https://archive.mozilla.org (aka https://ftp.mozilla.org). Once we shut off
> platforms in buildbot, the index will be the only mechanism for discovering
> new builds.
>
> I posted to planet Mozilla last week [2] with some more examples and
> details. Please explore the index, and ask questions about how to find what
> you're looking for!
>
> Cheers,
> Chris
>
> [1] http://docs.taskcluster.net/services/index/
> [2] http://atlee.ca/blog/posts/firefox-builds-on-the-taskcluster-index.html
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

2015-12-01 Thread ryan . sleevi 
On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
> Oh well. Bummer.
> 
> / Jonas

If it cheers you up any, the 2.0 API that replaces the U2F API uses promises - 
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

Richard, it would help if you could clarify - are you proposing that Firefox 
implement the 'old and deprecated' U2F API [1], or the 'fresh and new and 
hoping to be standards track' W3C member submission API [2].

I originally wanted to reply with 'good news' that Chrome only shipped this for 
google.com, and only for HTTPS, and that we were committed to the W3C member 
submission as the path forward, but as I was working to back up a citation to 
this, I found out that we submarine-launched the API in Chrome 40 [3], for all 
HTTP and HTTPS origins, without an Intent to Implement / Intent to Ship.

So, speaking solely on my behalf and not that of my employer, sorry that Chrome 
put Firefox in this position of "old and busted" and "new hotness", with 
"damned either way" as the result. I'm trying to find out more about this, as 
well as Chrome and Chromium's future commitments regarding this API.

That said, knowing full well that the FIDO Alliance intends the W3C member 
submission to the path forward, could you provide greater clarity:
1) What it is you intend to implement?
2) If you intend to implement [1], whether or not you'll unship that if/as/when 
[2] progresses?

[1] 
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html
[2] http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
[3] 
https://chromium.googlesource.com/chromium/src/+/d60fcd7caafa7046da693fe2c3206ab5cf20%5E%21/#F9
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APZ enabled on Fennec nightly

2015-12-01 Thread Kearwood "Kip" Gilbert 
Excellent, Kats!!

Perhaps this will also unblock smooth scrolling and scroll snapping for fennec.

Cheers,
 - Kearwood “Kip” Gilbert

> On Nov 30, 2015, at 8:37 AM, Kartikaya Gupta  wrote:
> 
> Hi all,
> 
> Just a heads up that I landed the patch to enable APZ on Fennec
> (nightly channel only for now). It should be in the Dec 1 nightly and
> onwards. This will make scrolling around, and general touch input
> handling, feel different on Fennec. The main improvement should be
> that scrolling of iframes and overflow:scroll divs will be smoother
> and faster.
> 
> If you find bugs, or behaviour differences that you feel make things
> worse, please file them in the "Graphics, Panning and Zooming"
> component of the "Firefox for Android" component and we'll take a
> look.
> 
> Thanks!
> kats
> ___
> 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: APZ enabled on Fennec nightly

2015-12-01 Thread Kartikaya Gupta 
Yes, I will be testing those features on Fennec later this week and
enabling them as well if they work well (or investigating why if they
don't). :)

On Tue, Dec 1, 2015 at 2:14 PM, Kearwood "Kip" Gilbert
 wrote:
> Excellent, Kats!!
>
> Perhaps this will also unblock smooth scrolling and scroll snapping for 
> fennec.
>
> Cheers,
>  - Kearwood “Kip” Gilbert
>
>> On Nov 30, 2015, at 8:37 AM, Kartikaya Gupta  wrote:
>>
>> Hi all,
>>
>> Just a heads up that I landed the patch to enable APZ on Fennec
>> (nightly channel only for now). It should be in the Dec 1 nightly and
>> onwards. This will make scrolling around, and general touch input
>> handling, feel different on Fennec. The main improvement should be
>> that scrolling of iframes and overflow:scroll divs will be smoother
>> and faster.
>>
>> If you find bugs, or behaviour differences that you feel make things
>> worse, please file them in the "Graphics, Panning and Zooming"
>> component of the "Firefox for Android" component and we'll take a
>> look.
>>
>> Thanks!
>> kats
>> ___
>> 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

Want a custom Telemetry Dashboard? Dashboard Generator.

2015-12-01 Thread Chris H-C 
Hello Everyone,

  There's a new addition to https://telemetry.mozilla.org today: Dashboard
Generator (https://telemetry.mozilla.org/dashboard-generator/index.html).

  It comes with an accompanying blog post (
https://chuttenblog.wordpress.com/to-order-telemetry-dashboards-dashboard-generator/)
but you're too busy, so here's the tl;dr:

  Let's say you're a JS dev and you want to see how garbage collector
performance is changing with E10s. So you'll want GC_MS on Nightly/latest,
compare by E10s. And to see how the measures have been changing you'll want
an evolution over the last three versions filtered to each of E10s and
Single Process.

  You will end up with a dashgen looking something like this:
http://mzl.la/1LM4kXH

  Then you press 'Generate Dashboard' and you will get a CodePen. Press
'Save' and it'll give you a URL like this:
https://codepen.io/anon/pen/JGPYzm

  Don't like it? Change the parameters in the CodePen JS window, or remove
and re-add some plots in the Dashboard Generator. Or Export and work on it
in your own dev environment.

  Play around with it. Ask some questions. Get answers from the data. And
if you find any bugs or think of improvements, file them here:
https://github.com/mozilla/telemetry-dashboard/issues

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

Re: Using the Taskcluster index to find builds

2015-12-01 Thread Axel Hecht 
I haven't found localized builds and their assets by glancing at things. 
Are those to come?


Also, I suspect we should rewrite wget-en-US? Or add an alternative 
that's index-bound?


Axel

On 11/30/15 9:43 PM, Chris AtLee wrote:

The RelEng, Cloud Services and Taskcluster teams have been doing a lot of
work behind the scenes over the past few months to migrate the backend
storage for builds from the old "FTP" host to S3. While we've tried to make
this as seamless as possible, the new system is not a 100% drop-in
replacement for the old system, resulting in some confusion about where to
find certain types of builds.

At the same time, we've been working on publishing builds to the
Taskcluster Index [1]. This service provides a way to find a build given
various different attributes, such as its revision or date it was built.
Our plan is to make the index be the primary mechanism for discovering
build artifacts. As part of the ongoing buildbot to Taskcluster migration
project, builds happening on Taskcluster will no longer upload to
https://archive.mozilla.org (aka https://ftp.mozilla.org). Once we shut off
platforms in buildbot, the index will be the only mechanism for discovering
new builds.

I posted to planet Mozilla last week [2] with some more examples and
details. Please explore the index, and ask questions about how to find what
you're looking for!

Cheers,
Chris

[1] http://docs.taskcluster.net/services/index/
[2] http://atlee.ca/blog/posts/firefox-builds-on-the-taskcluster-index.html



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

Re: Thunderbird, the future, mozilla-central and comm-central

2015-12-01 Thread mokvwap 
On Monday, November 30, 2015 at 10:08:19 PM UTC+1, Mitchell Baker wrote:
> This is a long-ish message. It covers general topics about Thunderbird 
> and the future, and also the topics of the Foundation involvement (point 
> 9) and the question of merging repositories (point 11).   Naturally, I 
> believe it's worth the time to read through the end.
> 
> 1. Firefox and Thunderbird have lived with competing demands for some 
> time now. Today Thunderbird developers spend much of their time 
> responding to changes made in core Mozilla systems and technologies. At 
> the same time, build, Firefox, and platform engineers continue to pay a 
> tax to support Thunderbird.
> 
> 2. These competing demands are not good for either project. Engineers 
> working on Thunderbird must focus on keeping up and adapting Firefox's 
> web-driven changes. Engineers working on Firefox and related projects 
> end up considering the competing demands of Thunderbird, and/or 
> wondering if and how much they should assist Thunderbird. Neither 
> project can focus wholeheartedly on what is best for it.
> 
> 3. These competing demands will not get better soon. Instead, they are 
> very likely to get worse. Firefox and related projects are now speeding 
> up the rate of change, modernizing our development process and our 
> infrastructure. Indeed, this is required for Mozilla to have significant 
> impact in the current computing environment.
> 
> 4. There is a belief among some that living with these competing demands 
> is good for the Mozilla project as a whole, because it gives us an 
> additional focus, assists Thunderbird as a dedicated open source 
> community, and also supports an open source standards based email 
> client. This sentiment is appealing, and I share it to some extent. 
> There is also a sense that caring for fellow open source developers is 
> good, which I also share.  However, point 2 above -- "Neither project can 
> focus wholeheartedly on what is best for it" -- is the most important 
> point. Having Thunderbird has an additional product and focus is *not* 
> good overall if it causes all of our products -- Firefox, other 
> web-driven products and Thunderbird -- to fall short of what we can 
> accomplish.
> 
> 5.  Many inside of Mozilla, including an overwhelming majority of our 
> leadership, feel the need to be laser-focused on activities like Firefox 
> that can have an industry-wide impact.With all due respect to 
> Thunderbird and the Thunderbird community, we have been clear for years 
> that we do not view Thunderbird as having this sort of potential.
> 
> 6.  Given this, it's clear to me that sooner or later paying a tax to 
> support Thunderbird will not make sense as a policy for Mozilla.I 
> know many believe this time came a while back, and I've been slow to say 
> this clearly.  And of course, some feel that this time should never 
> come.  However, as I say, it's clear to me today that continuing to live 
> with these competing demands given our focus on industry impact is 
> increasingly unstable.  We've seen this already, in an unstructured way, 
> as various groups inside Mozilla stop supporting Thunderbird.  The 
> accelerating speed of Firefox and infrastructure changes -- which I 
> welcome wholeheartedly -- will emphasize this.
> 
> 7.  Some Mozillians are eager to see Mozilla support community-managed 
> projects within our main development efforts.  I am also sympathetic to 
> this view, with a key precondition.  Community-managed projects that 
> make the main effort less nimble and likely to succeed don't fit very 
> well into this category for me.  They can still be great open source 
> projects -- this is a separate question from whether the fit in our main 
> development systems.  I feel so strongly about this because I am so 
> concerned that "the Web" we  love is at risk.  If we want the traits of 
> the Web to live and prosper in the world of mobile, social and data then 
> we have to be laser-focused on this.
> 
> 8.  Therefore I believe Thunderbird should would thrive best by 
> separating itself from reliance on Mozilla development systems and in 
> some cases, Mozilla technology. The current setting isn't stable, and we 
> should start actively looking into how we can transition in an orderly 
> way to a future where Thunderbird and Firefox are un-coupled.   I don't 
> know what this will look like, or how it will work yet. I do know that 
> it needs to happen, for both Firefox and Thunderbird's sake.  This is a 
> big job, and may require expertise that the Thunderbird team doesn't yet 
> have.Mozilla can provide various forms of assistance to the 
> Thunderbird team via a set of the Mozilla Foundation's capabilities.
> 
> 9. Mark Surman of the Mozilla Foundation and I are both interested in 
> helping find a way for Thunderbird to separate from Mozilla 
> infrastructure. We also want to make sure that Thunderbird has the right 
> kind of legal and financial

[no subject]

2015-12-01 Thread Carsten Book 
Hi,

To give a little insight into our work and make our work more visible to
our Community we decided to create a  monthly report of what's going on in
the Sheriffs Team.

If you have questions or feedback, just let us know!

In case you don't know who the sheriffs are, or to check if there are
current issues on the tree, see:
https://sheriffs.etherpad.mozilla.org/sheriffing-notes

Topics of this month!

1. How-To article of the month
2. Get involved
3. Statistics
4. Orange Factor
5. Meeting notes
6. Contact

1. How-To article of the month and notable things!

Sheriffs also do uplifts (like to mozilla-aurora, mozilla-beta, etc) - The
how-to page we use for that is mainly:
https://wiki.mozilla.org/Sheriffing/How:To:Uplifts


2. Get involved!

Are you interested in helping out by becoming a Community Sheriff? Let us
know!

3. Statistics

Intermittent Bugs filed this month [1]: 319
and 19 of them are closed [2]

For Tree Closing times and reasons see:
http://futurama.theautomatedtester.co.uk/

4. Orange Factor

Current Orangefactor [3]: 16:36

5. Meeting Notes:

We Sheriffs hold regular meetings. Our notes can be found here:

https://public.etherpad-mozilla.org/p/Sheriff-meeting-16nov

6.  How to contact us

There are a lot of ways to contact us. The fastest one is to contact
the sheriff on duty (the one with the |sheriffduty tag on their nick
:) or by emailing sheriffs @ mozilla dot org.

Cheers,

- Tomcat

[1] http://mzl.la/1PrCHei
[2] http://mzl.la/1QRza9e
[3] https://brasstacks.mozilla.com/orangefactor/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using the Taskcluster index to find builds

2015-12-01 Thread Chris AtLee 
Localized builds should be at e.g.
gecko.v2.mozilla-central.latest.firefox-l10n.win32-opt

And yes, once we've got the naming structure nailed down, wget-en-US should
change to use the index.

On Tue, Dec 1, 2015 at 5:22 AM, Axel Hecht  wrote:

> I haven't found localized builds and their assets by glancing at things.
> Are those to come?
>
> Also, I suspect we should rewrite wget-en-US? Or add an alternative that's
> index-bound?
>
> Axel
>
> On 11/30/15 9:43 PM, Chris AtLee wrote:
>
>> The RelEng, Cloud Services and Taskcluster teams have been doing a lot of
>> work behind the scenes over the past few months to migrate the backend
>> storage for builds from the old "FTP" host to S3. While we've tried to
>> make
>> this as seamless as possible, the new system is not a 100% drop-in
>> replacement for the old system, resulting in some confusion about where to
>> find certain types of builds.
>>
>> At the same time, we've been working on publishing builds to the
>> Taskcluster Index [1]. This service provides a way to find a build given
>> various different attributes, such as its revision or date it was built.
>> Our plan is to make the index be the primary mechanism for discovering
>> build artifacts. As part of the ongoing buildbot to Taskcluster migration
>> project, builds happening on Taskcluster will no longer upload to
>> https://archive.mozilla.org (aka https://ftp.mozilla.org). Once we shut
>> off
>> platforms in buildbot, the index will be the only mechanism for
>> discovering
>> new builds.
>>
>> I posted to planet Mozilla last week [2] with some more examples and
>> details. Please explore the index, and ask questions about how to find
>> what
>> you're looking for!
>>
>> Cheers,
>> Chris
>>
>> [1] http://docs.taskcluster.net/services/index/
>> [2]
>> http://atlee.ca/blog/posts/firefox-builds-on-the-taskcluster-index.html
>>
>>
> ___
> 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: Using the Taskcluster index to find builds

2015-12-01 Thread Chris AtLee 
The expiration is currently set to one year, but we can (and should!)
change that for nightlies. That work is being tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1145300

On Mon, Nov 30, 2015 at 7:00 PM, Ryan VanderMeulen  wrote:

> On 11/30/2015 3:43 PM, Chris AtLee wrote:
>
>> The RelEng, Cloud Services and Taskcluster teams have been doing a lot of
>> work behind the scenes over the past few months to migrate the backend
>> storage for builds from the old "FTP" host to S3. While we've tried to
>> make
>> this as seamless as possible, the new system is not a 100% drop-in
>> replacement for the old system, resulting in some confusion about where to
>> find certain types of builds.
>>
>> At the same time, we've been working on publishing builds to the
>> Taskcluster Index [1]. This service provides a way to find a build given
>> various different attributes, such as its revision or date it was built.
>> Our plan is to make the index be the primary mechanism for discovering
>> build artifacts. As part of the ongoing buildbot to Taskcluster migration
>> project, builds happening on Taskcluster will no longer upload to
>> https://archive.mozilla.org (aka https://ftp.mozilla.org). Once we shut
>> off
>> platforms in buildbot, the index will be the only mechanism for
>> discovering
>> new builds.
>>
>> I posted to planet Mozilla last week [2] with some more examples and
>> details. Please explore the index, and ask questions about how to find
>> what
>> you're looking for!
>>
>> Cheers,
>> Chris
>>
>> [1] http://docs.taskcluster.net/services/index/
>> [2]
>> http://atlee.ca/blog/posts/firefox-builds-on-the-taskcluster-index.html
>>
>> If I understand correctly, Taskcluster builds are only archived for one
> year, whereas we have nightly archives going back 10+ years now. What are
> our options for long-term archiving in this setup?
>
> ___
> 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: Using the Taskcluster index to find builds

2015-12-01 Thread Ryan VanderMeulen 
What does that mean for jobs that have already run? My understanding is 
that we can't change the expiration after the fact for them? Though I 
guess that it's not an issue as long as we fix bug 1145300 prior to 
shutting off publishing to archive.m.o?


I just want to avoid any gaps in nightly build coverage as the archived 
builds are critical for regression hunting.


On 12/1/2015 9:49 AM, Chris AtLee wrote:

The expiration is currently set to one year, but we can (and should!)
change that for nightlies. That work is being tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1145300

On Mon, Nov 30, 2015 at 7:00 PM, Ryan VanderMeulen  wrote:


On 11/30/2015 3:43 PM, Chris AtLee wrote:


The RelEng, Cloud Services and Taskcluster teams have been doing a lot of
work behind the scenes over the past few months to migrate the backend
storage for builds from the old "FTP" host to S3. While we've tried to
make
this as seamless as possible, the new system is not a 100% drop-in
replacement for the old system, resulting in some confusion about where to
find certain types of builds.

At the same time, we've been working on publishing builds to the
Taskcluster Index [1]. This service provides a way to find a build given
various different attributes, such as its revision or date it was built.
Our plan is to make the index be the primary mechanism for discovering
build artifacts. As part of the ongoing buildbot to Taskcluster migration
project, builds happening on Taskcluster will no longer upload to
https://archive.mozilla.org (aka https://ftp.mozilla.org). Once we shut
off
platforms in buildbot, the index will be the only mechanism for
discovering
new builds.

I posted to planet Mozilla last week [2] with some more examples and
details. Please explore the index, and ask questions about how to find
what
you're looking for!

Cheers,
Chris

[1] http://docs.taskcluster.net/services/index/
[2]
http://atlee.ca/blog/posts/firefox-builds-on-the-taskcluster-index.html

If I understand correctly, Taskcluster builds are only archived for one

year, whereas we have nightly archives going back 10+ years now. What are
our options for long-term archiving in this setup?

___
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: Thunderbird, the future, mozilla-central and comm-central

2015-12-01 Thread Kurt Roeckx 

On 2015-11-30 22:11, Mitchell Baker wrote:

5.  Many inside of Mozilla, including an overwhelming majority of our
leadership, feel the need to be laser-focused on activities like Firefox
that can have an industry-wide impact.With all due respect to
Thunderbird and the Thunderbird community, we have been clear for years
that we do not view Thunderbird as having this sort of potential.


I currently don't see Mozilla having a focus or having an industry-wide 
impact.  I do see both Firefox and Thunderbird as having that potential.



Kurt

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

Re: APZ enabled on Fennec nightly

2015-12-01 Thread Mark Finkle 
Awesome! Thanks to the team that made this happen.

(CC'ing dev-mobile-firefox too)

On Mon, Nov 30, 2015 at 11:37 AM, Kartikaya Gupta 
wrote:

> Hi all,
>
> Just a heads up that I landed the patch to enable APZ on Fennec
> (nightly channel only for now). It should be in the Dec 1 nightly and
> onwards. This will make scrolling around, and general touch input
> handling, feel different on Fennec. The main improvement should be
> that scrolling of iframes and overflow:scroll divs will be smoother
> and faster.
>
> If you find bugs, or behaviour differences that you feel make things
> worse, please file them in the "Graphics, Panning and Zooming"
> component of the "Firefox for Android" component and we'll take a
> look.
>
> Thanks!
> kats
> ___
> 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: Using the Taskcluster index to find builds

2015-12-01 Thread Chris AtLee 
You're right in that we can't change the expiration after the fact, but we
can copy all of the artifacts to new tasks with the longer expiration.

On Tue, Dec 1, 2015 at 9:53 AM, Ryan VanderMeulen  wrote:

> What does that mean for jobs that have already run? My understanding is
> that we can't change the expiration after the fact for them? Though I guess
> that it's not an issue as long as we fix bug 1145300 prior to shutting off
> publishing to archive.m.o?
>
> I just want to avoid any gaps in nightly build coverage as the archived
> builds are critical for regression hunting.
>
> On 12/1/2015 9:49 AM, Chris AtLee wrote:
>
>> The expiration is currently set to one year, but we can (and should!)
>> change that for nightlies. That work is being tracked in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1145300
>>
>> On Mon, Nov 30, 2015 at 7:00 PM, Ryan VanderMeulen 
>> wrote:
>>
>> On 11/30/2015 3:43 PM, Chris AtLee wrote:
>>>
>>> The RelEng, Cloud Services and Taskcluster teams have been doing a lot of
 work behind the scenes over the past few months to migrate the backend
 storage for builds from the old "FTP" host to S3. While we've tried to
 make
 this as seamless as possible, the new system is not a 100% drop-in
 replacement for the old system, resulting in some confusion about where
 to
 find certain types of builds.

 At the same time, we've been working on publishing builds to the
 Taskcluster Index [1]. This service provides a way to find a build given
 various different attributes, such as its revision or date it was built.
 Our plan is to make the index be the primary mechanism for discovering
 build artifacts. As part of the ongoing buildbot to Taskcluster
 migration
 project, builds happening on Taskcluster will no longer upload to
 https://archive.mozilla.org (aka https://ftp.mozilla.org). Once we shut
 off
 platforms in buildbot, the index will be the only mechanism for
 discovering
 new builds.

 I posted to planet Mozilla last week [2] with some more examples and
 details. Please explore the index, and ask questions about how to find
 what
 you're looking for!

 Cheers,
 Chris

 [1] http://docs.taskcluster.net/services/index/
 [2]
 http://atlee.ca/blog/posts/firefox-builds-on-the-taskcluster-index.html

 If I understand correctly, Taskcluster builds are only archived for one

>>> year, whereas we have nightly archives going back 10+ years now. What are
>>> our options for long-term archiving in this setup?
>>>
>>> ___
>>> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform