Firmware release procedures: Difference between revisions
Jump to navigation
Jump to search
(First save.) |
(add section on GIT) |
||
Line 7: | Line 7: | ||
* Quanta stores current EC build in a laptop.org GIT tree |
* Quanta stores current EC build in a laptop.org GIT tree |
||
** along with EC changelog and file hashes |
** along with EC changelog and file hashes |
||
** see notes below |
|||
* Quanta and OLPC test this version of EC |
* Quanta and OLPC test this version of EC |
||
* Quanta tags for release |
* Quanta tags for release |
||
Line 38: | Line 39: | ||
** Could we do this without rebuilding and changing the hashes? |
** Could we do this without rebuilding and changing the hashes? |
||
* Announce new build and hashes to devel-boards@ (requires moderation). |
* 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 them, and to know which EC binaries were 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. |
|||
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 [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html here], and our own instructions [http://dev.laptop.org/wiki/ImportingYourProject here]. |
Revision as of 19:42, 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 them, and to know which EC binaries were 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.