ReleaseEngineering/Official Platform Support Checklist

From MozillaWiki
< ReleaseEngineering
Revision as of 17:37, 5 March 2010 by Armenzg (talk | contribs) (Created page with 'These are the steps that will have to be taken in order to officially support a new platform. They don't exactly have to happen in this order but it more or less follows a sequen…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

These are the steps that will have to be taken in order to officially support a new platform. They don't exactly have to happen in this order but it more or less follows a sequential order and some steps can be followed in parallel.

I will add some bugs and links to have examples.

  • Determine tool chain
    • TO BE COMPLETED
  • Get an imaged machine and make the required tool chain changes
  • Generate a build on that machine (ref-image machine) and pass it to QA
  • Once the build is approved get IT to clone few machines with it
    • File IT bug
  • Nagios
    • The machines need to have nagios installed
    • TO BE COMPLETED
  • Mozconfig
    • if a new mozconfig is needed (it can't reuse the one of an existing platform) add another entry to configs/{mozilla2/mozilla2-staging}/$new_platform.
    • if it can be reused add a symlink
  • If the platform supports puppet
    • TO BE COMPLETED
  • Nightly and dependent builds
    • changes to config.py. master1.cfg and master2.cfg
    • which branches to turn on this platform for
    • you can test that the dependent builds are triggered when you test it on staging
  • Testing/baking on staging
    • normally staging-master03 is a good environment to leave it on for few days
    • you want to see dependent builds to be triggered besides manual triggering
  • Try builds
    • This is very very important for developers
    • This is inter-related with talos
    • We are working on adding try as a branch. This section will not be needed
  • Talos builds
    • Not sure what is involved in here
  • Debug builds
    • These are on-change builds
    • Different mozconfigs
    • Maybe some environment variables
    • Probably codesighs is enabled by default
    • This will require graphserver changes
    • graphs-stage DB, graphs DB and graphs repo
  • Unit-tests
    • We are switching to run unit-tests on talos
    • It will be a sendchange to the talos master
  • Release builds
    • one/two lines changes on release_config.py
    • some if statements on Release factories