What's the process for updating lfric_apps KGOs? #313
Replies: 1 comment 2 replies
-
Hi Mike, Its key that you and your science reviewer are happy with the updated answers on your branch, but since the Apps and Core split last year we've no longer had it be mandatory that the developer is the person to do the final update of the checksums. The process is now: Update the checksums on your branch - this allows you to be sure that the answers are stable from one run to another. Go through science and code review as usual. Once your ticket has been approved, if there are merge conflicts in the checksum files at the Head of Trunk then the code reviewer can update the checksums as part of their merge and commit process. This removes the need for lots of HoT branches and much back and forward with the developer. Hope that helps :) Jenny |
Beta Was this translation helpful? Give feedback.
-
Hi all,
I just wanted to ask for recommendations Re best practice for updating rose-stem KGOs when you have an lfric_apps ticket that doesn't preserve answers?
So-far, the process has been for developers to update the checksum files (which are contained in the lfric_apps repository) themselves before submitting their ticket for review. However, I'm aware of a large number of lfric_apps tickets aimed at this release which all change KGO for some of the same rose-stem apps. This will mean that updating the checksums in my vn2.0.1 dev branch will be futile; my updated checksums will be wrong by the time the ticket gets committed to the trunk, due to other KGO-breaking tickets getting lodged in the mean-time. The issue is exacerbated by the CCE-fast compile on ex1a being extremely fickle about its KGO; it changes answers if you pretty-much just breath on the code, hence a lot of tickets need to update certain CCE-fast-ex1a checksums.
Given the fairly high rate of ticket-lodging, even if I make a head-of-trunk branch and update the checksums in it at the point where I submit it to code review, odds are the checksums will need updating again by the time the code reviewer gets to the point of committing it to the trunk.
So I think we need each ticket to be able to reserve its own time-slot in-which to do its final updating of checksums before being committed to the trunk. Otherwise we'll have to waste a lot of time repeatedly making new head-of-trunk branches to update the checksums, only to find that another KGO-breaking ticket got lodged just before ours and the checksums need updating again :P
What do you reckon?
Cheers!
Mike
Beta Was this translation helpful? Give feedback.
All reactions