Cosmos-sdk: Update point release protocol with new process

Created on 8 Oct 2020 · 7Comments · Source: cosmos/cosmos-sdk

Summary

We outlined a new point release protocol in the "Final Cosmos Github Org" document here. It needs to be added to the CONTRIBUTIONS.md file of the repository in the appropriate format.

Actually 3 tasks here:

[ ] Strategy Discovery
[ ] Concept Approval
[ ] Implementation & Release Approval

Notedly still missing is the process for __Strategy Discovery__, which should maybe get made into a new issue.

Problem Definition

Proposal

3 Stages (Original Document)
- Strategy Discovery
  - Develop long term priorities, strategy and roadmap for the SDK
  - Release committee not yet defined as there is already a roadmap that can be used for the time being
- Concept Approval
  - Time bound period for Request for Comment (RFC) on Architectural Decision Records (ADR)
  - Release committee criteria
    - Participation in all or almost all ADR discussions
    - Are they already active contributors?
      - Are they constantly making substantial contributions to the project's codebase, review process, documentation or RFC?
    - Do they have a stake in the Cosmos SDK?
      - Are they a client of the SDK?
      - Are they “giving back” to the software?
    - Code owners need to maintain participation in a process
      - Delegate representation in case of vacation or absence
    - ⅔ approval from these initial three
      - Aaron (Regen), Bez (Fission), Alessio (AiB)
    - Secondary pool of candidates to replace / substitute
      - Chris Goes (IG), Sunny (Sikka)
    - Removal
      - Missing 3 meetings results in ICF evaluating whether the member should be removed / replaced
      - Violation of Code of Conduct
- Implementation & Release Approval
  - Ensure the PR does exactly what the ADR said it should
  - More senior engineering capability
  - ⅔ approval from these initial three
    - Aaron, Bez & Alessio
  - Secondary pool of candidates to replace / substitute
    - Marko, Federico, Jonathan & Cory
  - Removal
    - Missing 3 meetings results in ICF evaluating whether the member should be removed / replaced
    - Violation of Code of Conduct
Addition to committee can be recommended by anyone to the current group or the ICF directly
- The evaluation criteria will be considered and the committee will decide on the addition with final approval from the ICF

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Source

okwme

👍4

All 7 comments

Concept Approval

Time bound period for Request for Comment (RFC) on Architectural Decision Records (ADR)

Is there a proposed time frame?

Implementation & Release Approval

Ensure the PR does exactly what the ADR said it should

More senior engineering capability

⅔ approval from these initial three

Aaron, Bez & Alessio

Secondary pool of candidates to replace / substitute

Marko, Federico, Jonathan & Cory

Is this a proposed change to our PR approval process?

If so, I think requiring 2/3 approval from the three of us (or our representatives) would bring development to a halt for all teams.

Right now we have 1 approval as _required_ for PRs, but 2 approvals is the recommended practice and what is required for automerge. If there are mistakes, they can always be corrected in later PRs and anyone is welcome to request changes to any PR at any time.

I do not see the current system as broken and I'm not aware of anyone complaining because PRs are getting merged without enough approvals. Maybe it's happened for individual PRs, but that gets cleaned up. If anything people are already waiting too long for reviews.

aaronc on 8 Oct 2020

It's my understanding that the concept approval section would apply to any ADRs (all of which are made against master).

However, the implementation section I think is only meant to apply to PRs into a release branch, (e.g. launchpad/backports, or the new v0.40.x branch for stargate). Is that correct @okwme ?

Currently we essentially already hve this process underway for Launchpad with myself, Alessio & Ethan F as the release committee. I cannot remember exactly what those access controls are but they may even require 3/3 consensus, @alessio ?

It's worth clarifying what "approval" actually means for cutting a major release too, and at which point, if any, we put access control restrictions on a release branch. The v0.40.x is currently live, and so we technically should be putting access control restrictions on it already, but I also share @aaronc's concern that this may unnecessarily slow down development depending on who is on the release committee.

clevinson on 9 Oct 2020

Dropping here my thoughts that I shared in the last call:

RFC process should be distinct from Release Management.
RFC process decisions should be taken with +2/3 majority - no veto power whatsoever should be granted. When an RFC is raised, ADR Committee members should be given a reasonable amount of time (e.g. a few weeks review round?) to review + 1 week to approve or ask for changes/reject. Members of the committee should be allowed to delegate their voting rights temporarily on a case by case basis to reputable member of the Community - elected in agreement with the other members of the committee.
Each Release Series should have its own Stable Release Policy and its own Stable Release team (max 3 people for each release team IMHO, and same people can sit as SRM for multiple SRM teams). Rationale is we should try to avoid overloading people with work.
PRs to stable branches should be approved by consensus. Stable Release policies are the references, they set the rules and describe the process to go about granting exceptions - that makes reaching consensus easy.

alessio on 15 Oct 2020

👍1

Hey - any news on this?

alessio on 4 Nov 2020

@clevinson

It's my understanding that the concept approval section would apply to any ADRs (all of which are made against master).

However, the implementation section I think is only meant to apply to PRs into a release branch, (e.g. launchpad/backports, or the new v0.40.x branch for stargate). Is that correct @okwme ?

That's my understanding as well. No changes to the current merging process @aaronc except that RFC/ADR merges into master should have +2/3 approvals. We don't need to put actual access control restrictions on this process since github would have a hard time understanding which PRs were RFC/ADR. We would just want to ensure it ourselves.

WRT releases I'd also suggest that this 2/3 should not apply to release candidates, just the final release.

@aaronc These should not greatly modify (or modify at all) the current process and if you are still concerned it would slow things down I'd like to understand how we can modify them so they do not. The only difference from now I can see is that RFC/ADRs _require_ 2 approvals (even if it's technically possible to merge it with only 1). If it is taking too long to get 2 approvals with the current configuration let's address the reason why and figure out what is needed: more eligible reviewers? more direct compensation? a dedicated "reminder" role?

It seems that we could merge these into CONTRIBUTIONS.md and would be following them regardless for the Stargate release. If they were merged before then we could technically say that we followed this "new" release method which would actually mean a lot.

okwme on 12 Nov 2020

👍1

This matches my understanding of the release process needs for the community, the spirit of the conversations we've had between stakeholders and I am excited to see it merged.