[mpas-developers] Joint development in the MPAS repository trunk

[Michael Duda]

Hello, Developers.

As those of you on the mpas-developers at ucar.edu mailing list have
probably seen, we've done some rearranging to the MPAS repository
trunk around March 5 to accommodate our current three dynamical
cores (shallow water, ocean, hydrostatic atmosphere) under a
single directory structure that allows us to share much of the
infrastructure/framework code. The primary benefit here is that
improvements to shared code can now be leveraged by all cores; the
additional burden is that we now need to exercise greater care in
developing and committing changes to shared code.

We've come up with a set of initial guidelines for how to go about
managing changes to the trunk of the repository; I've committed
this document to the MPAS repository under
trunk/documents/repository_guidelines.txt. Essentially, before a
change is committed to the trunk (branches being excepted from
this requirement), a developer should give notice to other
developers of the change -- generally be attaching the modified
file or files to an e-mail to mpas-developers at ucar.edu -- and give
at least 24 hours for other developers to review the changes.
Before the changes are committed, representatives from both the
LANL group and the NCAR group need to "sign-off" on the changes;
initially, Todd Ringler will sign-off on behalf of LANL group, and
I'll do the same on behalf of NCAR group. 

Anyone not currently subscribed to mpas-developers at ucar.edu who
does plan to make changes to the repository is strongly encouraged
to subscribe in order to initiate and participate in any
discussion of changes proposed to the trunk code. Anyone may
subscribe through
http://mailman.ucar.edu/mailman/listinfo/mpas-developers .

Our intention is not for this new process to be too heavy-weight,
but rather, simply to impose some minimal controls to make 
development on a shared code base as smooth a process as possible.
As we work under these guidelines, we may find things that don't
work well, or points that need to be clarified. Certainly, any
comments or suggestions would be most welcomed at any time.

Cheers,
Michael


On Fri, Mar 05, 2010 at 10:26:29AM -0700, Todd Ringler wrote:
> Hi All,
> 
> With Michael's last commit, all of the cores are now built using  
> shared directories. The upside of sharing common code is that we can  
> all leverage off of each others' contribution. The downside is that we  
> can each break the model for everyone else, if we are not careful.
> 
> It seems reasonable to place some minimal controls over modifications  
> to the code on the trunk. Now seems to be an appropriate time to  
> figure out what these controls should be. This is wide open for  
> discussion, but here is what initial discussions between Phil, Bill,  
> Michael and me came up with:
> 
> The purpose of this minimal control over revisions to the trunk is to  
> guard against unintentional consequences. So it seems appropriate to  
> gives a heads up (probably to this list, Mpas-developers at lists.sourceforge.net 
>    ) before code is committed to the trunk. That email should probably  
> include what code is going to be changed, why is the code changing and  
> (if known) what repercussions might result. The "aging" period for  
> this email is still undetermined, but something between 24 and 48  
> hours between the email and svn commit seems about right. Clearly,  
> bigger commits require longer aging periods and more discussion.
> 
> The above control is essentially at the end of the process, i.e. what  
> happens right before the commit. It has always been our intention to  
> setup telecons as required to discussion structural changes to the  
> trunk well before this point. If anyone is pursing changes to the code  
> that are much more than cleanup and bug fixes, we should consider  
> going through a rapid process of telecon, requirement, design doc and  
> implementation. This does not have to be a heavy process, but instead  
> serves as a standard mechanism for communication.
> 
> Michael, Phil and I (and anyone else willing to help!) will be putting  
> general coding standard template, requirements template and design  
> template documents onto the trunk. As those become available, we will  
> announce those over this list for comment and feedback.
> 
> The most important message here is communication. Since we still  
> getting used to how this will work, we each likely have a different  
> perspective of what level of communication is appropriate. This  
> discussion is meant to determine, as a group, how we should  
> communicate during the development process.
> 
> A couple of open questions:
> 1. Should we have a different process for code in the shared  
> directories vs code changing a specific core?
> 2. Should we develop a common, simple testing directory where we can  
> all test our changes before commits?
> 
> Comments welcome!
> 
> Cheers,
> Todd
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mpas-developers mailing list
> Mpas-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mpas-developers