Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to check out a Develop branch of Chem, under GCM #31

Open
mmanyin opened this issue Aug 26, 2019 · 1 comment
Open

How to check out a Develop branch of Chem, under GCM #31

mmanyin opened this issue Aug 26, 2019 · 1 comment

Comments

@mmanyin
Copy link
Contributor

mmanyin commented Aug 26, 2019

A recent update included code changes in both GCM and Chem, so I need to check out the "develop" branches of each. But the current Develop.cfg under GEOSgcm automatically uses the Master branch of Chemistry. Is there a run-time option for getting the Develop branch of Chemistry, from the GEOSgcm level?

@tclune
Copy link
Collaborator

tclune commented Aug 26, 2019

@mmanyin I know we discussed this in the hallway, but for the record ...

A major issue here is whether or not we (GMAO) want the GCM gatekeepers to be the gatekeepers of grid comps that are in other repos. The decision can be made on a case-by-case basis.

If a grid comp, e.g. MOM, is controlled by a separate group, then the GCM gatekeepers need their "develop" branch to correspond to a fixed tag of MOM. Otherwise updates to MOM could confuse the gatekeepers as they test pull requests onto develop.

On the flip side, if the GCM gatekeepers control develop and master for separate grid comps, they can then treat the develop branch in a consistent manner with the develop branch of the main GCM. If we consider this for the case of chemistry, then other subcommunities (CTM, CCM) will need to have their own long-lived feature branches that will generally be ahead of the develop branch. Those communities can then accumulate pull requests without interfering with GCM validation. Of course those branches should be merged onto develop eventually - more of an advocacy issue than a technical issue.

My preference is for consistency. I defer to @lltakacs and @sdrabenh as to their preference here (and will discuss it with them soon). How Externals.cfg and Develop.cfg behave will depend on that decision. CTM/CCM subcommunities may wish to add their own cfg files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants