823368 - Add UA overrides for top Venezuela sites

Status: RESOLVED DUPLICATE of bug 823364

(Firefox OS Graveyard :: Gaia, defect)

Description

[Lawrence Mandel [:lmandel] (use needinfo)]

Attachment: Venezuela UA override candidate list

Note: This bug should remain confidential until Venezuela has been publicly announced as a target market for B2G.

Attached is a candidate list of 13 of the Alexa top 100 Venezuela sites for the B2G UA whitelist. This list of 13 sites was determined via screenshot comparison of the sites with the Firefox for Android, Firefox OS, and Android Stock UAs. Sites that are already included in bug 819210, bug 823364, and bug 823365 are omitted here.

Our goal is to create a recommended list of top Venezuela sites for the UA whitelist.

There are 3 actions:

1. Smoke test each of these sites, preferably on B2G, with a spoofed UA to ensure that with the UA override the site appearance is improved and the site is mostly functional. Non primary function, like a vertically scrollable list of posters/images or function buried deep within the site, should not block a smoke test from passing.

2. Add the UA overrides to Gaia.

3. Open an evangelism bug for each site that is added to the UA override list in order to track the work required to remove a site from the list.

Legend for the attachment:
(Android UA) = This site requires the Android stock UA to get mobile content
(better content with Android UA) = This site receives mobile content with the Fennec UA but better mobile content with the Android stock UA
(nsfw) = not safe for work (this is an adult site)

Comment 1

[Aaron Train [:aaronmt]]

I have added these to the user-agent override investigation spreadsheet for tracking.

Comment 2

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB-, tracking-b2g+, please renom if there is major user impact

Comment 3

[Jason Smith [:jsmith]]

