My thanks to everyone who had commented on this so far. I’m replying to
your questions and comments in this email so that we don’t have a threading
catastrophe.
First, several of you mentioned the typo where I wrote qa-verify when the
flag is qe-verify. The policy document has the correct flag nam
I have a bug that will introduce a pref/feature-flag, but that is just one
bug that blocks a meta bug. The meta bug covers the whole feature.
Should these flags get set on the meta bug or on the bug that introduces
the pref? Testing the specific bug that introduces the pref won't provide
much cove
On 03/05/2018 00:57, Emma Humphries wrote:
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 +
On Thu, May 3, 2018 at 11:57 AM, Adam Roach wrote:
> On 5/3/18 12:18 PM, Nicholas Alexander wrote:
>>
>> Not all features are feasible to ship behind feature flags.
>
>
> I'm pretty sure the proposed policy isn't intended to change anything
> regarding features that ship without associated feature
On 5/3/18 12:18 PM, Nicholas Alexander wrote:
Not all features are feasible to ship behind feature flags.
I'm pretty sure the proposed policy isn't intended to change anything
regarding features that ship without associated feature flags, nor is it
trying to get more features to ship behind f
On Wed, May 2, 2018 at 4:57 PM, Emma Humphries 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
6 matches
Mail list logo
