Release of Github Working Practices

[james-bruten-mo]

Hi All,

We have just released the first draft of the new simulation-systems working practices for use with github - these can be seen at https://metoffice.github.io/simulation-systems/
This is a significant rewrite of the working practices, ready for the imminent migration of the code bases to github. While we finalise their releases those repositories remain private - we will update here on their release.

For now, please familiarise yourselves with the new working practices. In particular, ensure you have a github account and have set up a way of authorising yourself from the command line. We will look to highlight key changes to the working practices in upcoming posts over the next few weeks.

For anyone still looking to reference the old fcm working practices, these can either be accessed through the history of the main branch of this repository, or for internal Met Office employees a temporary build is available at https://wwwspice/~umadmin/fcm_wps/index.html

Best Wishes,
James, on behalf of SSD team

[iboutle]

Thanks for sharing this James.

One question that jumps out to me. Under fcm, our process for head-of-trunk branches needed for merging back to trunk was to create a new branch, and merge the changes from the vnX.X branch into that. The key reason for this is that it keeps the vnX.X branch clean for use in standalone suites (where it may need to be merged with other vnX.X branches).

If I understand correctly, the Git proposal is to merge the trunk/main onto the vnX.X/stable branch. Won't that cause issues in then trying to use that vnX.X/stable branch in standalone suites, or what would be our method for dealing with that?

Cheers!

[jennyhickson]

Hi Ian,

You're right that we're suggesting to merge main into the version based branch - but only when it is almost through the review process. This keeps the development "clean" as it were until that point, and the branch could be used at the commit before main is merged in for standalone suites even after the merge has been done.

Github pull requests work best with changes that are at the "head of main", so not allowing the ability to merge main into a version branch would see an increased overhead in the number of changes that need to make a seperate head branch and pull request to get through the review process. Github likes to nag you about keeping upto date with the latest changes on main, so part of the challenge is to encourage all developers to resist that!

Just a note on terminology - we'd still refer to version branches, or vnX.X branches. Stable is a branch of its own which points to the latest release and is where you create the version branches from.

Happy to chat offline if you think this will still cause issues with merging vnX.X branches together so we can make sure we're doing the right things. We can also change tactic if we discover problems as we go along.

Cheers,
Jenny

[iboutle]

Thanks Jenny - I think that makes sense and will work if, as you say, we keep the branches 'clean' for as long as possible through the review process and only merge main on just before commit.

I think the main thing that confused me was the flow diagram at https://metoffice.github.io/simulation-systems/WorkingPractices/working_practices.html#working-practices-index, which has the "merge in main" box before the science/code review and changes required - whereas what you're saying (and what the text does say to be fair) is that this box should really enter the flow diagram after the science/code review changes are made - not sure if it's worth modifying the flow diagram to show that?

[jennyhickson]

Thanks Ian. We've updated the diagram to hopefully be clearer that this is one of the final steps in the process.

[iboutle]

Looks great - thanks!