8000 conda pilot/co-pilot release process by LtDan33 · Pull Request #49 · conda/ceps · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

conda pilot/co-pilot release process #49

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.

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
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
94 changes: 94 additions & 0 deletions new-cep.md
10000
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
# Conda Release Process Proposal

| Title | Conda Release Process |
| -------------------- | ---------------------------------------------- |
| Status | Draft |
| Author(s) | Dan Meador dan@anaconda.com> |
Comment on lines +5 to +6
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
| Status | Draft |
| Author(s) | Dan Meador dan@anaconda.com> |
| Author(s) | Dan Meador <dan@anaconda.com> |

| Created | April 19, 2023 |
| Updated | April 19, 2023 |
| Discussion | NA |
| Implementation | NA |

## Abstract

This proposal aims to establish a clear and efficient release process for conda (and other conda projects) by implementing a pilot and co-pilot system, ensuring a smooth transfer of responsibilities between team members and the continuous improvement of release quality. There will also be one "jump seat" available for those that want to sit in and observe the release process, but not be responsible for any of it.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
This proposal aims to establish a clear and efficient release process for conda (and other conda projects) by implementing a pilot and co-pilot system, ensuring a smooth transfer of responsibilities between team members and the continuous improvement of release quality. There will also be one "jump seat" available for those that want to sit in and observe the release process, but not be responsible for any of it.
This proposal aims to establish a clear and efficient release process for conda (and other conda projects) by implementing a pilot and co-pilot system, ensuring a smooth transfer of responsibilities between release managers and the continuous improvement of release quality. There will also be one "jump seat" available for those that want to sit in and observe the release process, but not be responsible for any of it.

Choose a reason for hiding this comment

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

@LtDan33 We were also thinking of the a QA member in a piece for release. Do we mention that as well


## Specification

