1. 27 6月, 2019 1 次提交
  2. 26 6月, 2019 5 次提交
  3. 20 6月, 2019 1 次提交
  4. 18 6月, 2019 2 次提交
  5. 17 6月, 2019 4 次提交
  6. 15 6月, 2019 1 次提交
  7. 14 6月, 2019 1 次提交
  8. 13 6月, 2019 2 次提交
  9. 12 6月, 2019 3 次提交
  10. 11 6月, 2019 2 次提交
  11. 07 6月, 2019 1 次提交
  12. 06 6月, 2019 5 次提交
  13. 05 6月, 2019 4 次提交
    • B
      Update instructions for the release shepherd · adfc5aaa
      beorn7 提交于
      This codifies how 2.10 was released. It removes the inconsistency of
      freezing master for pre-releases but handling post-release bug fixes
      in a separate branch.
      
      The previous instructions came from a time where master was often in
      bad shape. However, that's a problem of its own, which should be
      avoided at all times and not only when a release is imminent. On other
      words, freezing master can still happen if it is in bad shape and we
      need a break from feature development and just fix the bugs for a
      while. However, it should not happen as a formal step during the
      release of a release candidate. On the contrary, a release candidate
      is not really a release candidate if we already know it is in such a
      bad shape that we need bug fixes. On the other hand, if we truly
      believe the RC could be identical to the final release, there is no
      need to freeze master.
      
      I can explain more of the concept if there is still a need for
      clarification.
      Signed-off-by: Nbeorn7 <beorn@grafana.com>
      adfc5aaa
    • B
      Merge pull request #5632 from prometheus/juliusv-release-shepherd · 1a26dd6c
      Björn Rabenstein 提交于
      Add next three release shepherds
      1a26dd6c
    • B
      Replace Ganesh with Frederic for 2.11 · ac8d10f6
      beorn7 提交于
      Signed-off-by: Nbeorn7 <beorn@grafana.com>
      ac8d10f6
    • J
      Add next three release shepherds · 1299a737
      Julius Volz 提交于
      Signed-off-by: NJulius Volz <julius.volz@gmail.com>
      1299a737
  14. 29 5月, 2019 6 次提交
  15. 28 5月, 2019 2 次提交