Closed Bug 406579 Opened 12 years ago Closed 8 years ago

Update story for timezone database

Categories

(Calendar :: Build Config, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dbo, Assigned: Fallen)

References

Details

Attachments

(1 file, 3 obsolete files)

There's an idea to provide the timezone database using an xpi, so users could upgrade it between two calendar releases.

Sunbird could preinstall that xpi while lightning could be build as a composite xpi: { lightning-core.xpi, tz-database.xpi, [maybe providers] }.

However we need to check out the update process, whether lightning-core could still be updated (including the top-notch timezones database).
Flags: wanted-calendar0.8+
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Flags: wanted-calendar0.8- → wanted-calendar0.9+
Flags: blocking-calendar0.9?
We won't ship a bundled calendar-timezones.xpi with lightning in 0.9.
Flags: blocking-calendar0.9? → blocking-calendar0.9-
If calendar is going to be integrated into Thunderbird, a top-notch calendar-timezones.xpi should be bundled/preinstalled in Thunderbird.
Flags: wanted-calendar1.0+
Flags: wanted-calendar0.9+
Flags: tb-integration?
Flags: blocking-calendar0.9-
Flags: tb-integration? → tb-integration+
(In reply to comment #4)
> If calendar is going to be integrated into Thunderbird, a top-notch
> calendar-timezones.xpi should be bundled/preinstalled in Thunderbird.

Presumably you mean so it can be upgraded between releases? If so we need to check out the update story for all this things.
Priority: -- → P2
While I think we do want something that's shippable outside of the release cycles, it seems to me that we could probably get away without it in the short-term: we'd just use minor release vehicles to ship new timezones if they seem to be of critical importance.  I'm going to set back to tb-integration? and ask for thoughts from davida and Standard8 here...
Flags: tb-integration+ → tb-integration?
Attached patch proposal - v1 (obsolete) — Splinter Review
This patch proposal
- rips out the timezone bits out of lightning.xpi
- removes DISABLE_LIGHTNING_INSTALL, thus preinstalls on Thunderbird; xxx todo: check whether this is ok for Seamonkey
- preinstalls calendar-timezones.xpi
- adds a dependency on timezones.xpi to lightning.xpi (but not lightning-sunbird-stub).
Comment on attachment 347751 [details] [diff] [review]
proposal - v1

Although we're yet not ready for calendar integration: Philipp/Ause, could you please comment on this patch?
Attachment #347751 - Flags: review?(philipp)
Attachment #347751 - Flags: review?(ause)
Comment on attachment 347751 [details] [diff] [review]
proposal - v1

given that DISABLE_LIGHTNING_INSTALL gets obsoleted, the build stuff looks ok to me. no idea about the .js changes
Attachment #347751 - Flags: review?(ause) → review+
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
adding kairo for the SeaMonkey related topics
Attached patch proposal - v2 (obsolete) — Splinter Review
updated
Attachment #347751 - Attachment is obsolete: true
Attachment #348561 - Flags: review?(philipp)
Attachment #347751 - Flags: review?(philipp)
Depends on: 355927
Attachment #348561 - Flags: review?(philipp) → review+
Comment on attachment 348561 [details] [diff] [review]
proposal - v2


>diff --git a/calendar/lightning/install.rdf b/calendar/lightning/install.rdf
>--- a/calendar/lightning/install.rdf
>+++ b/calendar/lightning/install.rdf
>+    <em:requires>
>+      <Description>
>+        <em:id>calendar-timezones@mozilla.org</em:id>
>+        <em:minVersion>@TIMEZONES_VERSION@</em:minVersion>
>+        <em:maxVersion>0.1.*</em:maxVersion>
>+      </Description>
>+    </em:requires>
>+
...
>+    <em:locked>true</em:locked>
>+    <em:appManaged>true</em:appManaged>
Why is lightning locked and app managed?


r=philipp
(In reply to comment #12)
> >+    <em:locked>true</em:locked>
> >+    <em:appManaged>true</em:appManaged>
> Why is lightning locked and app managed?

My thoughts behind this were: Lightning updates only come with every update of Thunderbird(/Seamonkey?) and users should not be able to update nor uninstall the extension, but could disable it.
Clearly we need a story, so marking +
Flags: tb-integration? → tb-integration+
Whiteboard: [patch in hand]
Attached patch updated proposal - v3 (obsolete) — Splinter Review
updated due to version change in bug 474632
Attachment #359272 - Flags: review+
Attachment #348561 - Attachment is obsolete: true
Daniel, how should we proceed with the timezone database update story? Is your last patch ready for checkin, or are there open issue which need to be discussed?
The patch depends on tb-integration. It isolates the timezone bits out of lightning, thus it would require users install both lightning.xpi and timezones.xpi. I don't think we want this, so we could leave this work as is for now.
As the tb-integration never landed, this bug is somewhat orphaned, though there would be a patch ready at hand. I believe it would be advantageous to have a timezones update more frequently for some reasons:

1. minor timezone updates happen pretty often, and those involved (though a minority) experience substantial drawbacks, as their times are off, or they have to choose a different timezone that is not really theirs

2. multi-boot-scenarios, that share a common local.sqlite calendar file - I have such a thing: TB/Lightning updates will land on different dates on each system, and the one behind has serious trouble, as lightning silently ignores calendars that have a more recent version in cal_tz_version. Having recent timezones on all systems (they are architecture independent, aren't they?) would avoid such problems

So I strongly vote for a separate timezones package as the proposed patch would create, and to create a (semi-) automated packaging system that provides an updated xpi shortly after an Olsen update - it would not bind man power on the long run as I see it, wouldn't it?
One thing we need to fix in this bug is to allow timezone downgrades and make sure that translating the strings for the timezones is not required. This patch takes care.

Previously, the downgrade was stopped with an exception, but from testing between 2011b, 2011g and 2011n I couldn't find any negative side effects to allowing the downgrade.
Assignee: dbo.moz → philipp
Attachment #359272 - Attachment is obsolete: true
Attachment #572847 - Flags: review?
Attachment #572847 - Flags: review? → review?(mschroeder)
Comment on attachment 572847 [details] [diff] [review]
Allow timezone downgrades - v1

Looks good. r=mschroeder
Attachment #572847 - Flags: review?(mschroeder) → review+
I think we should close this bug after pushing the patch, the extension should "just work" in the future and if not then we can file other bugs. If we at some point are integrated by default, then we can rethink appManaged/locked
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/fb100e360ac6>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.3
I'm pushing this to comm-beta to make sure we can release the timezone extension sooner.

releases/comm-aurora changeset 64561e066845
releases/comm-beta changeset 45c318d270ea
Whiteboard: [patch in hand]
Target Milestone: 1.3 → 1.1
You need to log in before you can comment on or make changes to this bug.