Pegasus Enhancement Proposal (PEP)

PEP #: 321

Title: OpenPegasus Patch Approval Process

Version: 1.5

Created: 21 March 2008

Authors: Denise Eckstein

Status:  Approved (Steering Committee Ballot 2008-01)

Version History:

Version Date Author Change Description
1.0 21 March 2008 Denise Eckstein Initial Submission
1.1 25 March 2008 Denise Eckstein
  • Added sentence to Abstract clarifying that this process is designed as a transitional step towards moving to a meritocracy.
  • Eliminated the need to create another distribution list.  The existing pegasus-architecture@openpegasus.org distribution list will be used to request review and approval of non-enhancement, uncontroversial patches.
1.2 27 March 2008 Denise Eckstein
  • Added details in FAQ #3 describing how to format the e-mail requesting patch approval.
1.3 29 March 2008 Denise Eckstein
  • Added FAQ #14 defining statute of limitation for vetoes.
1.4 02 April 2008 Denise Eckstein
  • Added FAQs #15 and #16
1.5 09 April 2008 Denise Eckstein
  • Updated Abstract to clarify process goals.
  • Added Process Steps section.
  • Clarified who can issue a veto.
  • Clarified statute of limitation description in FAQ #14.

Approved Ballot Changes

  • Removed "Note:" from Proposed Solution section.
  • Added numbers to headers in Process Steps section.
  • Changed "submitted by" to "committed by" in sentence in Receiving Patch Approval section.

 

Abstract:  This PEP defines a low-cost, fast-cycle  process for approving  non-enhancement, uncontroversial patches.  This process has been specifically designed for a geographically dispersed community.  In addition, it serves as a transitional step towards moving the OpenPegasus Community to a meritocracy modeled after the Apache Software Foundation meritocracy process, How the ASF works.

Definition of the Problem

Today, all patches must be reviewed and approved by the Architecture Team.  This PEP defines a process that allows non-enhancement, uncontroversial patches to be approved outside the Architecture Team meeting.

Proposed Solution

Grant selected individuals, called Patch Approvers, the right to add the APPROVED keyword to bugzillas that meet the following criteria:

Process Steps

This section describes the three key Patch Approval process steps.

1. Requesting Patch Approval

After attaching a proposed patch to the bugzilla, the bugzilla owner may request review and approval of the patch by sending an e-mail to the OpenPegasus Architecture Team distribution list, pegasus-architecture@openpegasus.org.  The subject line of the e-mail should include the prefix "[PATCH APPROVAL REQUEST]".  The body of the e-mail should include a link to the bugzilla.

2. Receiving Patch Approval

If the patch is reviewed and approved by a Patch Approver, the Patch Approver will add the X.X.X_APPROVED keyword to the bugzilla. The Patch Approver will also add a second keyword to identify him or herself as the approver (e.g., PATCH_APPROVER_ABC). Once the APPROVED keyword has been added to the bugzilla, the patch may be committed by the bugzilla owner.

3. Objecting to a Patch Approval Change

Anyone who subscribes to the OpenPegasus Architecture Team distribution list,  pegasus-architecture@openpegasus.org, and has an OpenPegasus Bugzilla account, http://cvs.opengroup.org/bugzilla/, may object to a Patch Approver change by (1) adding the keyword "VETO_OPENED" to the Status Whiteboard field in the bugzilla and (2) adding a comment with an explanation of why the veto is appropriate. A veto without an explanation is void. Once the objection has been addressed, the individual issuing the veto is responsible for replacing the "VETO_OPENED" keyword on the Status Whiteboard with the "VETO_CLOSED" keyword.  The committed change must be reversed if the veto conditions cannot be satisfied within a reasonable amount of time with the equivalent of a "bug fix" commit.  If the patch is reversed, the veto is considered resolved and the "VETO_OPENED" keyword should be replaced with the "VETO_CLOSED" keyword.

