Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: Attempt to flesh out the different release responsibilities #20851

Merged
merged 7 commits into from
Apr 29, 2022
Merged

docs: Attempt to flesh out the different release responsibilities #20851

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
71a5d41
docs: Attempt to flesh out the different release responsibilities
RyanTheOptimist Apr 15, 2022
257b3a3
Reference GOVERNANCE.md
RyanTheOptimist Apr 15, 2022
a887c45
Address comments
RyanTheOptimist Apr 18, 2022
32aeb51
Move stable release process from GOVERNANCE.md to RELEASES.md
RyanTheOptimist Apr 25, 2022
34f3d3f
Merge branch 'main' into ReleaseDocs
RyanTheOptimist Apr 25, 2022
58837c9
Address comments
RyanTheOptimist Apr 26, 2022
1db0a72
New version steps
RyanTheOptimist Apr 26, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 34 additions & 18 deletions RELEASES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,11 @@ Active development is happening on the `main` branch, and a new version is relea

Stable releases of Envoy include:

TODO(RyanTheOptimist): It seems to me that we have two kinds of releases and it would be helpful for
this doc to make a clear distinction between them. For the sake of argument, I've called them
"Major Release" (v1.22) and "Security Releases" (v1.22.1, etc). Does this terminology work?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we effectively have 3 (well 2 with 1 having 2 subtypes):

  1. Major release
  2. Minor release (security)
  3. Minor release (stability)

The release mechanics for 2 and 3 are very similar, there is just more private coordination required for 2.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, interesting. I wasn't aware that we did minor releases for non-security reasons. Are these ad-hoc releases, or are they scheduled in some way? Presumably we should talk about these releases in this doc somewhere?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are basically ad-hoc and best effort. It's essentially if someone wants to do the work. I agree we should discuss this option and make it clear that it's best effort and requires people to volunteer for release work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I've updated this section to hopefully make this point clear. WDYT?


* Major releases in which a new version a created directly from the `main` branch.
* Extended maintenance window (any version released in the last 12 months).
* Security fixes backported from the `main` branch (including those deemed not worthy
of creating a CVE).
Expand All @@ -27,6 +32,7 @@ to execute tests on it.
Critical security fixes are owned by the Envoy security team, which provides fixes for the
`main` branch. Once those fixes are ready, the maintainers
of stable releases backport them to the remaining supported stable releases.
TODO(RyanTheOptimist): Should this perhaps mention that this process is not "in-the-clear"?

### Backports

Expand All @@ -42,23 +48,29 @@ schedule, initially aiming for the bi-weekly releases.

### Release management

Release managers of stable releases are responsible for approving and merging backports, tagging
stable releases and sending announcements about them. This role is rotating on a quarterly basis.

