Skip to content

Instantly share code, notes, and snippets.

@SimonKrughoff

SimonKrughoff/comments.md Secret

Last active December 7, 2018 22:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save SimonKrughoff/ba47bdba4396921ba3878144600d0889 to your computer and use it in GitHub Desktop.
Save SimonKrughoff/ba47bdba4396921ba3878144600d0889 to your computer and use it in GitHub Desktop.
Download ZIP
Comments for sqr-016
Raw
comments.md
  • 1.1.1 broken link to CLO.
  • 1.1.2 broken link to pipelines_lsst_io
  • 1.1.2 typos in clo-stubb
  • 1.1.2 pipelines_lsst_io didn't make it into provingground-larry
  • 1.1.2 It's not clear to me how the version string is chosen. Is this just an N+1 from the last release? If so, how do I find out N?
  • 1.1.3 It could be clearer how to find the weekly git tags. I.e. go to the tags panel of the branches pulldown and search on w.2018.*
  • 1.2.1 broken link to release/official-release
  • 1.2.1 git release tag suggested syntax disagrees with the suggestion in the Run dialog on Jenkins: v42.0.0.rc1 vs. v16.0.rc1. It is also a little confusing that the release numbering seems to be coming from the number of the weekly in the release playbook. I don't think that's what we have been doing.
  • 1.2.1 I think we also need to includ instructions on how to whitelist signatures. This came up in DM-16487. Since we can't make sure this is a one time process, we'll need to provide instructions on how to deal with it.
  • 1.2.1 It appears that annotated tags don't show up in the Github UI. It would be good to mention that if you want to inspect the tags after the build is done, you should clone the repos and use the git cli.
  • 1.3 Mentioned in other notes, markdown is broken in the second paragraph.
  • 1.3.1 FWIW, I think we should commit to release branch, review and merge to master, since we need a branch to merge to master anyway.
  • 1.3.1 Here and after, when you say v42.0.x, you mean v42.0.1 for the first branch, 'v42.0.1` for the second and so on.
  • 1.3.2 broken link to stack-os-matrix.
  • 1.3.3 branch(es)t --> branch(es)
  • 1.4 second paragraph As consequence --> A consequence
  • 1.4 the release branches should be merged to master before the final release (I believe). This results in the rc tag being on the commit behind HEAD of master since we suggest merging with --no-ff. Checking out the release tag results in a detatched head state. I don't think this is a problem, but is it potentially confusing?
  • 1.4 regardless of the answer above, we should describe the process for merging release branches after passing tests.
  • 1.4.1 broken markdwon in third paragraph.
  • 1.4.1 shouldn't the O_LATEST flag be set to true in Example 1?
  • 1.4.2 broken link to lsst/lsst
  • 1.4.2 confuses me:
    • Is v42.0.x the same tag from 1.3.1?
    • Shouldn't this be the release tag: i.e. without the v?
    • How does this release branch make it back to master?
  • 1.4.3 I realized I don't understand how the pipelines_lsst_io release branch relates to things. I have similar questions as to the branch of lsst/lsst. I.e. does the release branch really differ from the release tag name, and does it ever land back on master?

c.l.o stubb comments

  • It doesn't seem to self consistent: i.e. the summary says release is complete and the Release Engineering Steps seems to be at the step just after rc1. It seems reasonable to make it self consistent with the start of the release process.
  • 1.Repeat last 2 steps --> 1. Repeat last 2 steps
  • The stub mentions binary releases, but that is not touched on in the above release notes. Doesn't the release job just do this?
  • 1.5 include a pointer to the from-scratch installation instructions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment