If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Pocket shouldn't be shipping its platform X icons on platform Y (windows on *nix, osx on windows+gtk, linux on osx/windows)

NEW
Unassigned

Status

()

Firefox
Pocket
7 months ago
7 months ago

People

(Reporter: Gijs, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 months ago
Pocket's jar.mn looks like this:

% skin pocket classic/1.0 %skin/linux/
% skin pocket classic/1.0 %skin/osx/ os=Darwin
% skin pocket classic/1.0 %skin/windows/ os=WINNT
% skin pocket-shared classic/1.0 %skin/shared/
  content/  (content/*)
  skin/  (skin/*)

But this means that we're packaging all of the contents of the skin/ subfolder on every platform. Instead it could look like this:

% skin pocket classic/1.0 %skin/
#ifdef XP_WIN
  skin/   (skin/windows/)
#elifdef XP_MACOSX
  skin/   (skin/osx/)
#else
  skin/   (skin/linux/)
#endif

The override directives could also be limited so they're only included in the manifests for the platforms where they're relevant.

Finally, the pocket-shared stuff could be moved into the same dir, though that's mostly a code cleanup issue and won't actually save on bytes shipped.
Actually, since Pocket has to be signed, and it may be updated via gofaster or even via AMO (though in practice it hasn't), I think it does need to contain everything it needs to work.
(Reporter)

Comment 2

7 months ago
(In reply to Shane Caraveo (:mixedpuppy) from comment #1)
> Actually, since Pocket has to be signed, and it may be updated via gofaster
> or even via AMO (though in practice it hasn't), I think it does need to
> contain everything it needs to work.

We can ship OS-specific go-faster updates, surely?
Flags: needinfo?(mixedpuppy)
Well we had to build in all the locales, so I assume not.  I'm also not clear how addon versioning/signing/etc works if that were done.

But we can get someone on gofaster to inform us on that.  Perhaps rhelmer will know.
Flags: needinfo?(mixedpuppy) → needinfo?(rhelmer)
We *can* ship OS-specific gofaster updates, but it's not something we've generally done. We're working on automating the update process but right now it would require more packaging and QA for each update.

Gijs, it'd be pretty easy to do this for the built-in add-on. Pocket is particularly large and we don't use the update mechanism for it very frequently right now - what do you think about doing this for the built-in and not for the updates (yet)?

We could file a followup to do it for the updates, blocked on having better automation to make sure it's done correctly every time.
Flags: needinfo?(rhelmer) → needinfo?(gijskruitbosch+bugs)
(Reporter)

Comment 5

7 months ago
(In reply to Robert Helmer [:rhelmer] from comment #4)
> We *can* ship OS-specific gofaster updates, but it's not something we've
> generally done. We're working on automating the update process but right now
> it would require more packaging and QA for each update.
> 
> Gijs, it'd be pretty easy to do this for the built-in add-on. Pocket is
> particularly large and we don't use the update mechanism for it very
> frequently right now - what do you think about doing this for the built-in
> and not for the updates (yet)?
> 
> We could file a followup to do it for the updates, blocked on having better
> automation to make sure it's done correctly every time.

How would we tell the difference? Like, would we maintain 2 copies of jar.mn and hope nothing breaks?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(rhelmer)
I was thinking we'd built updates differently.. that's a good point though. If we change this in m-c it's probably easiest to just commit to doing updates the same way.
Flags: needinfo?(rhelmer)
You need to log in before you can comment on or make changes to this bug.