* Each bi-monthyl (every two month) release will have a pilot and a co-pilot.(See [CEP-8](https://github.com/conda-incubator/ceps/blob/main/cep-8.md))
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* Each bi-monthyl (every two month) release will have a pilot and a co-pilot.(See [CEP-8](https://github.com/conda-incubator/ceps/blob/main/cep-8.md))
* Each release will have a pilot and a co-pilot. See [CEP-8](https://github.com/conda-incubator/ceps/blob/main/cep-8.md) for the release schedule.

* The pilot is the primary person responsible for the release, while the co-pilot provides assistance and fills in for the pilot when they are absent.
* Team members will switch roles from pilot to co-pilot from one release to the next, serving for three consecutive releases.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* Team members will switch roles from pilot to co-pilot from one release to the next, serving for three consecutive releases.
* Release managers will switch roles from pilot to co-pilot from one release to the next, serving for three consecutive releases. This is to encourage knowledge sharing.

* The pilot and co-pilot will be responsible for the release of a given conda (or another conda project) version.
* A "jump seat" will be available for those that want to sit in and observe the release process, but not be responsible for any of it.

### Rotation

Release 1: Pilot: **Bob Ross(new)**, Co-pilot: **Jane Doe(new)**

Release 2: Pilot: Jane Doe, Co-pilot: Bob Ross

Release 3: Pilot: Jane Doe, Co-pilot: **Tobby Smith(new)**

Release 4: Pilot: Tobby Smith, Co-pilot: Jane Doe

Release 5: Pilot: Tobby Smith, Co-pilot: **Elvis Presley(new)**

[pilots_conda](https://user-images.githubusercontent.com/6708083/233211589-10bca344-141e-407a-8edc-ca39014605eb.png)
Comment on lines +26 to +36
Copy link
Contributor

Choose a reason for hiding this comment

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

Mermaid chart!

flowchart TB
%% styles
classDef anna fill:#D0D0D0,stroke:#D0D0D0
classDef bert fill:#ED760E,stroke:#ED760E
classDef clay fill:#64C042,stroke:#64C042
classDef debi fill:#20214F,stroke:#20214F,color:#fff

%% role groups
subgraph pilots
  pilot1(Anna):::anna
  pilot2(Bert):::bert
  pilot3(Bert):::bert
  pilot4(Clay):::clay
  pilot5(Clay):::clay
  pilot6(Debi):::debi
  pilot7(Debi):::debi
  pilot8(Anna):::anna
end
subgraph co-pilots
  copilot1(Bert):::bert
  copilot2(Anna):::anna
  copilot3(Clay):::clay
  copilot4(Bert):::bert
  copilot5(Debi):::debi
  copilot6(Clay):::clay
  copilot7(Anna):::anna
  copilot8(Debi):::debi
end

%% Anna flow
pilot1-->copilot2
copilot7-->pilot8

%% Bob flow
copilot1-->pilot2-->pilot3-->copilot4

%% Charlie flow
copilot3-->pilot4-->pilot5-->copilot6

%% Denese flow
copilot5-->pilot6-->pilot7-->copilot8

%% Responsibility flow
pilot1-.->pilot2
pilot3-.->pilot4
pilot5-.->pilot6
pilot7-.->pilot8
copilot1-.->copilot2-.->copilot3-.->copilot4-.->copilot5-.->copilot6-.->copilot7-.->copilot8
Loading
Suggested change
Release 1: Pilot: **Bob Ross(new)**, Co-pilot: **Jane Doe(new)**
Release 2: Pilot: Jane Doe, Co-pilot: Bob Ross
Release 3: Pilot: Jane Doe, Co-pilot: **Tobby Smith(new)**
Release 4: Pilot: Tobby Smith, Co-pilot: Jane Doe
Release 5: Pilot: Tobby Smith, Co-pilot: **Elvis Presley(new)**
[pilots_conda](https://user-images.githubusercontent.com/6708083/233211589-10bca344-141e-407a-8edc-ca39014605eb.png)
```mermaid
flowchart TB
%% styles
classDef anna fill:#D0D0D0,stroke:#D0D0D0
classDef bert fill:#ED760E,stroke:#ED760E
classDef clay fill:#64C042,stroke:#64C042
classDef debi fill:#20214F,stroke:#20214F,color:#fff
%% role groups
subgraph pilots
pilot1(Anna):::anna
pilot2(Bert):::bert
pilot3(Bert):::bert
pilot4(Clay):::clay
pilot5(Clay):::clay
pilot6(Debi):::debi
pilot7(Debi):::debi
pilot8(Anna):::anna
end
subgraph co-pilots
copilot1(Bert):::bert
copilot2(Anna):::anna
copilot3(Clay):::clay
copilot4(Bert):::bert
copilot5(Debi):::debi
copilot6(Clay):::clay
copilot7(Anna):::anna
copilot8(Debi):::debi
end
%% Anna flow
pilot1-->copilot2
copilot7-->pilot8
%% Bob flow
copilot1-->pilot2-->pilot3-->copilot4
%% Charlie flow
copilot3-->pilot4-->pilot5-->copilot6
%% Denese flow
copilot5-->pilot6-->pilot7-->copilot8
%% Responsibility flow
pilot1-.->pilot2
pilot3-.->pilot4
pilot5-.->pilot6
pilot7-.->pilot8
copilot1-.->copilot2-.->copilot3-.->copilot4-.->copilot5-.->copilot6-.->copilot7-.->copilot8


### Pilot Responsibilities

* Responsible and accountable for the release of a given conda (or another conda project) version.
* Ensure that users are able to successfully update to the latest version and that no critical bugs or issues arise as part of the release.
* Be the known go-to liaison if there is a potentially critical issue, and take point in addressing/fixing it.
* Responsible for getting the co-pilot prepared to be a pilot by being a teacher and ensuring that they will be able to take over the process next time.

### Co-pilot Responsibilities

* Responsible for certain roles or activities for a given conda (or another project) version.
* Be an extra set of eyes to help the pilot get to the correct outcome.
* Help with communication with the team and the broader community.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* Help with communication with the team and the broader community.
* Help with communication across the broader community.

* Learn as an active participant in the process, not meant to simply be "on deck" for the next time.

### Jump seat Responsibilities
* None. This is simply for someone that wants to just be along for the ride and learn by observing. This is not meant to be a "backup" or "on deck" role. This is an intentional choice in order to prevent the "too many cooks in the kitchen" problem as even though there might be good intentions, it can be distracting and confusing to have too many people involved in the process. With all that said there is benefits to allowing someone to just sit in and observe, so this is a compromise as this isn't meant to be a secret process, but it is meant to be a focused process as issues can arise at any time and the pilot and co-pilot need to be able to focus on the task at hand.

### Special Note for Previous Pilots

* If you are coming from being the pilot on the previous release, then make sure to help and guide the current pilot if there are any questions that come up.

## Motivation

The proposed release process is necessary to ensure a high-quality, consistent, and efficient release cycle for conda and related projects. The pilot and co-pilot system encourages knowledge transfer, collaboration, and continuous improvement.

## Rationale

The pilot and co-pilot model has been proven to work well in other projects, ensuring that there is always at least one person with the necessary experience and knowledge to handle releases, while also providing opportunities for other team members to learn and grow. This inspiration came from seeing how PyCon US has run their conference where the same city runsthe conference twice in a row, with the second year providing an opportunity for the next years city to learn from the previous years city.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
The pilot and co-pilot model has been proven to work well in other projects, ensuring that there is always at least one person with the necessary experience and knowledge to handle releases, while also providing opportunities for other team members to learn and grow. This inspiration came from seeing how PyCon US has run their conference where the same city runsthe conference twice in a row, with the second year providing an opportunity for the next years city to learn from the previous years city.
The pilot and co-pilot model has been proven to work well in other projects, ensuring that there is always at least one person with the necessary experience and knowledge to handle releases, while also providing opportunities for others to learn and grow. This inspiration came from seeing how PyCon US has run their conference where the same city runs the conference twice in a row, with the second year providing an opportunity for the next years city to learn from the previous years city.


## Alternatives

1. Have a dedicated release manager role, but this would limit the opportunities for team members to learn and grow, and it may create a single point of failure if the release manager becomes unavailable.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
1. Have a dedicated release manager role, but this would limit the opportunities for team members to learn and grow, and it may create a single point of failure if the release manager becomes unavailable.
1. Have a dedicated release manager role, but this would limit the opportunities for the community at large to learn and grow, and it may create a single point of failure if the release manager becomes unavailable.


## Sample Implementation

N/A

## FAQ

Q) Who can be a Pilot/copilot on a release?
A) Must be a core conda team member.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested cha 6D4E nge
A) Must be a core conda team member.
A) Must be a maintainer of conda (or other conda project being released).


Q) Conda broke on a Saturday due to a late Friday release, who should fix it?

A) The pilot is accountable for ensuring that critical conda issues due to the release are addressed. We simply have too many users that could be in an unusable state to not address this. Its recommended that we don’t release on a Friday for this reason.
Comment on lines +80 to +82
Copy link
Contributor

Choose a reason for hiding this comment

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

Per CEP-8, Friday releases are not allowed, the absolute latest in a week a release can occur is on a Thursday.


Q) How long should we wait to give the “all clear” that the release didn’t break anything?

A)

Q) I am in the rotation but would like out, how can do that?

A) If for whatever reason you can’t be the pilot/copilot for a release, then let the respective team members (Pilot or copilot) know with as much heads up as possible so a replacement can be found.

## Resolution


0