Marked as blocked:dependency because, at the moment, Externals.cfg points to branches of my personal MOSART (issue ESCOMP/MOSART#53) and RTM (issue ESCOMP/RTM#31) forks that contain the same changes. I haven't yet submitted those as pull requests, because I first wanted to see if any more testing is requested.

UPDATE
PRs ESCOMP/MOSART#66 and ESCOMP/RTM#35

From CTSM software engineering meeting today: This doesn't need to wait on other time-related PRs. It can come in as soon as the relevant externals are updated (and Externals.cfg here is changed to point to them).

derecho testing prior to updating .gitmodules to mosart1.1.08 and rtm1_0_85 in ce7f7b2:

PASS ./build-namelist_test.pl
PASS black and lint, though the latter gave 2 warnings
PASS ./run_ctsm_py_tests

Note to self: Consider initiating further testing, but perform final testing after updating to ctsm5.3.020.

Questions:
Given that we will mark this tag as the release tag for ctsm5.3:

• Would it make sense for us to include the one-line ccs_config update to enable f09_t232?
• Is it complicated to make a new ccs_config tag? I doubt that I have permission.
• Or is there a way around making a new ccs_config tag?
• Or should we wait for the fix to come in later?

@slevis-lmwg this is a good question. If the ccs_config updates can come in quickly, I'm supportive of wrapping the external update into this tag.

If this will take long, however, I'm wary of scope creep and somewhat less worried about how we're defining there minor version tags (especially since we expect a 5.4 tag to be made in the next few months). I'm also hesitant to hold up our upcoming tags, because it seemed like there are several FATES tags that are pretty critically and backed up against 5.3.021.

@slevis-lmwg this is a good question. If the ccs_config updates can come in quickly, I'm supportive of wrapping the external update into this tag.

If this will take long, however, I'm wary of scope creep and somewhat less worried about how we're defining there minor version tags (especially since we expect a 5.4 tag to be made in the next few months). I'm also hesitant to hold up our upcoming tags, because it seemed like there are several FATES tags that are pretty critically and backed up against 5.3.021.

Yay, I see that this was addressed here:
ESMCI/ccs_config_cesm#205
Thank you @fischer-ncar and @wwieder

Nice that we have a tag for the simple fix needed. So you should just include that here.

I will say that I'm supportive of this NOT having everything clean even for this tag being a development release tag. At least in this case when running with MOM masks in stand-alone CTSM is still considered "experimental". I know it shouldn't be thought of that way, but until it's standard practice -- it's experimental. The fact that it was broken the first time we tried it -- just underscores how "experimental" it really is right now.

And @slevis-lmwg just to be explicit on your questions:

• Is it complicated to make a new ccs_config tag? I doubt that I have permission.

It's not complicated, once a ccs_config PR is merged it automatically creates a tag for it.

BUT what is critical here is to have done enough testing with it that it doesn't break something in CESM. In this case it was easy to approve because it was so isolated to handling a grid that wasn't working. So your testing was sufficient.

@jedwards4b and @fischer-ncar are the main contributors to ccs_config from CSEG. There's a few others too though.

• Or is there a way around making a new ccs_config tag?

Not, really other than maybe doing a branch tag, but I don't think we should do that most of the time if ever.

Also there's a possible caveat to updating to the latest ccs_config:
ctsm5.3.020 is updating to ccs_config_cesm1.0.16. Beyond that I see tags upto ccs_config_cesm1.0.19, so the f09_t232 fix is not the only thing that we'd be getting by updating...

It looks like those changes in ccs_config tags should be benign. But, they also haven't gone through CESM testing, so I'd treat them a little suspect. I suggest you try it with it updated, but if it causes any problems -- back that update out.