From patchwork Fri Jan 29 10:09:44 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Justin Pettit X-Patchwork-Id: 575501 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from archives.nicira.com (unknown [IPv6:2600:3c00::f03c:91ff:fe6e:bdf7]) by ozlabs.org (Postfix) with ESMTP id 11C3D140C35 for ; Fri, 29 Jan 2016 18:31:59 +1100 (AEDT) Received: from archives.nicira.com (localhost [127.0.0.1]) by archives.nicira.com (Postfix) with ESMTP id 7C25510C0A; Thu, 28 Jan 2016 23:31:58 -0800 (PST) X-Original-To: dev@openvswitch.org Delivered-To: dev@openvswitch.org Received: from mx3v3.cudamail.com (mx3.cudamail.com [64.34.241.5]) by archives.nicira.com (Postfix) with ESMTPS id 5AF8510C09 for ; Thu, 28 Jan 2016 23:31:57 -0800 (PST) Received: from bar4.cudamail.com (localhost [127.0.0.1]) by mx3v3.cudamail.com (Postfix) with ESMTPS id B10A51629C1 for ; Fri, 29 Jan 2016 00:31:56 -0700 (MST) X-ASG-Debug-ID: 1454052716-03dc217d9cb946d0001-byXFYA Received: from mx3-pf3.cudamail.com ([192.168.14.3]) by bar4.cudamail.com with ESMTP id L6w4d4rk63ILIcmm (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jan 2016 00:31:56 -0700 (MST) X-Barracuda-Envelope-From: jpettit@ovn.org X-Barracuda-RBL-Trusted-Forwarder: 192.168.14.3 Received: from unknown (HELO relay4-d.mail.gandi.net) (217.70.183.196) by mx3-pf3.cudamail.com with ESMTPS (DHE-RSA-AES256-SHA encrypted); 29 Jan 2016 08:05:33 -0000 Received-SPF: pass (mx3-pf3.cudamail.com: SPF record at ovn.org designates 217.70.183.196 as permitted sender) X-Barracuda-Apparent-Source-IP: 217.70.183.196 X-Barracuda-RBL-IP: 217.70.183.196 Received: from mfilter33-d.gandi.net (mfilter33-d.gandi.net [217.70.178.164]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 2A095172095 for ; Fri, 29 Jan 2016 08:31:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter33-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter33-d.gandi.net (mfilter33-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id GMu-9xJBpGMo for ; Fri, 29 Jan 2016 08:31:50 +0100 (CET) X-Originating-IP: 67.161.8.206 Received: from localhost.localdomain (c-67-161-8-206.hsd1.ca.comcast.net [67.161.8.206]) (Authenticated sender: jpettit@ovn.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 12F0817209B for ; Fri, 29 Jan 2016 08:31:49 +0100 (CET) X-CudaMail-Envelope-Sender: jpettit@ovn.org From: Justin Pettit To: dev@openvswitch.org X-CudaMail-Whitelist-To: dev@openvswitch.org X-CudaMail-MID: CM-V3-128000773 X-CudaMail-DTE: 012916 X-CudaMail-Originating-IP: 217.70.183.196 Date: Fri, 29 Jan 2016 02:09:44 -0800 X-ASG-Orig-Subj: [##CM-V3-128000773##][PATCH 1/3] Documentation: Add information about committer policies. Message-Id: <1454062186-29778-1-git-send-email-jpettit@ovn.org> X-Mailer: git-send-email 1.9.1 X-Barracuda-Connect: UNKNOWN[192.168.14.3] X-Barracuda-Start-Time: 1454052716 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://web.cudamail.com:443/cgi-mod/mark.cgi X-ASG-Whitelist: Header =?UTF-8?B?eFwtY3VkYW1haWxcLXdoaXRlbGlzdFwtdG8=?= X-Virus-Scanned: by bsmtpd at cudamail.com X-Barracuda-BRTS-Status: 1 Subject: [ovs-dev] [PATCH 1/3] Documentation: Add information about committer policies. X-BeenThere: dev@openvswitch.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dev-bounces@openvswitch.org Sender: "dev" These files were only available on the openvswitch.org mailing list. Move them to the source tree so that they're more visible. Signed-off-by: Justin Pettit Acked-by: Russell Bryant --- Documentation/automake.mk | 2 + Documentation/committer-grant-revocation | 345 +++++++++++++++++++++++++++++++ Documentation/committer-responsibilities | 76 +++++++ 3 files changed, 423 insertions(+) create mode 100644 Documentation/committer-grant-revocation create mode 100644 Documentation/committer-responsibilities diff --git a/Documentation/automake.mk b/Documentation/automake.mk index e504801..f38f99f 100644 --- a/Documentation/automake.mk +++ b/Documentation/automake.mk @@ -1,2 +1,4 @@ EXTRA_DIST += \ + Documentation/committer-responsibilities \ + Documentation/committer-grant-revocation \ Documentation/group-selection-method-property.txt diff --git a/Documentation/committer-grant-revocation b/Documentation/committer-grant-revocation new file mode 100644 index 0000000..502a15a --- /dev/null +++ b/Documentation/committer-grant-revocation @@ -0,0 +1,345 @@ +OVS Committer Grant/Revocation Policy +===================================== +An OVS committer is a participant in the project with the ability +to commit code directly to the master repository. Commit access +grants a broad ability to affect the progress of the project as +presented by its most important artifact, the code and related +resources that produce working binaries of Open vSwitch. As such +it represents a significant level of trust in an individual's +commitment to working with other committers and the community at +large for the benefit of the project. It can not be granted +lightly and, in the worst case, must be revocable if the trust +placed in an individual was inappropriate. + +This document suggests guidelines for granting and revoking commit +access. It is intended provide a framework for evaluation of such +decisions without specifying deterministic rules that wouldn't be +sensitive to the nuance of specific situations. In the end the +decision to grant or revoke committer privileges is a judgment call +made by the existing set of committers. + + +Granting Commit Access +---------------------- +Granting commit access should be considered when a candidate has +demonstrated the following in their interaction with the project: + +- Contribution of significant new features through the patch +submission process where: +- Submissions are free of obvious critical defects +- Submissions do not typically require many iterations of +improvement to be accepted +- Consistent participation in code review of other's patches, +including existing committers, with comments consistent with the +overall project standards +- Assistance to those in the community who are less knowledgeable +through active participation in project forums such as the +ovs-discuss mailing list. +- Plans for sustained contribution to the project compatible with +the project's direction as viewed by current committers. +- Commitment to meet the expectations described in the +"Expectations of Developer's with Open vSwitch Access" + +The process to grant commit access to a candidate is simple: + +- An existing committer nominates the candidate by sending an +emailing to all existing committers with information +substantiating the contributions of the candidate in the areas +described above. +- All existing committers discuss the pros and cons of granting +commit access to the candidate in the email thread. +- When the discussion has converged or a reasonable time has +elapsed without discussion developing (e.g a few business days) +the nominator calls for a final decision on the candidate with a +followup email to the thread. +- Each committer may vote yes, no, or to abstain by replying to the +email thread. A failure to reply is an implicit abstention. +- After votes from all existing committers have been collected or a +reasonable time has elapsed for them to be provided (e.g. a +couple of business days) the votes are evaluated. To be granted +commit access the candidate must receive yes votes from a +majority of the existing committers and zero no votes. Since a +no vote is effectively a veto of the candidate it should be +accompanied by a reason for the vote. +- The nominator summarizes the result of the vote in an email to +the all existing committers. +- If the vote to grant commit access passed, the candidate is +contacted with an invitation to become a committer to the project +which asks them to agree to the committer expectations +documented on the project web site. +- If the candidate agrees access is granted by setting up commit +access to the repos on github. + + +Revoking Commit Access +---------------------- +There are two situations in which commit access might be revoked. + +The straightforward situation is a committer who is no longer +active in the project and has no plans to become active in the near +future. The process in this case is: + +- Any time after a committer has been inactive for more than 6 +months any other committer to the project may identify that +committer as a candidate for revocation of commit access due to +inactivity. +- The plans of the candidate for revocation should be consulted in +a private email to the candidate. +- If the candidate for removal states plans to continue +participating no action is taken and this process terminates. +- If the candidate replies they no longer require commit +access then commit access is removed and a notification is +sent to the candidate and all existing committers. +- If the candidate can not be reached within 1 week of the first +attempting to contact this process continues. +- A message proposing removal of commit access is sent to the +candidate and all other committers. +- If the candidate for removal states plans to continue +participating no action is taken. +- If the candidate replies they no longer require commit +access then their access is removed. +- If the candidate can not be reached within 2 months of the +second attempting to contact them, access is removed. +- In any case, where access is removed, this fact is published +through an email to all existing committers (including the +candidate for removal). + +The more difficult situation is a committer who is behaving in a +manner that is viewed as detrimental to the future of the project +by other committers. This is a delicate situation with the +potential for the creation of division within the greater +community and should be handled with care. The process in this +case is: + +- Discuss the behavior of concern with the individual privately and +explain why you believe it is detrimental to the project. Stick +to the facts and keep the email professional. Avoid personal +attacks and the temptation to hypothesize about unknowable +information such as the other's motivations. Make it clear that +you would prefer not to discuss the behavior more widely but will +have to raise it with other contributors if it does not change. +Ideally the behavior is eliminated and no further action is +required. If not, +- Start an email thread with all committers, including the source +of the behavior, describing the behavior and the reason it is +detrimental to the project. The message should have the same +tone as the private discussion and should generally repeat the +same points covered in that discussion. The person whose +behavior is being questioned should not be surprised by anything +presented in this discussion. Ideally the wider discussion +provides more perspective to all participants and the issue is +resolved. If not, +- Start an email thread with all committers except the source of +the detrimental behavior requesting a vote on revocation of +commit rights. Cite the discussion among all committers and +describe all the reasons why it was not resolved satisfactorily. +This email should be careful written with the knowledge that the +reasoning it contains may be published to the larger community +to justify the decision. +- Each committer may vote yes, no, or to abstain by replying to the +email thread. A failure to reply is an implicit abstention. +- After all votes have been collected or a reasonable time has +elapsed for them to be provided (e.g. a couple of business days) +the votes are evaluated. For the request to revoke commit access +for the candidate to pass it must receive yes votes from two +thirds of the existing committers. +- anyone that votes no must provide their reasoning, and +- if the proposal passes then counter-arguments for the reasoning in +no votes should also be documented along with the initial reasons +the revocation was proposed. Ideally there should be no new +counter-arguments supplied in a no vote all concerns should +have surfaced in the discussion before the vote. +- The original person to propose revocation summarizes the result +of the vote in an email to all existing committers excepting the +candidate for removal. +- If the vote to revoke commit access passes access is removed and +the candidate for revocation is informed of that fact and the +reasons for it as documented in the email requesting the +revocation vote. +- Ideally the revoked committer peacefully leaves the community +and no further action is required. However, there is a +distinct possibility that he/she will try to generate support +for his/her point of view within the larger community. In +this case the reasoning for removing commit access as +described in the request for a vote will be published to the +community. + + +Changing the Policy +------------------- +The process for changing the policy is: + +- Propose the changes to the policy in an email to all current +committers and request discussion. +- After an appropriate period of discussion (a few days) update +the proposal based on feedback if required and resend it to all +current committers with a request for a formal vote. +- After all votes have been collected or a reasonable time has +elapsed for them to be provided (e.g. a couple of business days) +the votes are evaluated. For the request to modify the policy to +pass it must receive yes votes from two thirds of the existing +committers. + + +Template Emails +=============== + +Nomination to Grant Commit Access +--------------------------------- +I would like to nominate for commit access. I believe + has met the conditions for commit access described in the +committer grant policy on the project web site in the following +ways: + + + +Please reply to all in this message thread with your comments and +questions. If that discussion concludes favorably I will request a +formal vote on the nomination in a few days. + + +Vote to Grant Commit Access +--------------------------- +I nominated for commit access on . Having +allowed sufficient time for discussion it's now time to formally +vote on the proposal. + +Please reply to all in this thread with your vote of: YES, NO, or +ABSTAIN. A failure to reply will be counted as an abstention. If +you vote NO, by our policy you must include the reasons for that +vote in your reply. The deadline for votes is . + +If a majority of committers vote YES and there are zero NO votes +commit access will be granted. + +Vote Results for Grant of Commit Access +--------------------------------------- +The voting period for granting to commit access to +initiated at is now closed with the following +results: + +YES: (<% of voters>) +NO: (<% of voters>) +ABSTAIN: (<% of voters>) + +Based on these results commit access granted. + + +Invitation to Accepted Committer +-------------------------------- +Due to your sustained contributions to the Open vSwitch (OVS) +project we would like to provide you with commit access to the +project repository. Developers with commit access must agree to +fulfill specific responsibilities described on the web site at: + +/development/committer-responsibilities + +Please let us know if you would like to accept commit access and if +so that you agree to fulfill these responsibilities. Once we +receive your response we'll set up access. We're looking forward +continuing to work together to advance the Open vSwitch project. + + +Proposal to Remove Commit Access for Inactivity +----------------------------------------------- +Committer has been inactive for . I have +attempted to privately contacted and could not +be reached. + +Based on this I would like to formally propose removal of commit +access. If a response to this message documenting the reasons to +retain commit access is not received by access will be +removed. + + +Notification of Commit Removal for Inactivity +------------------------------------------------ +Committer has been inactive for . +. Commit access has +now been removed. + + +Proposal to Revoke Commit Access for Detrimental Behavior +--------------------------------------------------------- +I regret that I feel compelled to propose revocation of commit +access for . I have privately discussed with +the following reasons I believe actions are detrimental +to the project and we have failed to come to a mutual +understanding: + + + +Please reply to all in this thread with your thoughts on this +proposal. I plan to formally propose a vote on the proposal on or +after . + +It is important to get all discussion points both for and against +the proposal on the table during the discussion period prior to the +vote. Please make it a high priority to respond to this proposal +with your thoughts. + + +Vote to Revoke Commit Access +---------------------------- +I nominated for revocation of commit access on . +Having allowed sufficient time for discussion it's now time to +formally vote on the proposal. + +Please reply to all in this thread with your vote of: YES, NO, or +ABSTAIN. A failure to reply will be counted as an abstention. If +you vote NO, by our policy you must include the reasons for that +vote in your reply. The deadline for votes is . + +If 2/3rds of committers vote YES commit access will be revoked. + +The following reasons for revocation have been given in the +original proposal or during discussion: + + + +The following reasons for retaining access were discussed: + + + +The counter-argument for each reason for retaining access is: + + + + +Vote Results for Revocation of Commit Access +-------------------------------------------- +The voting period for revoking the commit access of +initiated at is now closed with the following +results: + +YES: (<% of voters>) +NO: (<% of voters>) +ABSTAIN: (<% of voters>) + +Based on these results commit access revoked. The +following reasons for retaining commit access were proposed in NO +votes: + + + +The counter-arguments for each of these reasons are: + + + + +Notification of Commit Revocation for Detrimental Behavior +---------------------------------------------------------- +After private discussion with you and careful consideration of the +situation the other committers to the Open vSwitch (OVS) project +have concluded that it is in the best interest of the project that +your commit access to the project repositories be revoked and this +has now occurred. + +The reasons for this decision are: + + + +While your goals and those of the project no longer appear to be +aligned we greatly appreciate all the work you have done for the +project and wish you continued success in your future work diff --git a/Documentation/committer-responsibilities b/Documentation/committer-responsibilities new file mode 100644 index 0000000..7e143f6 --- /dev/null +++ b/Documentation/committer-responsibilities @@ -0,0 +1,76 @@ +Expectations for Developers with Open vSwitch Repo Access +========================================================= + +Prerequisites +------------- + +Be familiar with CodingStyle and CONTRIBUTING. + +Review +------ + +Code (yours or others') must be reviewed publicly (by you or others) +before you push it to the repository. With one exception (see below), +every change needs at least one review. + +If one or more people know an area of code particularly well, code +that affects that area should ordinarily get a review from one of +them. + +The riskier, more subtle, or more complicated the change, the more +careful the review required. When a change needs careful review, use +good judgment regarding the quality of reviews. If a change adds 1000 +lines of new code, and a review posted 5 minutes later says just +"Looks good," then this is probably not a quality review. + +(The size of a change is correlated with the amount of care needed in +review, but it is not strictly tied to it. A search and replace +across many files may not need much review, but one-line optimization +changes can have widespread implications.) + +Your own small changes to fix a recently broken build ("make") or +tests ("make check"), that you believe to be visible to a large number +of developers, may be checked in without review. If you are not sure, +ask for review. If you do push a build fix without review, send the +patch to ovs-dev afterward as usual, indicating in the email that you +have already pushed it. + +Regularly review submitted code in areas where you have expertise. +Consider reviewing other code as well. + +Git conventions +--------------- + +Do not push merge commits to the Git repository without prior +discussion on ovs-dev. + +If you apply a change (yours or another's) then it is your +responsibility to handle any resulting problems, especially broken +builds and other regressions. If it is someone else's change, then +you can ask the original submitter to address it. Regardless, you +need to ensure that the problem is fixed in a timely way. The +definition of "timely" depends on the severity of the problem. + +If a bug is present on master and other branches, fix it on master +first, then backport the fix to other branches. Straightforward +backports do not require additional review (beyond that for the fix on +master). + +Feature development should be done only on master. Occasionally it +makes sense to add a feature to the most recent release branch, before +the first actual release of that branch. These should be handled in +the same way as bug fixes, that is, first implemented on master and +then backported. + +Keep the authorship of a commit clear by maintaining a correct list of +"Signed-off-by:"s. If a confusing situation comes up, as it +occasionally does, bring it up on the mailing list. If you explain +the use of Signed-off-by: to a new developer, explain not just how but +why, since the intended meaning of Signed-off-by: is more important +than the syntax. As part of your explanation, quote or provide a URL +to the Developer's Certificate of Origin in CONTRIBUTING. + +Use Reported-by: and Tested-by: tags in commit messages to indicate +the source of a bug report. + +Keep the AUTHORS file up to date.