Re: PSA: Windows Defender can slow down builds and tests

[Gijs Kruitbosch]

On 01/07/2016 01:48, Gregory Szorc wrote:

Until we find a way to alert people to the negative performance impact of
Windows Defender (or most other anti-virus solutions for that matter) in
bug 1276019, I would invite you to consider having Windows Defender (or
other anti-virus products) exclude the Firefox source and object
directories so file scanning doesn't slow down I/O intensive development
operations.


As Xidorn already noted, this problem is not limited to the source and 
object directories, see also e.g. 
https://github.com/Maximus5/ConEmu/issues/692 , especially if you use 
something other than the builtin Windows terminal to run mach / build, etc.


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

Re: Making try faster for debugging intermittents

[Mike Hommey]

On Fri, Jul 01, 2016 at 03:07:43PM +1000, Xidorn Quan wrote:
> On Fri, Jul 1, 2016 at 1:02 PM, Karl Tomlinson  wrote:
> 
> > William Lachance writes:
> >
> > > As part of a larger effort to improve the experience around
> > > debugging intermittents, I've been looking at reducing the time it
> > > takes for common "try" workloads for developers (so that
> > > e.g. retriggering a job to reproduce a failure can happen faster).
> >
> > > Also, accounts of specific try workloads of this type which are
> > > annoying/painful would be helpful. :) I think I have a rough idea
> > > of the particular type of try push I'm looking for (not pushed by
> > > release operations, at least one retrigger) but it would be great
> > > to get firsthand confirmation of that.
> >
> > One thing that might be helpful is enabling running only tests on
> > try with a designated build that has already been created.
> >
> > Often tests are modified to add logging, after which the same
> > build could be run with the new version of the test, thus saving
> > waiting for a build.
> >
> 
> FWIW, there's a bug about this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240644

You can already run tests with arbitrary test tarballs (that you could
create locally), but I can't find where it's documented, which may
explain why it's not well known.

(CCing Armen, who would know)

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

Intent to implement and ship: force flattening of transform-style:preserve-3d when opacity is applied

[Matt Woodrow]

Summary:

The editors draft of the 3d transforms spec [1] has been updated to say 
that we need to flatten preserve-3d when the element also has an opacity 
of < 1, whereas the previous spec [2] made no mention of opacity.


The current behaviour (in Gecko, WebKit and blink) is to drop the 
'group' nature of opacity, and propagate the opacity effect down on to 
the leaves of the preserve-3d tree. This is non-intuitive, not specified 
at all, and has slightly differently rendering in all browsers (based on 
the specifics of what compositable layers get created I believe - see 
layout/reftests/opacity-preserve3d-N.html reftests).


The blink team intend to change their behaviour to match the new spec, 
even though it might break webcompat in some cases. The initial 
www-style discussion [3] and their intent to implement thread [4] covers 
their motivations for wanting to do this.


Given that the existing behaviour appears to be used incredibly rarely 
[5] and that it moves us to well specified behaviour that is easy to 
conform to, then I think we should do the same.



Bug:

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


Link to standard:

Editors draft: 
https://drafts.csswg.org/css-transforms/#grouping-property-values 



Current spec: https://www.w3.org/TR/css-transforms-1/ 
 







Platform coverage:

All platforms

Estimated or target release:

Firefox 52.

Preference behind which this will be implemented:

None.

- Matt

[1] https://drafts.csswg.org/css-transforms/#grouping-property-values 
[2] https://www.w3.org/TR/css-transforms-1/#transform-style-property [3] 
https://lists.w3.org/Archives/Public/www-style/2016May/0239.html [4] 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eBIp90_il1o 
 
[5] 
https://www.chromestatus.com/metrics/feature/popularity#OpacityWithPreserve3DQuirk




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

Re: MXR permanently offline, please transition to DXR

[Panos Astithas]

