Skip to content

Latest commit

 

History

History
81 lines (58 loc) · 5.78 KB

20221213.md

File metadata and controls

81 lines (58 loc) · 5.78 KB

Technical Lead Call 13 December 2022

Date and participants

  • Names legend:
  • Date: 13 December 2022 2pm UK time
  • Participants: @bouweandela @zklaus @remi-kazeroni @sloosvel @valeriupredoi @ehogan
  • Chairs and minutes takers: @valeriupredoi and @remi-kazeroni

Topics discussed

Topics added to the discussion item page

  1. Organization of the meetings Point decisions:

V @valeriupredoi proposes we decide who does a number of the following:

  • V sets up a doodle and sends it around
  • V talks during the call
  • Remi @remi-kazeroni prepares the agenda for the call. The order of the discussion items could be quickly discussed at the beginning of the call.
  • Remi and V take minutes during the call (items to be decided between Remi and V)
  • Remi and V collate and PR minutes after the call (alternated)
  • frequency schedule: once a month unless pressing issues to discuss
  • V or Remi set up a Discussion page in the Community repository to collect issues for the next call
  1. Strategy for supporting ESMValCore features that do not require a source installation Bouwe @bouweandela:

I would also like to talk about our strategy regarding supporting features that make it easier to use ESMValCore without doing a from source installation and modifying the source code if you need additional features. Examples could be:

  • Configuring the default paths to ESMValTool recipes, diagnostics, and the references (config-references.yml and references folder), i.e. make it easy to use ESMValCore without ESMValTool Using fixes from an external location as proposed in
  • Custom user-defined location for custom project CMOR fixes ESMValCore#1852 Using arbitrary python functions as preprocessor functions

Point discussion: Do we want to revise the current policy? Many users may not contribute their features (like fixes) since the level to contribute can be high (via PR) and the timescale (until next Core release) too long. For example, fixes could be decoupled from the Core. Fixes could live in a separate package with config files. We could also have different packages for different projects. TLT supports the idea. Agreement that we may lose contributors in the current situation. To be discussed with the PIs and the Science Lead Team.

Downside: more package maintenance and/or too many packages to be maintained

  1. Maintaining Zenodo records - also discussed in the previous meeting here V @valeriupredoi needs to figure out how to get a collective (2+ users) email address, this will be done ASAP

  2. Release procedure: What can go in after the feature freeze? [originally posted by @bouweandela]

Should a feature freeze for the release mean that we allow only bugfixes after that, or will any pull request that is merged after the feature freeze but before the release be included in the release?

It looks like there are different opinions on this (see e.g. ESMValGroup/ESMValTool#2734 (comment)), so it would be good to talk about this at the upcoming tech lead team meeting.

Point discussion:

  • @zklaus: supports the idea of release Core and the tool shortly after.
  • @valeriupredoi: important to keep feature freeze.
  • @ehogan: unlikely that the recipe test workflow would be available for the next release (v2.8)
  • @remi-kazeroni: prefers working with release candidates and only doing thorough recipe testing for the Tool (and last Core release candidate).
  • @valeriupredoi: try to keep the number of release candidates for the Core to a minimum and not necessary to have rcs for the Tool.
  • @bouweandela: can I still merge new features to main during the release procedure? @zklaus: suggests veto rights to the RM. Also others may ignore the ongoing release if new features can still be merged.
  • @valeriupredoi: It's the responsibility of the RM to ensure good communication and the community is actively supporting the release, the testing
  • @bouweandela: we should aim at keeping release cycles as short as possible so that contributions are not put on hold for too long. Also, make sure the release documentation is up-to-date
  • @zklaus: Core feature freeze would be the point of first release candidate.
  • @bouweandela: Make sure all the commits related to a tag are included into the main branch. Doubts about the handling of release candidate tags (e.g. v2.8.0rc1), to be checked
  • Documentation @valeriupredoi will update the release documentation early January, previous release managers can then take a look
  1. Release procedure: documentation of the release process

TBD

  1. Release procedure: Strategy to run all recipes

TBD

  1. Release procedure: Administration of the VM and its usage during the release

TBD