On Wed, May 2, 2018 at 4:57 PM, Emma Humphries <e...@mozilla.com> wrote:
> Hello, > > We control enabling many features and changes to Firefox using preferences. > > Program and Release management as well as PI need a better view of this. > > We've written a new policy which you can read on our nascent bug-handling > mini-site: > > https://github.com/mozilla/bug-handling/blob/master/ > policy/feature-flags.md > > To summarize, when you are releasing a feature that "rides behind a flag", > on the bug for the feature: > > * set the behind-pref flag to + > * set the qa-verify flag to ? > * note the bug in the Firefox Feature Trello board > > We expect qa-verify to be set to + before enabling prefs on features. > > We'll be going over this at two upcoming meetings, with Reese's and JoeH's > teams. > > There are two, known open questions to resolve on the policy: > > * Features developed over multiple releases with individual patches not > verifiable by external testing (passing unit tests, but not integration > tests) such as Hello and WebRTC > * Features are often turned on in Nightly, ignoring prefs using compiler > directives, and kept off in Beta and Release. Is this the right thing to > do, or should we be flipping prefs from on to off when going from Nightly > to Beta and forwards? > Not all features are feasible to ship behind feature flags. Fennec features that interact with the OS directly, in particular, can sometimes just be all or nothing; and I would anticipate that things that interact directly with newer App stores (iOS features, say, or Windows Store features in the future) will become more common. We can't have a policy that fights against that trend. Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
