1. 05 May, 2019 1 commit
  2. 08 Apr, 2019 1 commit
    • intrigeri's avatar
      Release process: generate the expected OpenPGP signature verification output... · 40aa8198
      intrigeri authored
      Release process: generate the expected OpenPGP signature verification output in a more deterministic way (refs: #16585)
      
      Using --trusted-key avoids this warning:
      
        gpg: WARNING: This key is not certified with a trusted signature!
        gpg:          There is no indication that the signature belongs to the owner.
      
      … and makes our signing key trusted at the "ultimate" level.
      
      So let's also s/ultimate/full/ to stick closer to what users should
      get once they verify our key via the WoT and certify it locally.
      40aa8198
  3. 23 Mar, 2019 6 commits
    • intrigeri's avatar
      Release process: document what the $NEXT*VERSION variables are used for (refs: #16600) · 5db3b595
      intrigeri authored
      This should help understand the implications of changing their value
      in the middle of the release process.
      5db3b595
    • intrigeri's avatar
      Release process: clarify variable vs. constant (refs: #16600) · c832a971
      intrigeri authored
      Some of the trouble kibi suffered from was caused by changing the value of
      $NEXT_PLANNED_MAJOR_VERSION in the middle of the release process. Let's clarify
      that these variables should be thought of as constants throughout the
      release process.
      c832a971
    • intrigeri's avatar
      8c8d5467
    • intrigeri's avatar
      Release process: clarify what does not need to be adapted (refs: #16600) · 9b428474
      intrigeri authored
      Given we're going to have a bunch of bugfix releases in a row, recent RMs have
      been tempted to set $NEXT_PLANNED_MAJOR_VERSION to one of them, assuming that if
      they didn't do so, the rest of our release process doc would be buggy because
      said doc assumes strictly alternating bugfix/major releases. AFAIK this is not
      the case: to the best of my knowledge, the release process doc makes no such
      assumption anymore (it used to, but we've been in such a situation already
      and had to make the doc support it).
      
      So clarify that this part of the release process doc can be followed blindly.
      9b428474
    • intrigeri's avatar
      Release process: avoid having to guess when it's not needed (refs: #16600) · dd14b778
      intrigeri authored
      kibi wrote "one is expected to know about the next major release, and about the
      one after that". I assume that's about $SECOND_NEXT_PLANNED_MAJOR_VERSION.
      In the general case, indeed we don't always know what that version will be.
      
      Thankfully, we only need this variable when preparing a RC for a major release,
      in which case all the RM needs to know is 1. the version number of that major
      release (the RM has to know that anyway); and 2. the version number of the major
      release after the one the they're preparing (in general we have a release
      schedule for the next 6-12 months, which includes this info).
      
      So let's only set this variable when we need it, i.e. when it's rather easy
      to find out what its value should be: as kibi said, right now we have
      no idea what will be the major release after 3.17.
      dd14b778
    • intrigeri's avatar
      d9cc68c5
  4. 22 Mar, 2019 5 commits
  5. 21 Mar, 2019 17 commits
  6. 19 Mar, 2019 2 commits
  7. 07 Mar, 2019 6 commits
    • intrigeri's avatar
      Release process: group path arguments on one side and version-related... · e390dd34
      intrigeri authored
      Release process: group path arguments on one side and version-related arguments on another (refs: #16405).
      e390dd34
    • intrigeri's avatar
      Release process: explain both the general case and exceptional ones wrt. UDF... · d46c4837
      intrigeri authored
      Release process: explain both the general case and exceptional ones wrt. UDF generation (refs: #16405).
      
      commit:625ceaf0 automated the general
      case, which is super cool; but it also:
      
       - Removed all the (arguably very bad) instructions we had wrt. corner cases.
      
         Without any explanation whatsoever, most RMs won't be able to guess whether
         they're in one of these corner cases; I bet they'll always assume they're in
         the general case and run the example command as-is (while previously they
         would have asked someone more familiar with our incremental upgrade system
         what they should do).
      
       - Left in place an explanation that did not match the code anymore.
      
      This commit adds explanations of what we're trying to achieve (from the user's
      PoV), how that's expressed in the example command, what the corner cases are and
      how to deal with them. Hopefully these explanations will be less mind-boggling
      than the previous version we had; even if they probably have plenty of problems,
      I hope they'll be a good enough basis that we can improve as needs arise.
      d46c4837
    • intrigeri's avatar
      Release process: automate all the UDF generation bits that can easily be (refs: #16405). · 79144c70
      intrigeri authored
      Again, let's avoid the RM having to think about things that can easily be
      automated, even if they're simple in isolation. Let them focus on the hard bits.
      
      Besides, this gets rid of all the "oh by the way you should have done X, Y and
      Z" the RM might discover after having run the example command already:
      the only changes they might have to apply to the example command are now
      documented _before_ the command itself.
      79144c70
    • intrigeri's avatar
    • intrigeri's avatar
      Release process: automate (refs: #16405). · 2c48af67
      intrigeri authored
      Let's avoid the RM having to think about things that can easily be automated,
      even if they're simple in isolation. Let them focus on the hard bits.
      2c48af67
    • intrigeri's avatar
      Release process: remove duplicate info (refs: #16405). · 25f8ab65
      intrigeri authored
      Much of our release process relies on the assumption that generated files land
      in some well-known directory, whose path is stored in an environment
      variable to allow RMs to configure it, e.g. $ISOS.
      
      So for example in this case, as long as one follows the instructions in the
      previous section, this constraint is satisfied already: IUKs are generated
      in $ISOS/.
      25f8ab65
  8. 06 Mar, 2019 1 commit
    • intrigeri's avatar
      Release process: make build settings expectations explicit (refs: #16476). · e98c7fce
      intrigeri authored
      According to anonym on https://redmine.tails.boum.org/code/issues/16476#note-23:
      
      1. The command now used on this branch:
      
             git fetch origin "${GIT_REF}"
      
         … will not overwrite a previously existing Git tag, while the command
         used previously:
      
             git fetch --tags
      
         … would.
      
      2. This is only a problem when we replace a tag as part of the regular release
         process, when using keeprunning or rescue. This can be solved with "rake
         vm:destroy" but having to discover that during the release process could
         be too stressful. The goal of this branch is to avoid developers wasting
         their time and having headaches, not to create more situations in which
         that will happen.
      
      So let's document explicitly what one MUST NOT do.
      e98c7fce
  9. 14 Feb, 2019 1 commit