<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 2, 2018 at 4:57 PM, Emma Humphries <span dir="ltr"><<a href="mailto:emma@mozilla.com" target="_blank">emma@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">Hello, <br></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">We control enabling many features and changes to Firefox using preferences.<br></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">Program and Release management as well as PI need a better view of this.</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif"> We've written a new policy which you can read on our nascent bug-handling mini-site:</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif"><a href="https://github.com/mozilla/bug-handling/blob/master/policy/feature-flags.md" target="_blank">https://github.com/mozilla/<wbr>bug-handling/blob/master/<wbr>policy/feature-flags.md</a></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">To summarize, when you are releasing a feature that "rides behind a flag", on the bug for the feature:<br></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">* set the behind-pref flag to +</div><div style="font-family:arial,helvetica,sans-serif">* set the qa-verify flag to ?</div><div style="font-family:arial,helvetica,sans-serif">* note the bug in the Firefox Feature Trello board</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">We expect qa-verify to be set to + before enabling prefs on features.<br></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">We'll be going over this at two upcoming meetings, with Reese's and JoeH's teams. <br></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">There are two, known open questions to resolve on the policy:</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">* 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<br></div><div style="font-family:arial,helvetica,sans-serif">* 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?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Nick<br></div><div><br></div></div></div></div>