hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "eric baldeschwieler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8248) Clarify bylaws about review-then-commit policy
Date Thu, 26 Apr 2012 00:15:17 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262269#comment-13262269

eric baldeschwieler commented on HADOOP-8248:

IMO the HEP (Hadoop Enhancement Process) discussion we had a while back was focused on a set
of core principles I'd like us to consider again.  Simple fixes and enhancements are easy,
but for a major platform like Hadoop, I think we should have a community process to make sure
that big changes are good changes.  Before a big change goes into Hadoop, we want to know
that it is complete, meaning:

- There is an understanding of the use cases / needs the change is addressing
- There is agreement that the change makes hadoop better
- The work is done: Full design / Real Tests & executed test plan / Docs
- It meets our API compatibility goals

For big changes I'd like to see us focus on defining a process that makes sure the above points
are discussed and everyone agrees that the work is complete. I feel like the bylaw changes
discussed here are focused on procedure.

A HELP proposal (Hadoop Enhancement Lightweight Process):  ;-)

- When a proposal seems complex, folks can request that a HELP is filed...
- A doc is created in the subversion tree .../HELP/<JIRA-ID> of a companion JIRA
  (often the preexisting JIRA the issue was raised on)
- Development can take place on a branch, via patches, whatever, but it is not committed until...
  - The HELP document is complete (there will be a HELP template with appropriate questions)
    - The help document outlines:
      - the need for the change
      - the use cases
      - An external spec of the change (EG man page / java doc)
      - An examination of API/compatibility issues
  - a vote on common-dev occurs blessing the HELP DOC
  - .../HELP/<JIRA-ID>.designdoc & .../HELP/<JIRA-ID>.testplan are complete
  - a vote on common-dev blesses the code, the design doc, the test plan, that the work is
- Beyond the votes on general to guarantee wide acceptance of the change all work can happen
on the JIRA

What do people think? 
> Clarify bylaws about review-then-commit policy
> ----------------------------------------------
>                 Key: HADOOP-8248
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8248
>             Project: Hadoop Common
>          Issue Type: Task
>            Reporter: Todd Lipcon
>         Attachments: c8248_20120409.patch, proposed-bylaw-change.txt
> As discussed on the mailing list (thread "Requirements for patch review" 4/4/2012) we
should clarify the bylaws with respect to the review-then-commit policy. This JIRA is to agree
on the proposed change.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message