Release Process Updates

From Einstein Toolkit Documentation
Revision as of 23:57, 26 May 2023 by Scupp (talk | contribs)
Jump to: navigation, search

Ideas and drafts for an updates release process documentation


Branch creation script partially broken

This script is very convenient. It not only makes and pushes the branches/tags, but also skips any repos which already have the branches. This is very important in the case that someone tries to run it but doesn't have permissions to push to all the repos. At this point, the simplest solution would be to delete the repo they can't push to and rerun the script. This allows for the manager to quickly traverse the repos and mark down which ones they were unable to do while automatically doing all the other repos. Unfortunately, GetComponents has been changed to default to shallow checkouts. This means that git doesn't know what remote other than whatever it has checked out (main/master, in this case). One needs to have un-shallowed the repos or originally checked them out with the "--noshallow" option to be able to fully use this script. Either the script could be changed to work with shallow checkouts (if possible), or a note should be added to alert managers that they should get a "--noshallow" checkout.

Updating SelfForce-1D

Since this repo is not checked out via GetComponents, making sure to do it as well during the branch/tag creation is important. Sam added a note in the release process documentation saying to make sure this is done. However, the script which automatically does all other repos could easily be extended to handle this as well. Currently, it goes into every repo it finds and makes the branches. If the start of the script checked out the selfforce-1d repo into repos/, the script should work for this repo as well.

Who is on the release team?

It would be good to create a clearer documentation of who should be included in the release team, as there was some confusion this time. Since previous releases also didn't seem to follow a clear pattern either, this probably needs some discussion. The following groups are always included now:

  • Release manager(s)
  • Code reviewers
  • Gallery and test runners
  • anyone putting in work specifically for the release

The last bullet is somewhat vague and leaves a fair bit to interpretation. A simpler addition is probably to add all contributors to the release team. This is because the contributors are going to fall under the last bullet in almost all cases. We can also leave the last bullet in case someone who isn't in any other categories helps with addressing review comments. The new list would be

  • Release manager(s)
  • Code reviewers
  • Gallery and test runners
  • Contributors
  • anyone putting in work specifically for the release

I think this would reduce confusion on what is considered part of the release team. Leo and Sam's interpretation considered anyone resolving reviewer comments on their own contributions as not being part of the release team. This interpretation seems to match the release teams listed in previous releases, but it doesn't match some of the documentation on the site. Also, it makes the case of release managers having to make a value judgement of someone's contribution to release less likely.