Re: Removing tinderbox-builds from archive.mozilla.org

[Mike Kaply]

Can we move the builds temporarily and see if it affects workflows over a
few months and if not, then remove them?

Mike

On Thu, May 17, 2018 at 9:22 AM, Tom Ritter  wrote:

> I agree with ekr in general, but I would also be curious to discover
> what failures we would experience in practice and how we could
> overcome them.
>
> I think many of the issues experienced with local builds are
> preventable by doing a TC-like build; just build in a docker container
> (for Linux/Mac) and auto-build any toolchains needed. (Which would be
> part of bisect in the cloud automatically.) I've been doing this
> locally lately and it is not a friendly process right now though.
>
> Of course on Windows it's an entirely different story. But one more
> reason to pursue clang-cl builds on Linux ;)
>
> -tom
>
>
> On Tue, May 15, 2018 at 12:53 PM, Randell Jesup 
> wrote:
> >>On 5/11/18 7:06 PM, Gregory Szorc wrote:
> >>> Artifact retention and expiration boils down to a
> >>> trade-off between the cost of storage and the convenience of accessing
> >>> something immediately (as opposed to waiting several dozen minutes to
> >>> populate the cache).
> >>
> >>Just to be clear, when doing a bisect, one _can_ just deal with local
> >>builds.  But the point is that then it takes tens of minutes per build as
> >>you point out.  So a bisect task that might otherwise take 10-15 minutes
> >>total (1 minute per downloaded build) ends up taking hours...
> >
> > Also (as others have pointed out) going too far back (often not that
> > far) may run you into tool differences that break re-building old revs.
> > Hopefully you don't get variable behavior, just a failure-to-build at
> > some point.  I'm not sure how much Rust has made this worse.
> >
> > --
> > Randell Jesup, Mozilla Corp
> > remove "news" for personal email
> > ___
> > 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: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine

[Mike Kaply]

We currently do not plan to allow arbitrary preferences, but if certain
preferences are important, we can add policies for them.

We could also add policies that set groups of preferences for specific
purposes.

Mike

On Thu, Dec 21, 2017 at 10:03 AM, Luke Crouch  wrote:

> On Wednesday, December 20, 2017 at 9:42:50 AM UTC-6, Sylvestre Ledru wrote:
> > First, as Dave Camp mentioned during the Firefox All Hands, we are
> started some developments to improve
> > our support for enterprise users.
> > More information can be found on the wiki: https://wiki.mozilla.org/
> Firefox/EnterprisePolicies
>
> The first example configuration.json I saw on the page only shows some
> custom policy configs - e.g., bookmarks_on_toolbar, allow_popups_from, etc.
>
> Will the policy config allow admins to set other/any about:config prefs to
> custom values?
>
> I'm thinking specifically it would be cool to let Enterprise+InfoSec
> admins set some security + privacy about:config prefs to more hardened
> defaults.
> ___
> 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: Proposal to remove some preferences override support

[Mike Kaply]

When I first read this, I thought you meant the defaults/preferences
directory in Firefox.

Considering this only worked for true legacy extensions (not bootstrapped
extensions), this shouldn't be a problem for enterprise.

We double check to sure that no system add-ons need this.

Mike

On Wed, Nov 1, 2017 at 6:41 PM, Nicholas Nethercote 
wrote:

> Greetings,
>
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1413413 I am planning to
> remove a couple of things relating to preferences.
>
> 1) Remove the defaults/preferences directory support for extensions. This
> is a feature that was used by legacy extensions but is not used by
> WebExtensions.
>
> 2) Remove the "preferences" override directory in the user profile.
> This removes
> support for profile preferences override files other than user.js.
>
> The bug has a patch with r+. The specific things it removes include:
> - The "load-extension-default" notification.
> - The NS_EXT_PREFS_DEFAULTS_DIR_LIST/"ExtPrefDL" directory list, including
> the entry from the toolkit directory service.
>
> Does anybody foresee any problems with this change?
>
> Thanks.
>
> Nick
> ___
> 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: nsAutoConfig

[Mike Kaply]

I didn't write the test, so I honestly don't know. I'll try to make time to
take a look.

Mike

On Wed, Nov 1, 2017 at 12:04 PM, <mcastelluc...@mozilla.com> wrote:

> Hey Mike,
> according to our code coverage report, nsAutoConfig is never executed
> during tests.
>
> As far as I can see, it is actually not tested, as the test you mentioned
> is not setting the autoadmin.global_config_url pref that would make
> nsReadConfig instantiate nsAutoConfig. Is that correct?
>
> I'd like to understand whether this is a problem in our coverage
> collection tools that are not picking up this file for some reason or if it
> actually is not tested. I've opened https://bugzilla.mozilla.org/
> show_bug.cgi?id=1413600.
>
> - Marco.
>
> On Tuesday, October 31, 2017 at 4:22:06 PM UTC+1, mka...@mozilla.com
> wrote:
> > On Tuesday, October 31, 2017 at 12:10:21 AM UTC-5, Nicholas Nethercote
> wrote:
> > > Hi,
> > >
> > > I was just looking at the extensions/pref/autoconfig/ directory and
> trying
> > > to understand what it does.
> > >
> > > As far as I can tell, the code is there to allow custom deployments
> with
> > > particular prefs set, as described at
> > > https://developer.mozilla.org/en-US/Firefox/Enterprise_
> deployment#Configuration
> > >
> > > It's initialized by modules/libpref/Preferences.cpp if a
> > > "general.config.filename" pref is found:
> > > http://searchfox.org/mozilla-central/rev/
> 1ebd2eff44617df3b82eea7d2f3ca1b60cc591a0/modules/libpref/
> Preferences.cpp#3907-3920
> > >
> > > There is also some MozHarness code relating to it here:
> > > http://searchfox.org/mozilla-central/source/testing/
> mozharness/mozharness/mozilla/firefox/autoconfig.py
> > >
> > > Just to check: is this still supported functionality?
> > >
> > > Thanks.
> > >
> > > Nick
> >
> > Yes, this is very much supported functionality. It is our primary means
> of enterprise customization right now.
> >
> > The reason there are very few tests is because when it was first
> developed, it wasn't possible to write tests that involved putting down
> files before startup. There are some tests now:
> >
> > http://searchfox.org/mozilla-central/source/extensions/
> pref/autoconfig/test/unit
> >
> > Mike Kaply
>
> ___
> 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