972034 - Disable rocketbar on Gaia builds used on pvtbuilds

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Jason Smith [:jsmith]]

Disable the rocketbar on Gaia builds used on pvtbuilds temporarily until we get a more stable UX for rocketbar. This is done to unblock e.me testing & allow UI automation to remain up and running for e.me.

Comment 1

[Kevin Grandon :kgrandon]

We can disable rocketbar by passing in an additional flag to the gaia build. By default, ROCKETBAR is set to half, we should set it to none instead.

E.g., if you would normally build with: MOZILLA_OFFICIAL=1 make, you would instead build with ROCKETBAR=none MOZILLA_OFFICIAL=1 make.

Comment 2

[Jason Smith [:jsmith]]

(In reply to Kevin Grandon :kgrandon from comment #1)
> We can disable rocketbar by passing in an additional flag to the gaia build.
> By default, ROCKETBAR is set to half, we should set it to none instead.
> 
> E.g., if you would normally build with: MOZILLA_OFFICIAL=1 make, you would
> instead build with ROCKETBAR=none MOZILLA_OFFICIAL=1 make.

It's probably going to be easier if we do on the Gaia side, rather than rel side, as we control the commit to enable & disable here off the default build logic we use.

Can we just switch the default for ROCKETBAR to be none for now until the UX stabilizes?

Comment 3

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #2)
> (In reply to Kevin Grandon :kgrandon from comment #1)
> > We can disable rocketbar by passing in an additional flag to the gaia build.
> > By default, ROCKETBAR is set to half, we should set it to none instead.
> > 
> > E.g., if you would normally build with: MOZILLA_OFFICIAL=1 make, you would
> > instead build with ROCKETBAR=none MOZILLA_OFFICIAL=1 make.
> 
> It's probably going to be easier if we do on the Gaia side, rather than rel
> side, as we control the commit to enable & disable here off the default
> build logic we use.
> 
> Can we just switch the default for ROCKETBAR to be none for now until the UX
> stabilizes?

Kevin had other ideas for a solution, but I've realized that we actually need to do this specific solution here - if we don't, then we'll run into problems where our problems where our partners will be running different builds than we are. We need to make sure the default is the same across our build processes, which means rocketbar should be off by default.

Comment 4

[Kevin Grandon :kgrandon]

There are many stakeholders involved with Rocketbar, and it's not something I can make the decision to do alone. I will setup a meeting to discuss this with you and all necessary stakeholders as soon as possible.

Comment 5

[Jason Smith [:jsmith]]

(In reply to Kevin Grandon :kgrandon from comment #4)
> There are many stakeholders involved with Rocketbar, and it's not something
> I can make the decision to do alone. I will setup a meeting to discuss this
> with you and all necessary stakeholders as soon as possible.

Okay - include Clint & Tony on this as well.

Comment 6

[Tony Chung [:tchung]]

(In reply to Kevin Grandon :kgrandon from comment #4)
> There are many stakeholders involved with Rocketbar, and it's not something
> I can make the decision to do alone. I will setup a meeting to discuss this
> with you and all necessary stakeholders as soon as possible.

Hi Kevin, Preffing the feature off on our production builds for trunk, and re-enabling our existing automation tests to execute correctly is mandatory for QA testing.   This is a policy that we've brought up to the group many times and signed off that both daily manual and automation testing should pass legitimately.  If the automation test xfails, we will work on fixing those tests.  But disabling tests because a new feature is enabled and known to fail them is not how we are going to stabilize a development tree.

Please pref this off for now, and you can re-enable the feature when internal testing has stabilized.   If someone needs to see rocketbar (ie. UX, product, whoever), there's always the option to special build it with the pref enabled.   

Thanks for cooperating!

Comment 7

[Kevin Grandon :kgrandon]

We can certainly do that, but there may be other options here to consider as well. For instance, we can have the homescreen searchbar return to its former state while rocketbar exists. This way all existing automation tests pass, and manual smoketests should as well.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Kevin Grandon :kgrandon from comment #7)
> We can certainly do that, but there may be other options here to consider as
> well. For instance, we can have the homescreen searchbar return to its
> former state while rocketbar exists. This way all existing automation tests
> pass, and manual smoketests should as well.

The problem with that approach is that puts a band aid on the real issue here that will only last for a small period of time. There's other UX flux happening as well (notifications UX being redone, more rocketbar UX, etc), so as soon as another flux point lands, we end up with the same problem with a different set of UI automated tests.

Comment 9

[Kevin Grandon :kgrandon]

I don't see how this is a band-aid fix, as it allows both of us to move forward with our goals? It would be a shame if there were *zero* compromise here and there were no way to iteratively work on features. That kind of thinking is only going to cause larger regressions down the road when you have to crash land everything at once.

I can go ahead and take this and start working on a patch though.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Kevin Grandon :kgrandon from comment #9)
> I don't see how this is a band-aid fix, as it allows both of us to move
> forward with our goals? It would be a shame if there were *zero* compromise
> here and there were no way to iteratively work on features. That kind of
> thinking is only going to cause larger regressions down the road when you
> have to crash land everything at once.

Well, the iterative nature can still happen here - you can still develop on trunk, except the features are only enabled when the rocketbar preference is set. If there's concern about the fallout risk from the rocketbar work, then that can easily be mitigated by doing focused feature test runs with the pref set as needed to detect regressions & bad feature bugs. When we sign off on these feature test runs, then we can pref on by default. This process is similar to what we did for APZC, which proved to work quite well.

Note - The UX flux poses more risks than automated tests problem. It also creates confusion on state of the world of what works vs. doesn't - for example, a lot of QAs were confused on why adding e.me apps to the homescreen wasn't working anymore. A QA's immediate reaction is to file bugs & raise them as high priority, even though in reality, the support might have not been implemented in the new UX. This ends up creating noise for a development team, as they get hit by bugs on issues that are expected to not be working right now.

Comment 11

[Kevin Grandon :kgrandon]

The E.me experience just got turned on in the search app: https://github.com/mozilla-b2g/gaia/commit/63e6d4c7aa2c63eed482e0faa3c4fcc0f44b4e7b

The original reason for this bug, "This is done to unblock e.me testing & allow UI automation to remain up and running for e.me." is now solved as we have a E.me UI and can enable the tests now. I will work with Zac and team to get these tests up again. I think it's better to start on updating the tests now, then waiting to land this last minute without them. The DOM/UI for the E.me experience should now be stable (with only slight styling tweaks in the future).

As implementation of testing should now be unblocked, I'm going to close this as wontfix. Thanks!