Status

Release Engineering
General Automation
P3
normal
4 years ago
14 days ago

People

(Reporter: bhearsum, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
It's not clear what the priority of this is, but the overall "make new h264 binaries available" process has tons of human error built into it. We've already got a Mozharness script that does most of the work as part of the build, so we're not that far from being able to automate it. Callek tells me that two unknowns are:
1) Where do we upload them? They need to be somewhere private, but accessible by Cisco. Perhaps pvtbuilds, if we're able to give Cisco accounts to access that with.
2) What do we call the binaries? We should decide on a specific naming convention. Last time, I used openh264-$platform-$branch-$rev.zip. I think that's got all the right information in it, but perhaps we should replace the -'s with _, because some $branch can have -'s within it. I'm not too fussy here, though.

We should probably automate notifying Cisco (and requesting that they host the files) when we do this, too.
(Reporter)

Comment 1

4 years ago
Oh, and it would probably be good to generate a .checksums file like we do for other things (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-07-25-03-02-02-mozilla-central/firefox-34.0a1.en-US.linux-x86_64-asan.checksums). These files have sha512 and filesize in them, which means we wouldn't need to download files to generate update data.

Should we start signing everything, too? Or does that not make sense because it's not our code, and we're not the distributor?
(Reporter)

Updated

4 years ago
Blocks: 1043911

Updated

14 days ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.