900194 - Reference workload calendars don't work with v1-train calendars

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Calendar, defect)

Description

[Jon Hylands [:jhylands]]

After creating reference workload calendars, they were tested on both master and v1-train devices. They work properly on master devices, but fail on v1-train.

Comment 1

[Jon Hylands [:jhylands]]

light - https://www.dropbox.com/s/mpfim0flskgg62k/calendar-1.sqlite 
medium - https://www.dropbox.com/s/ywast972byf62lj/calendar-2.sqlite 
heavy - https://www.dropbox.com/s/h4v5osj82eg64we/calendar-3.sqlite 
x-heavy - https://www.dropbox.com/s/fnow1qsf4qndh1c/calendar-4.sqlite

Comment 2

[Mike Lee [:mlee]]

James,
Is anyone on the Calendar actively working on this bug? It's blocking completion of our Calendar Reference Workload bug 867320 needed to for testing Calendar's performance under various loads.

Comment 3

[Mike Lee [:mlee]]

James, see comment #2. Who's working on this bug?

Comment 4

[James Lal [:lightsofapollo]]

Do we need to fix this for v1-train? Ganesh's import work is going to land in master but nowhere else. I am not clear on why its important to get this working on v1-train now that we have been at a "critical fix only" phase for fairly long period of time.

On a general note if I asked you to assign this to me I am sorry but in general please don't assign people to bugs it will sit in my queue behind the other work I assigned myself (not out of malice).

Comment 5

[Mike Lee [:mlee]]

Hi James,

We need this fixed for v1-train so we can collect calendar performance data using specific workloads. We'll use that data to confirm, identify, and set priority for areas not meeting performance goals in v1-train.

Jon assigned this to you based on one or more conversations he had with you re: this being a blocker for the calendar reference workload work he's trying to complete via bug 867320. I needinfo'd you to confirm who if you or anyone else was actually working on this.

Mike

Comment 6

[James Lal [:lightsofapollo]]

So a big part of this issue is that we are relying on soon to be landed work on 1.2 to generate the databases. There are a few ways to fix this in theory.

- base the import patch on v1-train and land it there (this is highly unlikely right now given the state of v1-train and the high risk of the patch)

- apply Ganesh's work directly on a local copy of v1-train (possible but high probability of conflicts)

Nothing is impossible and I am sorry for keeping this outstanding but as I see it this still does not block reference workloads for master. If this is a critical issue we will prioritize it accordingly and get someone to resolve this.

Comment 7

[Jon Hylands [:jhylands]]

Hi James,

This does not require Ganesh's work to be landed on v1-train. I use his patch to generate the database, but the issue here is that the database that I generate does not work with phones running b2g18/v1-train.

Comment 8

[James Lal [:lightsofapollo]]

Hey John, 

What branch do you run his code on top of? If you directly checked out his work its somewhere on master (which probably only works on master). In theory if you apply his work to v1-train then it should work on v1-train + master.

Comment 9

[Jon Hylands [:jhylands]]

I only ran it on master, but the database version is the same between master and v1-train, so the generated database should in theory work on both.

Comment 10

[Jon Hylands [:jhylands]]

After talking to James Lal and Ben Turner about this, it turns out that although the database schema version is the same, the internal structure of IndexedDB has changed between b2g18 and m-c, so this will not work unless we generate the database on v1-train.

In order to generate the database on v1-train, we would need Ganesh's patch for importing iCal data to be ported from master to v1-train, which is also not likely to happen.