| Quarter | Release manager |
|:-------:|:--------------------------------------------------------------:|
| 2020 Q1 | Piotr Sikora ([PiotrSikora](https://github.com/PiotrSikora)) |
| 2020 Q2 | Piotr Sikora ([PiotrSikora](https://github.com/PiotrSikora)) |
| 2020 Q3 | Yuchen Dai ([lambdai](https://github.com/lambdai)) |
| 2020 Q4 | Christoph Pakulski ([cpakulski](https://github.com/cpakulski)) |
| 2021 Q1 | Rei Shimizu ([Shikugawa](https://github.com/Shikugawa)) |
| 2021 Q2 | Dmitri Dolguikh ([dmitri-d](https://github.com/dmitri-d)) |
| 2021 Q3 | Takeshi Yoneda ([mathetake](https://github.com/mathetake)) |
| 2021 Q4 | Otto van der Schaaf ([oschaaf](https://github.com/oschaaf)) |
| 2022 Q1 | Otto van der Schaaf ([oschaaf](https://github.com/oschaaf)) |
| 2022 Q2 | Pradeep Rao ([pradeepcrao](https://github.com/pradeepcrao)) |

## Release schedule
Major releases are handled by Matt Klein ([mattklein123](https://github.com/mattklein123))
or Alyssa Wilk ([alyssawilk](https://github.com/alyssawilk)) and do not involve any backports.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice if other people did this. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Completely agree :) Should we set up a rotation? I'd be happy to add a column to the schedule below.

Are there any steps in the stable release process with require a repo admin? (I seem to recall needing repo admin help from repo admins in the security release process).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure a rotation would be great. I think it might require an admin to actually make the release (I'm not sure) but that is a tiny step.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I talked to @alyssawilk about this and she proposed making this the responsibility of the on-call maintainer, which makes a lot of sense to me. It's not much work in the grand scheme of things so it should fit nicely on that person's plate.

The details are outlined in the "Cutting a release" section of [GOVERNANCE.md](GOVERNANCE.md).
Security releases are handled by a Release Manager and a Fix Lead. The Release Manager is
responsible for approving and merging backports. The Fix Lead is a member of the security
team and is responsible for coordinating the overall release. This includes identifying
issues to be fixed in the release, communications with the Envoy community, and the
actual mechanics of the release itself.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to link to the docs here? is there anything private in the doc?

AFIK the release manager generally responsible for doing backports for releases.

Also somewhere maybe we should outline all the responsibilities for the role? Right now they're docced up here https://docs.google.com/document/d/1AnIqmJlGlN0nZaxDme2uMjcO9VJxIokGDMYsq2IZM98/edit but we could fold the content in here and delete that doc?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I didn't realize that doc existed. I added a link to it. But I'd be happy to inline it here, if you think that would be better?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I think inlining would be better but you're already voluntering for enough improvements so your call :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do! But I'll do it in a follow up so as not to drag this PR out any longer.

alyssawilk marked this conversation as resolved.
Show resolved Hide resolved

| Quarter | Release Manager | Fix Lead |
|:-------:|:--------------------------------------------------------------:|:----------------------------------------------------------------------|
| 2020 Q1 | Piotr Sikora ([PiotrSikora](https://github.com/PiotrSikora)) | |
| 2020 Q2 | Piotr Sikora ([PiotrSikora](https://github.com/PiotrSikora)) | |
| 2020 Q3 | Yuchen Dai ([lambdai](https://github.com/lambdai)) | |
| 2020 Q4 | Christoph Pakulski ([cpakulski](https://github.com/cpakulski)) | |
| 2021 Q1 | Rei Shimizu ([Shikugawa](https://github.com/Shikugawa)) | |
| 2021 Q2 | Dmitri Dolguikh ([dmitri-d](https://github.com/dmitri-d)) | |
| 2021 Q3 | Takeshi Yoneda ([mathetake](https://github.com/mathetake)) | |
| 2021 Q4 | Otto van der Schaaf ([oschaaf](https://github.com/oschaaf)) | |
| 2022 Q1 | Otto van der Schaaf ([oschaaf](https://github.com/oschaaf)) | Ryan Hamilton ([RyanTheOptimist](https://github.com/RyanTheOptimist)) |
| 2022 Q2 | Pradeep Rao ([pradeepcrao](https://github.com/pradeepcrao)) | TBD |

## Major release schedule

In order to accommodate downstream projects, new Envoy releases are produced on a fixed release
schedule (the 15th day of each quarter), with an acceptable delay of up to 2 weeks, with a hard
Expand All @@ -79,4 +91,8 @@ deadline of 3 weeks.
| 1.22.0 | 2022/04/15 | 2022/04/15 | 0 days | 2023/04/15 |
| 1.23.0 | 2022/07/15 | | | |

[repokitteh]: https://github.com/repokitteh
## Security release schedule

There is no fixed scheduled for security fixes. Zero-day vulnerabilities might necessitate
an emergency release with little or no warning. However, historically security release have
happened roughly once per quarter, midway between major releases.