Firmware release procedures: Difference between revisions

From OLPC
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.