(In reply to Joe Cheng from comment #2)
> Triage: BB-, tracking-b2g+, please renom if there is major user impact

The user impact is pretty obvious here - many top sites won't work. This was a requirement by product as well. Back into triage it goes.

Comment 4

[David Scravaglieri [:scravag]]

The target market is Brasil, we don't block on this.

Comment 5

[Jason Smith [:jsmith]]

(In reply to David Scravaglieri [:scravag] from comment #4)
> The target market is Brasil, we don't block on this.

No. Chris Lee confirmed that the target market isn't just Brazil. There's other involved here. That's the point of why we filed bugs for these UA overrides - they represent each market to our understanding. Into triage it goes again.

Comment 6

[Tony Chung [:tchung]]

Jason, any bugs that are post C3, but still valid for v1.0, will no longer use blocking-basecamp flag. instead, it is replaced by tracking-b2g18 flag.   We'll want these override bugs for non-brazil to get tracking-b2g18+'d.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Tony Chung [:tchung] from comment #6)
> Jason, any bugs that are post C3, but still valid for v1.0, will no longer
> use blocking-basecamp flag. instead, it is replaced by tracking-b2g18 flag. 
> We'll want these override bugs for non-brazil to get tracking-b2g18+'d.

Wrong. Last time I checked, triage is still going on. So that argument doesn't make sense to me.

Comment 8

[Tony Chung [:tchung]]

(In reply to Jason Smith [:jsmith] from comment #7)
> (In reply to Tony Chung [:tchung] from comment #6)
> > Jason, any bugs that are post C3, but still valid for v1.0, will no longer
> > use blocking-basecamp flag. instead, it is replaced by tracking-b2g18 flag. 
> > We'll want these override bugs for non-brazil to get tracking-b2g18+'d.
> 
> Wrong. Last time I checked, triage is still going on. So that argument
> doesn't make sense to me.

jason, this example is -'d.  Triage has discussed it, and this is the consensus made - even after your arguments have been said.   venezuela is not a target site that our partners need before we package on jan 15th.  only brazil is, from what partners and product is telling me.   

we need to take this discussion offline as there's obviously a disconnect with the nominations.   flipflopping this discussion has now become a distraction to this bug and not relevant.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Tony Chung [:tchung] from comment #8)
> (In reply to Jason Smith [:jsmith] from comment #7)
> > (In reply to Tony Chung [:tchung] from comment #6)
> > > Jason, any bugs that are post C3, but still valid for v1.0, will no longer
> > > use blocking-basecamp flag. instead, it is replaced by tracking-b2g18 flag. 
> > > We'll want these override bugs for non-brazil to get tracking-b2g18+'d.
> > 
> > Wrong. Last time I checked, triage is still going on. So that argument
> > doesn't make sense to me.
> 
> jason, this example is -'d.  Triage has discussed it, and this is the
> consensus made - even after your arguments have been said.   venezuela is
> not a target site that our partners need before we package on jan 15th. 
> only brazil is, from what partners and product is telling me.  

A past email cites the following that talked about the goal being:

"Full functionality on the sites representing N% of all mobile device page views in each of the 5 P1 markets (Brazil, Colombia, Venezuela, Poland, Spain)."

So I still stand to say that your argument does not align with the above statement. Venezuela is a target P1 market.
 
> 
> we need to take this discussion offline as there's obviously a disconnect
> with the nominations.   flipflopping this discussion has now become a
> distraction to this bug and not relevant.

That is not what the basecamp+ flag was supposed to be used for. Evidently the Gaia team is using the flag quite differently than how the platform team is using it - it was supposed to be what was needed to call software complete on device. It was not what you just described. So yeah, there is a disconnect on process here, and honestly, your argument still makes no sense, as we do need to track exactly what is stop ship on device. The tracking flag more exists as a path to ensuring that we mark things that we definitely want to fix, but won't block on. But there's the case of needing to still track what's stop ship. This definitely falls in that category as stated in the above statement. I'm not taking no for an answer on not blocking on this given that we know that this is a target P1 market unless I see evidence that we do not have plans to go to market in this country.

I want to see in writing exactly where this process definition changed or I stand to believe that your argument is incorrect. Especially after an email put out not too long ago that complained about the fact that Gaia team is using a "dump and run" strategy to throw out blocker bugs, I'm inclined to think that the Gaia triage group is the one at fault for making questionable triage decisions in comparison to seeing how the platform team is triaging.

I want a response to the above statement about the P1 markets. Otherwise, I think argument lacks enough justification to not block.

Comment 10

[Jason Smith [:jsmith]]

Perhaps Lawrence can shed some light on my concerns, as I'm clearly not getting the answer out of the Gaia triage sessions.

Comment 11

[Gervase Markham [:gerv]]

In the amount of time taken to have this discussion, the patch for all 3 bugs could have been written and checked in twice...

Is this argument about what's important to work on, or about which patches will be accepted? (I don't know the semantics of the particular flags.) If it's about priorities, then someone should just spend 10 minutes and make the patch. If no-one has by tomorrow morning UK time, I will.

Gerv

Comment 12

[Jason Smith [:jsmith]]

(In reply to Gervase Markham [:gerv] from comment #11)
> In the amount of time taken to have this discussion, the patch for all 3
> bugs could have been written and checked in twice...
> 
> Is this argument about what's important to work on, or about which patches
> will be accepted? (I don't know the semantics of the particular flags.) If
> it's about priorities, then someone should just spend 10 minutes and make
> the patch. If no-one has by tomorrow morning UK time, I will.

Importance. The equivalent bug for this in the preloaded apps story in bug 815520 labels itself as a basecamp+ that talks about implementation prep work in the releng space. I'd state this would fall under that same category. Unless lmandel can explain the distinguishing difference.

But yeah, I hear your point. We are taking more time to argument over this rather than taking the 10 minutes to get the patch out.

Comment 13

[Jason Smith [:jsmith]]

I'll hold off on the renom until I get the response.

Also - see bug 817044 which cites examples of target markets we're hitting for v1.

Comment 14

[Lawrence Mandel [:lmandel] (use needinfo)]

There is clearly some confusion about the target markets that are important for our code complete date. While we can (and probably should) clarify the target, in any case, I don't think that we will hold the release for this change. Marking as a non blocker simply means that this group of bugs isn't tracked during triage. It doesn't mean that this work won't land. These bugs can be marked b2g18+. I expect that we can land these patches very shortly after QA completes the verification step for the candidate list.

We do not need significant additional engineering effort to fix these bugs. I will create the patches for these bugs after QA verifies that the overrides do indeed result in functional sites.

Comment 15

[Jason Smith [:jsmith]]

(In reply to Lawrence Mandel [:lmandel] from comment #14)
> There is clearly some confusion about the target markets that are important
> for our code complete date. While we can (and probably should) clarify the
> target, in any case, I don't think that we will hold the release for this
> change. Marking as a non blocker simply means that this group of bugs isn't
> tracked during triage. It doesn't mean that this work won't land. These bugs
> can be marked b2g18+. I expect that we can land these patches very shortly
> after QA completes the verification step for the candidate list.

Can you clarify why we don't need to block on the UA overrides then? I thought this was a critical v1 requirement to have "good" compatibility. Is it cause we can still do outreach independently of the override even past a ship date (e.g. process workarounds)?

Comment 16

[Lawrence Mandel [:lmandel] (use needinfo)]

You make a good point. My point is, if this was the last bug preventing us from shipping, we wouldn't hold the release for a fix. 

This really is an academic argument at this point as the UA override bugs will land within the next week or so. I'm happy to go basecamp+ or b2g18+ at this point.

Comment 17

[Jason Smith [:jsmith]]

(In reply to Lawrence Mandel [:lmandel] from comment #16)
> You make a good point. My point is, if this was the last bug preventing us
> from shipping, we wouldn't hold the release for a fix. 
> 
> This really is an academic argument at this point as the UA override bugs
> will land within the next week or so. I'm happy to go basecamp+ or b2g18+ at
> this point.

Okay, makes sense. Thanks for the clarification.

Comment 18

[Tony Chung [:tchung]]

(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Tony Chung [:tchung] from comment #8)
> > (In reply to Jason Smith [:jsmith] from comment #7)
> > > (In reply to Tony Chung [:tchung] from comment #6)
> > > > Jason, any bugs that are post C3, but still valid for v1.0, will no longer
> > > > use blocking-basecamp flag. instead, it is replaced by tracking-b2g18 flag. 
> > > > We'll want these override bugs for non-brazil to get tracking-b2g18+'d.
> > > 
> > > Wrong. Last time I checked, triage is still going on. So that argument
> > > doesn't make sense to me.
> > 
> > jason, this example is -'d.  Triage has discussed it, and this is the
> > consensus made - even after your arguments have been said.   venezuela is
> > not a target site that our partners need before we package on jan 15th. 
> > only brazil is, from what partners and product is telling me.  
> 
> A past email cites the following that talked about the goal being:
> 
> "Full functionality on the sites representing N% of all mobile device page
> views in each of the 5 P1 markets (Brazil, Colombia, Venezuela, Poland,
> Spain)."
> 
> So I still stand to say that your argument does not align with the above
> statement. Venezuela is a target P1 market.
>  
I never said Venezuela isn't a target P1 market.  i said it's not a priority to land before Jan 15th. (if you're wondering why Jan 15th is so important, lets talk offline - but i thought you already knew)  I also said that the tracking-b2g18 flag is there to track any bugs in triage that Jan 15 < X days < Final shipping of v1.0.   There are still going to be opportunities for approving bugs that come after the c3 milestone, but it will need more justification from triage/ partners/ others.   And i agree that this override work for the other venezuela, colombia, and spain markets fall in this category.   


> > 
> > we need to take this discussion offline as there's obviously a disconnect
> > with the nominations.   flipflopping this discussion has now become a
> > distraction to this bug and not relevant.
> 
> That is not what the basecamp+ flag was supposed to be used for. Evidently
> the Gaia team is using the flag quite differently than how the platform team
> is using it - it was supposed to be what was needed to call software
> complete on device. It was not what you just described. So yeah, there is a
> disconnect on process here, and honestly, your argument still makes no
> sense, as we do need to track exactly what is stop ship on device. The
> tracking flag more exists as a path to ensuring that we mark things that we
> definitely want to fix, but won't block on. But there's the case of needing
> to still track what's stop ship. This definitely falls in that category as
> stated in the above statement. I'm not taking no for an answer on not
> blocking on this given that we know that this is a target P1 market unless I
> see evidence that we do not have plans to go to market in this country.
> 
> I want to see in writing exactly where this process definition changed or I
> stand to believe that your argument is incorrect. Especially after an email
> put out not too long ago that complained about the fact that Gaia team is
> using a "dump and run" strategy to throw out blocker bugs, I'm inclined to
> think that the Gaia triage group is the one at fault for making questionable
> triage decisions in comparison to seeing how the platform team is triaging.

I think this is where the communication breakdown lies.  Alex keybl did define this in an email, but it looks like it only went to b2g-release-drivers.   

* tracking-b2g18. This flag is used similarly to tracking-esr17 and is meant to specifically track major stability/security/usability that we'd like to fix int he v1x timeframe. The value can either be set to + (generically tracked) or for a specific 6-week cycle (19+, 20+, etc.). It's been proposed that tracking-b2g-v1x may be a better flag, as it pertains to both Gecko and Gaia.
* status-b2g18. This flag is used similarly to status-esr17 and is meant to track whether a fix has been landed on v1x release branches. It's been proposed that status-b2g-v1x may be a better flag, as it pertains to both Gecko and Gaia.

I'm told that he'll be sending something to the whole world soon.   So you have every right to question why things changed when you never got the memo.

> 
> I want a response to the above statement about the P1 markets. Otherwise, I
> think argument lacks enough justification to not block.

Comment 19

[Gervase Markham [:gerv]]

(In reply to Gervase Markham [:gerv] from comment #11)
> In the amount of time taken to have this discussion, the patch for all 3
> bugs could have been written and checked in twice...

This may have been a little hasty given that, if Lawrence's patch for bug 819210 is anything to go by, each site needs careful testing to determine the best UA and that process has not yet been done. It's not just as case (as I thought it was) of copy-pasting and slapping the Fennec UA on all of them. Apologies.

Gerv

Comment 20

[Aaron Train [:aaronmt]]

Lawrence - override recommendations completed in the investigation spreadsheet.