A summary of recommendations is presented here. The recommendations reflect a coordinated effort to improve software quality and control by implementing a suite of new policies related to repository access, change review, planning, testing, and documentation. If implemented correctly, all of these recommendations can work together to significantly improve productivity and quality.
A summary of how CCM would operate based on this document's recommendations is presented here. Much of this also applies to other components.
Repository access would be granted to users on an individual basis. Limits on how, where, and when they could read and write would be outlined and their use would be monitored. Violaters would lose repository privledges. Development would only occur on branches and a gatekeeper would be in charge on the main trunk.
A CCM change review board (CRB) would be put in place to review, prioritize, and coordinate changes to the main trunk. Individuals would make change requests, the board would ask for comments from the community, and then approve, defer, or deny a change request. The approved requests would then be prioritized for merging onto the main trunk. A status accounting / tracking tool would be put in place to help organize requests/status and to make sure the CRB status is visible to the community.
All approved changes will be thoroughly tested by the developer prior to being merged on the main trunk. As those changes are merged onto the main trunk, code reviews and independent, thorough testing will take place. Once a new version of CCM has been validated, it will be tagged. At the same time, all documents will also be updated and tagged along side the source code. No source code will be tagged until the accompanying documentation is updated.
Because of the new coordination and testing requirements, these tags will likely not take place more than once per month. These tagged version will formally be released for production. In addition, developers will be asked to regularly merge the updates from the main trunk into their development branches. Bug fixes can be implemented quickly by creating bug-fix branches off tagged versions. These changes can be fast-tracked through the review process and may not require formal testing.
The atm working group would be responsible for long-term coordination and planning for CCM. The working group would continue to function as meeting place for developers and as the main community served by the CRB.
CCSM work revolves around gathering the individual components together and running them in production. As such, improved coordination and software qualtity within the individual components will be a major benefit to CCSM.
CCSM development will now proceed along the following path. There will be improved planning and priorization. This will be managed mainly by a CCSM change review board (CRB) which will meet regularly to assess change requests and prioritize them. Input on changes will be received mainly from the working group co-chairs and impacts assessment will be required of everyone. Long-term planning will also be part of the CRB's charter. The CRB is also responsible for making sure changes are coordinated between components; for instance, if an interface is changed.
When new versions of CCSM are recommended, the complete model will be tagged and thoroughly tested. All associated documents will also be updated. Once the new version is validated, production can begin. Because of the new testing and documentation requirements, new CCSM tags will likely not be produced more than once or twice a month. Bug fixes can be incorporated quickly by using bug-fixed versions of released components. In that case, less rigorous testing of the updated model may be possible depending on the extent of the changes.