Frequently Asked Questions

  1. Do I have to use this new process?
      Absolutely not.  Patches that satisfy the above criteria can still be added to the Architecture Team agenda for approval.  Patches that do not satisfy the above criteria must be approved by the Architecture Team.



  2. What process is used by the Patch Approver to approve patches?
      The Patch Approver will add the X.X.X_APPROVED keyword to the Bugzilla. The Patch Approver will also add a second keyword to identify him or herself as the approver (e.g., PATCH_APPROVER_ABC). Once the APPROVED keyword has been added to the bugzilla, the patch may be submitted by the bugzilla owner.


  3. How can I request that a Patch Approver approve my patch?
      After attaching your proposed patch to the bugzilla, you should send an e-mail to the OpenPegasus Architecture Team distribution list, pegasus-architecture@openpegasus.org, requesting review and approval.  The subject line of the e-mail should include the prefix "[PATCH APPROVAL REQUEST]".  The body of the e-mail should include a link to the bugzilla.



  4. Can a Patch Approver approve his or her own patch?
      Yes, as long the patch meets the above criteria.


  5. Is a Patch Approver required to review and approve patches that meet the criteria?
      No, the ability to approve patches is an earned privilege not a responsibility. The decision on when, and for whom, to exercise this privilege is at the discretion of the individual.


  6. Do patches still need to be attached to the bugzilla?
      Absolutely, all changes to CVS must be documented as an attachment to an APPROVED bugzilla. This part of the process has not changed and applies to all committers including Patch Approvers.


  7. What should I do if I disagree with a Patch Approver approval?
      Anyone who subscribes to the OpenPegasus Architecture Team distribution list,  pegasus-architecture@openpegasus.org, and has an OpenPegasus bugzilla account, http://cvs.opengroup.org/bugzilla/, may object to a Patch Approver change by (1) adding the keyword "VETO_OPENED" to the Status Whiteboard field in the bugzilla and (2) adding a comment with an explanation of why the veto is appropriate. A veto without an explanation is void. Once the objection has been addressed, the individual issuing the veto is responsible for replacing the "VETO_OPENED" keyword on the Status Whiteboard with the "VETO_CLOSED" keyword.  The committed change must be reversed if the veto conditions cannot be satisfied within a reasonable amount of time with the equivalent of a "bug fix" commit.  If the patch is reversed, the veto is considered resolved and the "VETO_OPENED" keyword should be replaced with the "VETO_CLOSED" keyword.

       
  8. What should I do if I agree, in principle, with an approved patch, but it breaks the NB&T for my platform?
      You have a choice. If you’re willing to take ownership for resolving the defect, it is perfectly acceptable to create a new, blocker bugzilla to fix the problem. If you’d like the Patch Approver to take responsibility for resolving the defect, then it’s probably easier to use the veto process.


  9. What should I do if I agree, in principle, with an approved patch but notice that it introduces a non-blocker defect that should be fixed?
      You have a choice. If you’re willing to take ownership for resolving the defect, it is perfectly acceptable to create a new bugzilla to fix the problem. If you’d like the Patch Approver to take responsibility for resolving the defect, then it’s probably easier to use the veto process.


  10. What should I do if a Patch Approver is not addressing my veto?
      This would be considered a misuse of Patch Approval and should be escalated to the OpenPegasus Steering Committee. Patch Approval is a privilege that can be revoked.


  11. What should I do if a Patch Approver frequently approves bad patches?
      This would be considered a misuse of patch approval and should be escalated to the OpenPegasus Steering Committee. Patch Approval is a privilege that can be revoked.


  12. As a Patch Approver, I’ve approved a patch for an engineer and they are unable or unwilling to resolve a veto. What should I do?
      It is the responsibility of the Patch Approver to ensure that the veto conditions are either met or the patch is reversed. Depending on the circumstances, you may want to avoid approving patches for this individual in the future.


  13. As a Patch Approver, what should I do if I feel someone is misusing their veto power?
      Any misuse of veto power, should be escalated to the OpenPegasus Steering Committee. Veto power is a privilege that can be revoked.


  14. Is there a statute of limitations on voicing an veto?
      Yes.  Although we strongly encourage individuals to register a veto as soon as possible, all vetoes on a contribution must be filed and resolved prior to achieving SF (Source Freeze) on the release containing the contribution.

       

  15. As a Patch Approver, what if I can review a portion or aspect of a patch (e.g., performance implications), but, for some reason (e.g., time, expertise, or interest), can't  review the entire patch?
      You should add your comments to the bugzilla without adding the APPROVED keyword.  Comments of this type of very valuable and we encourage all members of the OpenPegasus Community to review and comment on patches in their areas of expertise.

       

  16. One benefit of this process is that Blocker defects can be resolved more quickly.  Does this loosen the requirement to test patches before submitting?
      No. The following text from PEP #002, Pegasus Bug Tracking and Bug Fix Commitment Process is still applicable.

        Regardless of the etiology of any change to any OpenPegasus CVS file, or group of files, the change:

          1)must not break the Pegasus build
          2)must not break the automated Pegasus test cases.
        The OpenPegasus community's expectations with respect to build and test of new and modified code are: 1) the source must build and pass all regression tests on at least one supported platform (developer's choice) and 2) the source additionally should be tested on either Linux or Windows. Changes should not be submitted if they are known to break the build or the automated testing process on ANY platform.


Copyright (c) 2008 Hewlett-Packard Development Company, L.P.; IBM Corp.;
EMC Corporation; Symantec Corporation; The Open Group.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN
ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED
"AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Template last modified: March 26th 2006 by Martin Kirk
Template version: 1.11