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

proposals: add release-approval-process #15

Closed
wants to merge 18 commits into from
Closed

proposals: add release-approval-process #15

Changes from 1 commit
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
bdfa70d
proposals: add release-approval-process
Jun 9, 2016
1e3b643
proposal: release-approval-process add some motivation
Jun 10, 2016
66fce91
proposals: release approval process to one week for apps
Jun 14, 2016
da906b9
proposals: release approval process 3 rcs required
Jun 14, 2016
b01dc6c
proposals: release approval process: one month pre-releases
Jun 14, 2016
ff453b6
proposals: release approval process: use consistent language for rejects
Jun 14, 2016
86a3255
proposals: release approval process: clarify utility of GitHub
Jun 14, 2016
d6a6dbe
proposals: release-approval-process: add voting members language
Jun 14, 2016
33d5a19
proposals: release approval process: add quorum language
Jun 15, 2016
78d6c1e
proposals: release approval process: add language about mailing list
Jun 15, 2016
4206adb
proposals: release approval process: add information to projects
Jun 15, 2016
abd3704
proposals: release approval process: improve REJECT feedback
Jun 15, 2016
fb003ff
proposals: release-approval-process: fixup additional typos
Jun 16, 2016
77305d8
release-approval: Shuffle to make more DRY
wking Jun 16, 2016
ebae4ac
release-approval: Add non-spec unanimous quorum reduction
wking Jun 17, 2016
7599a0f
proposals: release-approval-process fix a grammar thing
Jun 22, 2016
9553cfe
proposal: fix a typo
Jun 22, 2016
37088fb
proposals: release approval process explain security@ email
Jun 25, 2016
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
Prev Previous commit
Next Next commit
proposal: release-approval-process add some motivation 
I got some feedback from folks that some motivation early in the
document might be helpful for why the process encourages regular
communication.
  • Loading branch information
Brandon Philips committed Jun 14, 2016
commit 1e3b64326bc00aa502ad1e068b43671fa5a28295
4 changes: 3 additions & 1 deletion proposals/release-approval-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,11 @@

OCI projects need a standard process for making releases so the community of maintainers can consistently know when something can be tagged and released. As the OCI maintains three categories of projects: specifications, applications, and conformance/testing tools we will set different rules for each.

This approval process hopes to encourage early consistent consensus building during project and specification development. The mechanisms used are regular community communication on the mailing list about progress, scheduled meetings for issue resolution and release triage, and regularly paced and communicated releases. An anti-pattern that we want to avoid is heavy development or discussions "late cycle" around major releases. We want do build a community that is involved and communicates consistently through all releases instead of relying on "silent periods" as a judge of stability.

## Specifications

**Planning a release:** Every OCI specification project SHOULD hold a weekly meeting that involves maintainers reviewing pull requests, debating outstanding issues, and planning releases. This meeting MUST be advertised on the project README and MAY happen on a phone call, video conference, or on IRC. Maintainers MUST send updates to the dev@opencontainers.org with results of these meetings. Maintainers MAY change the meeting cadence once a specification has reached v1.0.0. The meeting cadence MUST NOT be greater than once every four weeks The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. https://github.com/opencontainers/runtime-spec/milestones).
**Planning a release:** Every OCI specification project SHOULD hold a weekly meeting that involves maintainers reviewing pull requests, debating outstanding issues, and planning releases. This meeting MUST be advertised on the project README and MAY happen on a phone call, video conference, or on IRC. Maintainers MUST send updates to the dev@opencontainers.org with results of these meetings. Maintainers MAY change the meeting cadence once a specification has reached v1.0.0. The meeting cadence MUST NOT be greater than once every four weeks The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. https://github.com/opencontainers/runtime-spec/milestones).

**Making a release:** OCI specification projects MUST announce intentions to release with two project maintainer sponsors (listed in the repo MAINTAINERS file) on the dev@opencontainers.org mailing list. After the announcement a two-thirds super majority of project maintainers MUST reply to the list with an LGTM within one week for the release to be approved. The maintainers MUST wait a full week for maintainers to reply but if all maintainers reply with an LGTM then the release MAY release earlier except in the case of a major releases.
Copy link

Choose a reason for hiding this comment

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

Maybe a different criteria for a major vs minor release will help. For e.g. 0.1 should require LGTM from half but 1.0 should require 2/3 LGTMs.

Copy link
Contributor

Choose a reason for hiding this comment

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

The last sentence reads a bit strangely around the MUST to me. How about replacing the last two sentences with:

A release is approved a week after the announcement if at least two-thirds of maintainers LGTM the release. Minor and point releases MAY be approved earlier if all maintainers LGTM the release.

And that also gives space for @mrunalp's different thresholds.

Copy link
Contributor

Choose a reason for hiding this comment

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

On Thu, Jun 09, 2016 at 01:48:30PM -0700, Mrunal Patel wrote:

Maybe a different criteria for a major vs minor release will
help. For e.g. 0.1 should require LGTM from half but 1.0 should
require 2/3 LGTMs.

What about 1.1.0? The charter's only Member out for “I don't like
that release” is “then you can quit” 1. If that applies to minor
and point releases (and in the absence of wording to the contrary I
expect it does), then I think we want to be cautious about them as
well.

 §8.d

Copy link
Contributor

Choose a reason for hiding this comment

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

A release should be preceded with a release proposal, giving reasoning about how the release meets the requirements of the release. If any requirements for the release are not met, but the proposal is to proceed despite the lack of met requirements, this should be called out.

Copy link

@anuthan anuthan Jun 10, 2016 •
edited
Loading

Choose a reason for hiding this comment

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

I would also request that we get a LGTM from one of the platform specific parties for "Making a release". As in atleast one LGTM for Linux , one from Windows and one from Solaris or whoever is contributing to the specified project. We can keep a time limit for this response as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

On Fri, Jun 10, 2016 at 12:17:22PM -0700, Abhijeeth Nuthan wrote:

I would also request that we get a LGTM from one of the platform
specific parties for "Making a release". As in atleast one LGTM for
Linux , one from Windows and one from Solaris or whoever, is
contributing to the specified project.

I don't think there's a need to call that out. Platforms who wish to
be represented should have maintainers they trust (and/or employ) on
the project, and expect the maintainers to respect any per-platform
concerns raised (just as concerns from anybody should be respected,
#17).

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 agree we don't need to call this out. Maintainers should be trusted to make the right call, and platform maintainers should make their case to the relevant channels. It is pretty clear how this stuff should work based on the OCI gov. docs 5.d: "The primary means for any organization to influence the technical direction of the OCI Projects is via contribution or service as maintainers. "


Expand Down