Discuss requirements from other parts of the team for toolchain freezes
At several points in the oneiric cycle, there were mismatched expectations regarding the handling of the toolchain. Despite discussions at last UDS that concluded with agreement that the kernel did not need to check the exact compiler version in use for building out of tree modules, the kernel team expected to use the same compiler version for building the kernel across all architectures for a given milestone, a requirement that the foundations team was not aware of.
The outcome of this session is to be an understanding of any requirements for toolchain stabilization (gcc, binutils) from other parts of the team and a description of any freezes (timelines, scope, and rationale) that need to be applied to the toolchain for precise above and beyond the standard freezes.
Toolchain update procedures are currently documented at https:/
Would be good to review the toolchain plan for the 12.04 cycle.
- Any component version changes anticipated?
- Where is the definitive location to reference to see the latest upcoming plans?
Differing levels of communication about upcoming changes needed during various development phases.
- Can we agree on periods in release cycle where there is sensitivity to change?
- Mechanism to use to communicate effectively?
* used to have a hard constraint to not change the gcc used for the kernel without also changing the ABI version
* determined that this was not needed, but still wanting all kernels of a given version built with the same compiler for debuggability
* if the changes are all superficial and don't impact the kernel, it's ok - but the kernel team needs some way of knowing this
* kernel team doesn't want changes to the contents of the toolchain, they just want to know when the uploads will be done so that the kernel can avoid them
uploads through PPAs did improve things.
Milestones - avoiding skew between compiler first preference, but need to have more communication of upcoming schedule of changes from compiler.
Let know compiler upload is coming before a milestone (sensitve window).
* notification to ubuntu-devel
* both kernel and toolchain tend to get uploaded on weekend because the buildds are idle
* somebody needs to stop working on weekends
* when is the sensitive window in which notifications are required?
* Milestone prior to Feature Freeze: (Kernel on Monday) 3 days before freeze <--> freeze
* Milestone after Feature Freeze: Beta Window (Kernel on Friday)
* no toolchain uploads in the three days before the start of the freeze without notifying the kernel team via mail to ubuntu-devel, kernel-team
* notification should include guidance to the kernel team whether the toolchain upload includes bugfixes that the kernel team will want in their own builds
* Matthias wants to track upstream until 4.6.3, which is roughly 3 months from Nov 2011
* Kate thinks this should be safe to land before feature freeze
* Discussion needs to happen with Linaro TC WG here at UDS about how long to follow the Linaro releases
* Kate wants notices of any changes with a high-level summary after feature freeze, even though they're bugfix only
* Notifications should happen a day before upload, so that if there are any concerns they can be raised in advance (just in case)
- relative stability of archive (alpha & beta)
- schedule before archive unfreezes - daily use and installabiliy
- 2 days for main is estimate - if using all buildds.
- limit this to A2 and B1 hold archive freeze for two windows for rebuild.
(work with desktop team to ensure that their schedules sync up).
- rebuild test, try it this way for A2, and revisit if issues with B1.
- gcc 4.7 - test toolchain want to use rebuilds avoid conflict - use for universe.
4.7 right after DIF.
- Matthias requests daily PPA builds have lower priority than Compiler Test rebuilds.
* doko to make sure HWE / test rebuild usage of the PPA builders are on the interlock page and don't clash
* slangasek to talk to launchpad to change PPA build scores to improve behaviour for compiler test rebuilds