It seems like the awesomebar could at least help you by boosting the
frecency weight of the new URL compared to the old one, so it can gradually
(or even not so gradually) be replaced. We are going to fix this in bug 737836.


Panos

On Fri, Jul 1, 2016 at 3:58 AM, Justin Dolske  wrote:

> This reminds me of a password manager bug we fixed 9 years ago (379997!),
> where password manager would "helpfully" delete a saved HTTP login if it
> got a 403 response upon using it. Unsurprisingly, this was a a terrible
> idea that caused your saved logins to disappear when a site was glitchy.
>
> Seem like it would be tough to find a solution to rewrite history/bookmarks
> that works when servers are nice, but also ignores servers that are
> naughty. Maybe this is addon-fodder for advanced users who want to
> mass-edit bookmarks and history.
>
> Justin
>
> On Thu, Jun 30, 2016 at 4:55 PM, Robert O'Callahan 
> wrote:
>
> > In theory responses 301 and 308 mean "permanent redirect" so the browser
> > could do that for those responses.
> >
> > In practice you'd need a lot of data to convince yourself that Web
> > developers haven't screwed this up too badly. Maybe 308, being newer, is
> > not compromised...
> >
> > 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
> >
> ___
> 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

Notice: decommissioning git.mozilla.org

[Jonathan Griffin]

We are planning to decommission git.mozilla.org. It was originally created
to serve the B2G project, but is no longer needed for that purpose, and
other uses have remained slight and don't justify the operational or
maintenance costs.

There is some work underway to migrate existing users to alternatives; this
is tracked in bugs that block https://bugzil.la/1277297. As soon as the
last of these is cleaned up, we'll be turning off git.mozilla.org. This
will likely occur the week of July 5th.

For futher details, see this dev-version-control thread:
https://groups.google.com/forum/#!topic/mozilla.dev.version-control/H6_TWlWPQGk
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tier-1 for Fennec api-15 Debug builds in TaskCluster at end of week (July 1st)

[jlund]

On Wednesday, June 29, 2016 at 10:44:16 AM UTC-7, jmaher wrote:
> On Wednesday, June 29, 2016 at 7:37:51 PM UTC+3, jl...@mozilla.com wrote:
> > On Tuesday, June 28, 2016 at 2:35:22 PM UTC-7, David Baron wrote:
> > 
> > > 
> > > Why is it vital to opt jobs but less so for debug jobs?
> > 
> > you're right. I worded this poorly. I mean more that opt builds are part of 
> > the critical path: they are the actual builds that we promote to releases 
> > and therefore more important.
> > 
> > it sounds like you personally don't mind triggering new jobs missing on 
> > fennec debug for a few weeks. My hope is that others feel the same.
> 
> I would prefer to push this out a week.  We just got builds running on 
> inbound/fx-team this week, and there are downstream consumers that depend on 
> buildbot builds which need to be updated (and couldn't until this week at the 
> earliest).
> 
> I would also like to make sure that failures from builds and tests are 
> understandable to the sheriffs.
> 
> July 11th seems like a better candidate to switch so we can find other issues 
> which might be related.

Okay let's aim for July 11th. Thanks for raising these issues. I would push 
back if it was just missing 'trigger new jobs' against existing builds but I 
don't want to break downstream consumers, find bustage in other trunk based 
repos, or surprise sheriffs.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Notice: decommissioning git.mozilla.org

[Nicolas B. Pierron]

On 07/01/2016 06:11 PM, Jonathan Griffin wrote:

We are planning to decommission git.mozilla.org. It was originally created
to serve the B2G project, but is no longer needed for that purpose, and
other uses have remained slight and don't justify the operational or
maintenance costs.

There is some work underway to migrate existing users to alternatives; this
is tracked in bugs that block https://bugzil.la/1277297. As soon as the
last of these is cleaned up, we'll be turning off git.mozilla.org. This
will likely occur the week of July 5th.

