1600120 - Provide a FeatureGate module based on prefs topology

Status: RESOLVED INVALID

(Toolkit :: FeatureGate, task)

Description

[Mike de Boer [:mikedeboer]]

So I just figured out there's already a FeatureGate component, so I'm filing this here so that more people can follow along.

So the Search & Navigation team implements every change behind a pref, or everything is feature-gated.

If we don't start adopting a standardized method of organizing preferences in such a way that

1. Dog-fooding of these changes doesn't become a pain,
2. We are able to develop and reconfigure changes/ features during runtime,
3. We are able to distribute changes to specific channels and platforms.

And all these things should preferably be captured in a single pref value that is easy to change by hand for non-engineers. After all, dog-fooding is something that should be possible for all members of a team. And many of them are not coders, after all.

I'll post a proposed patch up here, before I trick myself into spending more time on it.

Example topology:

feature1                                  4
feature1.feature11                        4
feature1.feature11.feature12              4
feature1.feature11.feature13              4
feature1.feature11.feature14              4
feature1.feature11.feature15              1
feature1.feature11.feature15.feature151   4
feature1.feature11.feature15.feature152   4
feature1.feature11.feature15.feature152   1

4. Means that the feature may be enabled on DEBUG_BUILDs and
5. means that the feature may be used on RELEASE_OR_BETA builds, or lesser channels.

Now consider changing 'feature1' to 1. This has the effect that ALL features in this example may be used on RELEASE_OR_BETA builds, or lesser channels in one go. This is unlikely to happen in practice, but illustrates the effect nicely.

Anyone can start dogfooding specific features or entire branches of them by simply setting the desired feature pref to a 1 in about:config.

In code, you'd opt-in to using this module as follows:

class URLBarInput {
  constructor()  {
    this.features = new FeatureGate("browser.urlbar");
    this.features.on("update", (eventName, feature) {
      if (feature == "update1.newAwesomeness") {
        this.render();
      }
    });
  }

  render() {
    if (this.features.canIUse("update1.newAwesomeness")) {
      // Do something...
    }
  }
}

Comment 1

[Mike de Boer [:mikedeboer]]

Attachment: Bug 1600120 - Provide a FeatureGate module based on prefs topology. r?Standard8,mak,dao

Example topology:

feature1                                  4
feature1.feature11                        4
feature1.feature11.feature12              4
feature1.feature11.feature13              4
feature1.feature11.feature14              4
feature1.feature11.feature15              1
feature1.feature11.feature15.feature151   4
feature1.feature11.feature15.feature152   4
feature1.feature11.feature15.feature152   1

4. Means that the feature may be enabled on DEBUG_BUILDs and
5. means that the feature may be used on RELEASE_OR_BETA builds, or lesser channels.

Now consider changing 'feature1' to 1. This has the effect that ALL features
in this example may be used on RELEASE_OR_BETA builds, or lesser channels in one
go. This is unlikely to happen in practice, but illustrates the effect nicely.

Anyone can start dogfooding specific features or entire branches of them by
simply setting the desired feature pref to a 1 in about:config.

In code, you'd opt-in to using this module as follows:

class URLBarInput {
  constructor()  {
    this.features = new FeatureGate("browser.urlbar");
    this.features.on("update", (eventName, feature) {
      if (feature == "update1.newAwesomeness") {
        this.render();
      }
    });
  }

  render() {
    if (this.features.canIUse("update1.newAwesomeness")) {
      // Do something...
    }
  }
}

Comment 2

[Mark Banner (:standard8)]

Could we not also adopt the current Feature Gate work and make that work so that developers/testers can toggle things easily?

Comment 3

[Mike de Boer [:mikedeboer]]

Yeah, I have to reply to :mythmon about that, since he kindly reached out to me the other day.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:mythmon, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 5

[Michael Cooper [:mythmon]]

Benson, since at the time this bug was filed I was working with you, I'm going to foist this upon you to figure out what to do with. I think I got need infoed because I'm the triage owner for this component. That's also weird, and I'm going to figure out how to stop doing that.

Comment 6

[Benson Wong [:mostlygeek]]

Seems like we only have these choices:

• close this bug
• find a new owner
• do nothing

With the nimbus project, adding feature-gates seem like a conflicting feature. I'm going to close this and if anyone disagrees we can reopen and discuss again in the future.