[an error occurred while processing this directive] [an error occurred while processing this directive]
CCSM Software Engineering Working Group Meeting
NCAR, October 2-3, 2000
Much of our meeting was open discussion that focused on the following topics:
In addition, the meeting included:
Action items and recommendations are listed at the end of this report.
SOFTWARE ENGINEERING MANAGER
The draft CCSM Software Engineering Plan proposes the creation of a software engineering manager position for the CCSM project. This was not an original idea; it was being discussed by CCSM management before the Plan was released, in response to a need for greater coordination across the project and also as relief to scientists who were finding managing software development on top of their other responsibilities a burden.
However, how exactly such a position could be introduced smoothly has been a matter of active debate. Many software engineers within the CCSM project value the strong connection of their work to original research and want to continue working for scientists. Others would like to pursue work that has a stronger focus on computational techniques. The solution that appealed most to the participants in the working group was the introduction of a manager who would directly oversee software engineers responsible for overall CCSM functions, such as configuration management, common build scripts, and testing the whole model. Most other software engineers would continue to work for scientists in the near term. The software engineering manager would coordinate with individual scientists and the software engineers working for them to maintain a focused software effort across the project. This solution allows for the gradual migration of more software engineers reporting to the software manager, if that appears more desirable in the future.
The working group came up with a list of responsibilities that they foresee the software engineering manager taking on:
1. Prioritization and assignment of selected SE tasks
2. Tracking software activities across CCSM groups
3. Coordination with groups external to CCSM
- to obtain shareable code (e.g., coordinate with ESMF)- to help assimilate code from external computational collaborators (e.g., ACPI)- to help assimilate code from external scientific collaborators
4. Software decisions and arbitration within CCSM
5. Release coordination and accountability
6. Represent SE interests on SSC
7. Serve as point of contact for other groups
8. Developing and maintaining updated software engineering plans
9. Arranging software training
10. Responsible for creating and promoting software-related protocols
CCSM DEVELOPER'S GUIDE
Brian Kauffman presented work he has done so far on the Developer's Guide. The subsequent discussion touched on whether all groups within the CCSM should have separate software processes, who should make such a decision, what sorts of documents might be recommended, and whether such a recommendation should be in an initial Developer's Guide.
Less controversial items relating to the Developer's Guide were the incorporation of some practical guidelines for configuration management, testing procedures, build scripts, and code standards.
Jim Rosinski led a discussion on improving build procedures, possibly using autoconfig. Further exploration is an action item.
Brian Kauffman (CGD)
Cecelia Deluca (SCD)
Ricky Rood (NASA/GSFC)
Jim Rosinski (CGD)
Mariana Vertenstein (CGD)
Lawrence Buja (CGD)
Gokhan Danabasoglu (CGD)
Peter Gent (CGD)
Matthew Hecht (CGD)
Erik Kluzek (CGD)
Mike Moran (CGD)
Keith Lindsay (CGD)
Nancy Norton (CGD)
Sam Levis (CGD)