Hi all,
There are often times when we want to hook up features for testing that
we don't want exposed to the general user community.
In the past we have hooked things up in master, then when the release
branch is made, we have had to go and change things there. This is a
terrible way to do it.
I like the idea. Thinking out loud: do we want to combine this with the
wrench so that we have 1 consistent way to fiddle with Juju behavior?
On Tue, Nov 25, 2014 at 4:47 PM, Tim Penhey tim.pen...@canonical.com
wrote:
Hi all,
There are often times when we want to hook up features for testing
On Wed, Nov 26, 2014 at 6:47 AM, Tim Penhey tim.pen...@canonical.com
wrote:
Hi all,
There are often times when we want to hook up features for testing that
we don't want exposed to the general user community.
In the past we have hooked things up in master, then when the release
branch is
On 26/11/14 14:18, Andrew Wilkins wrote:
On Wed, Nov 26, 2014 at 6:47 AM, Tim Penhey tim.pen...@canonical.com
mailto:tim.pen...@canonical.com wrote:
Hi all,
There are often times when we want to hook up features for testing that
we don't want exposed to the general user
Given the constraints you just listed (globally set in the environment,
etc), why not just make it environment config, rather than yet-another-way
to set env config?
John
=:-
On Wed, Nov 26, 2014 at 5:22 AM, Tim Penhey tim.pen...@canonical.com
wrote:
On 26/11/14 14:18, Andrew Wilkins wrote:
I like feature flags so am +1 to the overall proposal. I also agree with the
approach to keep them immutable, given the stated goals and complexity
associated with making them not so.
I think the env variable implementation is ok too - this keeps everything very
loosely coupled and avoids
Because I explicitly wanted to avoid touching config.
We want a simple method for checking flags that can't fail. Dealing with
config doesn't give us that.
I don't think that using an environment variable to define feature flags
is too terrible. We don't want to make it too easy ;-)
Tim
On