For futher details, see this dev-version-control thread:
https://groups.google.com/forum/#!topic/mozilla.dev.version-control/H6_TWlWPQGk



Would we keep maintaining the github mirror[1] of Gecko?

Are we planning to enforce git-cinnabar, even if this implies that we cannot 
collaborate (yet) with other git repositories?


[1] https://github.com/mozilla/gecko-dev

Apparently git.mozilla.org/integration/gecko-dev.git is already lagging behind.

If like me you were using gecko-dev.git, you can switch to github using the 
following command (assuming …/gecko-dev.git was named origin):


$ git remote set-url origin https://github.com/mozilla/gecko-dev.git

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

Re: The integration/autoland repo

[Henrik Skupin]

Gregory Szorc wrote on 06/28/2016 08:44 PM:
> As of a few minutes ago, when you land commits from MozReview they will be
> pushed to https://hg.mozilla.org/integration/autoland instead of
> https://hg.mozilla.org/integration/mozilla-inbound.
> 
> For now, think of integration/autoland as just another mozilla-inbound or
> fx-team. In fact, the sheriffs will be treating the autoland repo just like
> they treat inbound and fx-team. But that will change in the weeks ahead.

I'm just curious when autoland will actually be merged to
mozilla-central the first time. Given that we have this repository for a
while now, and sheriffs merged mozilla-central into it a couple of
times, I do not see any single merge of autoland to mozilla-central yet.
It's blocking some of my patches to reach Nightly builds. So for me the
current situation is not satisfying.

Can you please clarify the merge strategy?

> *Please do not pull from the autoland repo.* If you do, future changes that
> will introduce divergent commits/DAG heads will make your life painful.

This gives problems if you have patches for different bugs but which
have overlapping code blocks. This requires you to keep already landed
commits around until code found its way to mozilla-central and
mozilla-inbound. Given that this can take up to a day or more I don't
feel satisfied right now in using autoland for my mozreview patches.

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

Re: Notice: decommissioning git.mozilla.org

[Jonathan Griffin]

There is no change to https://github.com/mozilla/gecko-dev or related
workflows. Only the git.mozilla.org mirror of this repo is going away.

On Fri, Jul 1, 2016 at 12:40 PM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> On 07/01/2016 06:11 PM, Jonathan Griffin wrote:
>
>> We are planning to decommission git.mozilla.org. It was originally
>> created
>> to serve the B2G project, but is no longer needed for that purpose, and
>> other uses have remained slight and don't justify the operational or
>> maintenance costs.
>>
>> There is some work underway to migrate existing users to alternatives;
>> this
>> is tracked in bugs that block https://bugzil.la/1277297. As soon as the
>> last of these is cleaned up, we'll be turning off git.mozilla.org. This
>> will likely occur the week of July 5th.
>>
>> For futher details, see this dev-version-control thread:
>>
>> https://groups.google.com/forum/#!topic/mozilla.dev.version-control/H6_TWlWPQGk
>>
>>
> Would we keep maintaining the github mirror[1] of Gecko?
>
> Are we planning to enforce git-cinnabar, even if this implies that we
> cannot collaborate (yet) with other git repositories?
>
> [1] https://github.com/mozilla/gecko-dev
>
> Apparently git.mozilla.org/integration/gecko-dev.git is already lagging
> behind.
>
> If like me you were using gecko-dev.git, you can switch to github using
> the following command (assuming …/gecko-dev.git was named origin):
>
> $ git remote set-url origin https://github.com/mozilla/gecko-dev.git
>
> --
> Nicolas B. Pierron
> ___
> 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: The integration/autoland repo

[Gijs Kruitbosch]

On 01/07/2016 20:52, Henrik Skupin wrote:

I do not see any single merge of autoland to mozilla-central


https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=61ed5c0d64195c58de57489147046aeaf14252d3

is a merge from autoland to m-c earlier today, and you are CC'd on the 
bug...


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