865276 - Remove ancient version of maps from gaia repo

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Donovan Preston [:fzzzy]]

The packaged version of maps in external-apps/m.here.com is very old, and requires updating from the marketplace immediately. This is a sub-optimal first run experience. A better strategy is to remove the maps app from the gaia repo, and if a carrier wants the maps app included in a release, they can add the latest maps app from the marketplace to the distribution just like they do for all other third party apps.

Comment 1

[Jason Smith [:jsmith]]

I don't think this is a good idea. When I talked with Karen about this, we wanted to move towards a model that would actually include common apps in the gaia repository by default that did not need to be confidential to push for better dogfooding. If we really have a problem with production builds, we can resolve it during the customization phase.

Comment 2

[Donovan Preston [:fzzzy]]

I disagree with including common apps in the gaia repo quite strongly.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Donovan Preston from comment #2)
> I disagree with including common apps in the gaia repo quite strongly.

Why?

Dogfooding is quite important to the successful of making sure preinstalls are working. If we take this out, we lose the dogfooding workflows for preinstalls, which will miss quite a lot of bugs.

I thought we already came to agreement with Karen and others that we were moving the other direction (putting dogfooding apps as part of the build). But apparently there's disagreement here.

Comment 4

[Donovan Preston [:fzzzy]]

The gaia repository is not the place to store external apps. the marketplace is the place for that. The gaia development process is in a code freeze right now and has a very strict process for which bugs get approved to make changes to the repo. It's insane to require that we get a + bug approved by an oem every time a third party app gets updated. It's also silly to have two places where the package is stored, the marketplace and the gaia repo.

If you want dogfooding to always include certain apps, produce a distribution file that includes the common third party apps and use it every time a build is produced.

Comment 5

[Dylan Oliver [:doliver]]

(In reply to Donovan Preston from comment #4)
> If you want dogfooding to always include certain apps, produce a
> distribution file that includes the common third party apps and use it every
> time a build is produced.

This seems like the right path to me -- that way we're exercising our distribution/configuration functionality as well in the dogfooding builds.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Donovan Preston from comment #4)
> The gaia repository is not the place to store external apps. the marketplace
> is the place for that. The gaia development process is in a code freeze
> right now and has a very strict process for which bugs get approved to make
> changes to the repo. It's insane to require that we get a + bug approved by
> an oem every time a third party app gets updated. It's also silly to have
> two places where the package is stored, the marketplace and the gaia repo.

Fair enough. I think we originally took this approach because the customization option wasn't available, although as you've stated, it's now possible. We've also recently trained release engineering in the customization process, so I'll go ahead and file a bug to do the modification on the release engineering side for Nightly builds.

Comment 7

[Donovan Preston [:fzzzy]]

(In reply to Jason Smith [:jsmith] from comment #6)
> Fair enough. I think we originally took this approach because the
> customization option wasn't available, although as you've stated, it's now
> possible. We've also recently trained release engineering in the
> customization process, so I'll go ahead and file a bug to do the
> modification on the release engineering side for Nightly builds.

Excellent, I'm glad we agree. You are right that we originally took the approach we did because we had no other option, and now that we have another, far superior option I would like to stop doing the inferior thing, hence this bug :)

Comment 8

[Jason Smith [:jsmith]]

I've filed bug 865323 to track the work on the release engineering side.

Comment 9

[Donovan Preston [:fzzzy]]

Attachment: Remove very old version of maps from gaia repo

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

We can take this cleanup for uplift, nominate when ready, not a blocker.

Comment 12

[Jason Smith [:jsmith]]

Now it's a requirement that we have to do this per the dupe (bug 886814). The HERE Maps packaged app in the Gaia repository is not a signed app, so we'll never be able to update this app on 1.1 or later. Donovan & I agree the best solution is to remove the app from the Gaia repository for now and handle including the HERE Maps as part of build process:

* For Mozilla-based builds, we generate customized builds for testing internally with HERE Maps included - bug 865323
* For partner builds, we generate customized builds with the customization including HERE Maps as a signed app

Comment 14

[Julien Wajsberg [:julienw]]

Comment on attachment 749325 [details]
Remove very old version of maps from gaia repo

I'm a bit sad to not have the maps by default anymore but I agree with the rationale.

r=me

Comment 15

[Donovan Preston [:fzzzy]]

Bug 865323 is intended to ensure that maps continues to ship default in dogfooding builds. For people who build and flash from source, the latest version of maps is available from the marketplace. Installing it in both of these ways will correctly sign the package for updates in the future.

What's the procedure for getting this landed into gaia now? I haven't had a patch to gaia in quite a while.

Comment 16

[Jason Smith [:jsmith]]

Add the checkin-needed keyword and watch magic happen.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Don't forget to needinfo? jhford for Gaia checkin-neededs

Comment 18

[Julien Wajsberg [:julienw]]

master: 4313facec01e6ed307fcb126efbba76367bee9b4

or just press the big green button ;)

Comment 19

[Gareth Aye [:gaye] (back from PTO)]

Uplifted 4313facec01e6ed307fcb126efbba76367bee9b4 to:
v1-train: f2245378cea44e283db8f1ce923167fc15cb1148

Comment 20

[John Ford [:jhford] CET/CEST Berlin Time]

v1.1.0hd: f2245378cea44e283db8f1ce923167fc15cb1148

Comment 21

[Julien Wajsberg [:julienw]]

Donovan, however, I don't see HERE Maps in the Marketplace anymore.

Comment 22

[Jason Smith [:jsmith]]

I'm seeing it on marketplace just fine here - https://marketplace.firefox.com/app/here-maps-packaged.

Comment 23

[Julien Wajsberg [:julienw]]

seems like it's back :) I couldn't find it like yesterday or 2 days ago.

Comment 24

[Julien Wajsberg [:julienw]]

Alexandre Lissy told me that it depends on the region for your account (ie: Worldwide vs United States)

Comment 25

[:gerard-majax]

(In reply to Julien Wajsberg [:julienw] from comment #24)
> Alexandre Lissy told me that it depends on the region for your account (ie:
> Worldwide vs United States)

After cross checking with :mat, the app has been marked as non available for the "Worldwide" region. So it's just Nokia that screwed up.

Comment 26

[Julien Wajsberg [:julienw]]

Can we change this ? should we file a bug for this ?

Comment 27

[Donovan Preston [:fzzzy]]

It was an intentional decision by nokia to turn off the "Worldwide" region.

Comment 28

[:gerard-majax]

(In reply to Donovan Preston from comment #27)
> It was an intentional decision by nokia to turn off the "Worldwide" region.

Any reason for this ? Any hope that they might change it ?

Comment 29

[sarsenyev]

Verified this bug is fixed, the "Here Maps" app is removed from Gaia repo and updated version is available for downloading from  the "Marketplace

Environmental  Variables:
Build ID: 20130730070228
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/1fe3339e3d96
Gaia: 6221737cb50d6e8435ac5d3fe3b7e2788bd8a37c
Platform Version: 18.1