Information
We are currently investigating an issue with the editor of some pages. Please save your work and avoid to create new pages until this banner is gone.
During a meeting we discussed that it would be a great idea to send an e-mail to ICT workers, making available an ACS tarball with the changes for the upcoming release at least 2 weeks before the release is rolled out whenever an SCCB (Change Request) ticket which would likely affect other subsystems is a candidate for the release. We usually try to have these changes ready during the first half of the release development as feature branch candidates, so the tarballs will be regularly provided between 3 to 4 weeks ahead of time.
The experience in the latest processes have shown that we have to at least consider the implications within:
In the process we use, before creating the SCCB tickets we have already created the candidate branches, exercised ACS' phase A tests, compiled ARCHIVE and ICD (and applied the necessary changes for them), which in principle means that we're at a state where other subsystems may just try the changes against their own. As part of the COMMON release, we have agreed that it is enough to have the subsystems compiling, but it might be a bit more complicated for those components in the "grey area" which may affect offline subsystems, where we encourage at least some smoke testing if they're affected by the change.
Additional changes for building ARCHIVE and ICD can be found in the development/acs branch, which is constructed in the following way:
We're regularly updating this branch with the latest changes from master and integration/COMMON-YYYYMMM.
A notification should be sent to ICT workers within 2 or more weeks ahead of time whenever an SCCB (Change Request) ticket which would likely affect other subsystems is a candidate for the upcoming release.