Yannick opened the meeting announcing that Mark M will present a status report of the recent JEDI release and follow that with Q and A.
Mark M presented the following slides.
In general the release went smoothly except for one item which is that GitHub does not allow a private fork of a public repository. This meant that when we changed the JCSDA repos from private to public, the corresponding repos in JCSDA-internal were automatically converted from forks (of JCSDA) to stand-alone repositories. Please note that nothing was lost in the JCSDA-internal repos. All the feature branches, PRs, issues, histories etc. remain intact in the JCSDA-internal repos.
The bottom line of losing the ability to organize our internal repos as forks is that we move back to conducting software development as we did before the release. That is, all work is to be done in the JCSDA-internal (private) repos. All feature branches, PRs, ZenHub issues, etc. stay in the JCSDA-internal repos. Note that everyone's access to JCSDA-internal, at this point, has not changed.
Moving forward, the core team will manage keeping the public JCSDA repos (master and develop branches) in sync with the private JCSDA-internal repos. We are nearing having a GitHub Webhook in place that will regularly sync the JCSDA repos automatically. For external entities that have access only to the JCSDA public repos who want to contribute, a process will be setup for them to be able to issue PRs to the public repos. This process will involve another Webhook that automatically copies the feature branch and PR to the corresponding repo in JCSDA-internal. The code review process will take place in JCSDA-internal and once merged, those updates will be pushed back to the public JCSDA repo.
This operating model that we have set up for JEDI is based on the process that ECMWF is successfully using and should look familiar to anyone who has submitted PRs to ECMWF.
This concluded Mark's presentation and the floor was opened up for questions.
Jake commented that he could not see PRs, issues, history, etc. in the public JCSDA repos of which he was expecting to see, and asked if this is what was intended. The answer is yes because we wanted to keep the public repos as simple and clean as possible. This is why the public repos contain only the master and develop branches for example. It was also noted that the complete history, issues, PRs, etc. still exist in the "-old" JCSSDA-internal repos, and the intention when we made the new repos in JCSDA-internal was that the new repos would also contain the complete history, PRs, etc. with the exception of the issues. ZenHub didn't allow us to copy the issues so all of the open issues from the "-old" repos were manually copied into the new repos. If anyone discovers discrepancies with what we are describing here, please let us know so we can fix them.
Mark M added some information about the fv3-bundle repo on the public JCSDA organization. Because some of the packages you may be used to seeing in fv3-bundle have remained private, their ecbuild_bundle links have been removed. Examples are the RTTOV and ROPP packages. Also some extra items have been added to the public fv3-bundle such as tutorials.
Yannick asked the group to be diligent about submitting issues in ZenHub so that their work could be properly tracked. In the Quarterly Review meetings, the reports that we generate from ZenHub are the means of communicating to the partner organizations' high level management who and what contributions are being made to JEDI. If your contributions are not being tracked in the ZenHub issues, then your organization's high level management will not see it being reported which can create unwanted distraction during the reporting discussions. Yannick added that entering an issue in ZenHub typically takes around one minute which is time well spent for making our reporting more accurate.
For help with ZenHub see this page in the JEDI ReadTheDocs website and please don't hesitate to contact core team members as well. When entering an issue in ZenHub, at the bare minimum, please attach a label denoting the JEDI AOP task that this issue relates to. There should be labels already defined for JEDI1 through JEDI5 and for the other JCSDA projects (e.g., OBS).
Yannick closed the meeting at this point since there were no more questions or comments.