Firmware release procedures: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
mNo edit summary |
||
Line 42: | Line 42: | ||
==Using GIT for EC code== |
==Using GIT for EC code== |
||
Using a revision-control system allows us to keep a copy of old EC releases, the changes between releases, and to know which EC binary was part of which release. There is already a GIT server running on laptop.org; the appropriate person at Quanta would need to install GIT and SSH, both of which work under [http://www.cygwin.com/ Cygwin], and would need to send us their SSH public key. |
Using a revision-control system allows us to keep a copy of old EC releases, the changes between releases, and to know which EC binary was part of which release. There is already a GIT server running on laptop.org; the appropriate person at Quanta would need to install [http://git.or.cz/ GIT] and SSH, both of which work under [http://www.cygwin.com/ Cygwin], and would need to send us their SSH public key. |
||
A draft set of instructions would be: |
A draft set of instructions would be: |
Revision as of 21:21, 13 October 2006
Release procedure
Here is a draft of a BIOS release procedure.
Stage one: EC:
- Quanta stores current EC build in a laptop.org GIT tree
- along with EC changelog and file hashes
- see notes below
- Quanta and OLPC test this version of EC
- Quanta tags for release
- Quanta sends mail to OLPC announcing the release, along with hashes from their build system
- OLPC acknowledges receipt
Stage two: Buildrom:
- Pull EC release from GIT, check hashes
- Update buildrom changelog and tag for release
- Update SPI flash version string in buildrom binary
- Create buildrom SRPM
- Build two flavors of binary RPM for the two RAM variants
- check with Ray -- do we need separate EC code for A-test and B-test?
Stage three: Testing:
- announce build to BIOS team and Ray, release candidate testing begins
- wmb to test on a 256M board
- install the binary RPMs on Tinderbox machines
- >12 hours of burn-in warm reboot testing on Tinderbox
- cold boot tests
- we need a cold boot solution; X10 doesn't seem to like the power at OLPC
- After automated tests, send "Who has tested?" mail asking for problem reports
- Release after twelve hours if no problem reports
Stage four: Release:
- Release builds kept in a separate directory
- Update the version number in LB from release candidate to final
- Could we do this without rebuilding and changing the hashes?
- Announce new build and hashes to devel-boards@ (requires moderation).
Using GIT for EC code
Using a revision-control system allows us to keep a copy of old EC releases, the changes between releases, and to know which EC binary was part of which release. There is already a GIT server running on laptop.org; the appropriate person at Quanta would need to install GIT and SSH, both of which work under Cygwin, and would need to send us their SSH public key.
A draft set of instructions would be:
git clone git+ssh://user@dev.laptop.org/git/projects/quanta-ec cd quanta-ec cp /latestec . git add latestec # this line only needs to be run the first time git commit -a # this will prompt for a commit message, which should be the changelog git push --all
There is a GIT tutorial here, and our own instructions here.