Closed
Bug 1043908
Opened 10 years ago
Closed 2 years ago
automation h264 builds
Categories
(Release Engineering :: General, defect, P3)
Release Engineering
General
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.
Reporter | ||
Comment 1•10 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?
Updated•6 years ago
|
Priority: -- → P3
Assignee | ||
Updated•6 years ago
|
Component: General Automation → General
Comment 2•2 years ago
|
||
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.
Description
•