PlumbingFreeze

Differences between revisions 3 and 4
Revision 3 as of 2011-05-06 14:59:53
Size: 2288
Editor: business-89-133-214-82
Comment: ## page was copied from ToolchainFreeze
Revision 4 as of 2011-05-06 15:06:12
Size: 717
Editor: business-89-133-214-82
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was copied from ToolchainFreeze
Line 4: Line 3:
After this point the toolchain used for building the release should '''not''' change without significant regression testing and written signoff from release team and management. After this point the packages which are considered "plumbing" used for building the release should '''not''' change without significant regression testing and written signoff from release team and management.
Line 6: Line 5:
Core toolchain components include GNU compiler, binutils, libc. (Debugger - TBD) Components that are to be classified as "plumbing" are TBD.
Line 8: Line 7:
Process needs to be defined still, as does infrastructure to do the testing and what the tests should be. Candidates to consider are:
  * python toolchain
  * java infrastructure
  * multiarch support
  * Features that impact the boot
  * Features that other teams have dependencies on before feature freeze.
Line 10: Line 14:
Elements to consider:
 * purpose is sanity testing, (safety net before introducing to general build)
Process needs to be defined still, as does infrastructure to do the testing and what the tests should be (which is obviously dependent on the packages considered to be "plumbing")
Line 13: Line 16:
 * review of actual fixes being proposed, and anticipated scope of impact (ie. platform specific code, or general cross architecture location)
   * no ABI changes that could require rebuild of entire repostitory to be required, those only at start of new cycle.

 * if general cross architecture:
   * automated compiler regression tests should have been run on each of the architectures, and the logs results should be as good or better than the prior run's logs.
   * rebuild of boot loader when appropriate (arm, ppc) - no build failures
   * rebuild of kernel across all architectures (not just the one with the fix ) - no build failures
   * rebuild of key main components (TBD - all of main, or subset? ) - no build failures
   * boot of system on each of the architectures - no obvious failures
   * sanity set of tests (open browser, send an email, ?? ) - no obvious run time failures

 * if architecture specific
   * automated compiler regression tests should have been run on each of the architectures, and the logs results should be as good or better than the prior run's logs.
   * rebuild of bootloader, kernel, and key components (main?) on that specific architecture - no build failures
   * boot of system on the architecture - no obvious failures
   * sanity set of tests (open browser, send email, ?? ) - no obvious run time failures


== Short Term Risk Mitigation ==

In the short term we likely should extend automated toolchain testing. We could create a new PPA into which daily uploads of the toolchain, and a selection of bigger packages could be uploaded (kernel, and libreoffice to start with). If the tool chain uploads trigger no-change rebuilds of the others.
 

DRAFT - this is WORK IN PROGRESS

After this point the packages which are considered "plumbing" used for building the release should not change without significant regression testing and written signoff from release team and management.

Components that are to be classified as "plumbing" are TBD.

Candidates to consider are:

  • python toolchain
  • java infrastructure
  • multiarch support
  • Features that impact the boot
  • Features that other teams have dependencies on before feature freeze.

Process needs to be defined still, as does infrastructure to do the testing and what the tests should be (which is obviously dependent on the packages considered to be "plumbing")

PlumbingFreeze (last edited 2011-05-08 10:45:16 by business-89-133-214-82)