Closed Bug 1043908 Opened 10 years ago Closed 2 years ago

automation h264 builds

Categories

(Release Engineering :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Unassigned)

References

(Blocks 1 open bug)

Details

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.
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?
Blocks: 1043911
Priority: -- → P3
Component: General Automation → General
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.