From commits-return-32121-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Thu Feb 8 06:22:29 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id A68BC18065B for ; Thu, 8 Feb 2018 06:22:29 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 9661F160C5C; Thu, 8 Feb 2018 05:22:29 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id DAB88160C5B for ; Thu, 8 Feb 2018 06:22:28 +0100 (CET) Received: (qmail 22087 invoked by uid 500); 8 Feb 2018 05:22:27 -0000 Mailing-List: contact commits-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list commits@couchdb.apache.org Received: (qmail 22078 invoked by uid 99); 8 Feb 2018 05:22:27 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Feb 2018 05:22:27 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id B3148DF9FD; Thu, 8 Feb 2018 05:22:27 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: wohali@apache.org To: commits@couchdb.apache.org Message-Id: <3ccefd5928c74fa3a79b558ef4705194@git.apache.org> X-Mailer: ASF-Git Admin Mailer Subject: couchdb-www git commit: Strengthen requirements on backwards-incompatible API changes [Forced Update!] Date: Thu, 8 Feb 2018 05:22:27 +0000 (UTC) Repository: couchdb-www Updated Branches: refs/heads/api-wait-time 7ff1a95e6 -> 4a234b490 (forced update) Strengthen requirements on backwards-incompatible API changes Project: http://git-wip-us.apache.org/repos/asf/couchdb-www/repo Commit: http://git-wip-us.apache.org/repos/asf/couchdb-www/commit/4a234b49 Tree: http://git-wip-us.apache.org/repos/asf/couchdb-www/tree/4a234b49 Diff: http://git-wip-us.apache.org/repos/asf/couchdb-www/diff/4a234b49 Branch: refs/heads/api-wait-time Commit: 4a234b4900e9472d157222206ba9ec018a0f0468 Parents: 7a93d54 Author: Joan Touzet Authored: Thu Feb 8 00:13:28 2018 -0500 Committer: Joan Touzet Committed: Thu Feb 8 00:22:18 2018 -0500 ---------------------------------------------------------------------- bylaws.html | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/couchdb-www/blob/4a234b49/bylaws.html ---------------------------------------------------------------------- diff --git a/bylaws.html b/bylaws.html index dde2319..754c534 100644 --- a/bylaws.html +++ b/bylaws.html @@ -286,11 +286,13 @@

For electing a new Chair, the PMC may opt to use Single Transferable Vote (STV) which comes with its own rules. Apache STeVe was specifically designed to enable this process. -

3.5. RTC and Vetos

+

3.5. Review-Then-Commit, API Changes and Technical Vetos

Typically, CouchDB uses the Review-Then-Commit (RTC) model of code collaboration. RTC allows work to proceed on separate feature or bugfix branches, and requires at least one other developer to review and approve the changes before they are committed to a release branch. A release branch is any branch that a release might be prepared from, such as master, 1.6.x, and so on. Notifications of these changes are sent to the commits mailing list. It is expected that the rest of the community is regularly reviewing these changes. -

Any change made to a release branch is a technical decision of the project. If a committer wants to object to a technical decision, they have the option of casting a -1 vote. We call this a veto. Vetos can only be made for technical reasons. A -1 vote is not considered a veto in any other context. Vetos should be used sparingly, and only after careful consideration. +

Whenever a change is proposed to a release branch or master that removes or changes an existing HTTP API endpoint in a way that breaks backwards compatibility, the proposed change must be announced on the developer mailing list, and a minimum of a lazy consensus decision is required. Additions of new endpoints, or changes that do not affect backwards compatibility, do not require this notification and process, but announcement to the developer mailing list is still strongly encouraged.

+ +

Any change made to a release branch or to the master branch is a technical decision of the project. If a committer wants to object to a technical decision, they have the option of casting a -1 vote. We call this a veto. Vetos can only be made for technical reasons. A -1 vote is not considered a veto in any other context. Vetos should be used sparingly, and only after careful consideration.

All vetoes must be justified and vetoes without justification are null and void. The validity of the justification can be challenged and the outcome is decided with a vote. If the justification is valid, a veto cannot be overruled and stands until withdrawn by the caster. If you disagree with a veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, the commit must be reverted in a timely manner.