Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> HEP proposal


Thanks for a really good proposal.
Some questions / comments:

On voting
1. Which voting rule?
I think you mean the MajorityApproval as it does not have veto rule.
So may be it's just clarifying the reference.

2. Who can vote?
Usually PMCs have Binding Votes.
Would be good to have a sentence clarifying this.

3. How long does the vote go?
Usual 3 days may not be enough. One week is reasonable?

4. Discussion on public lists.
A HEP can evolve from a jira, then it should be counted as a public
discussion. I think it makes sense even to continue the discussion
there if so. I propose to add the following:
========================================idea is HEP-able by sending mail to the general, or the project-specific lists
+ (including Jiras)
if the scope of the idea is limited to the project.
5. How the set of editors is selected?
    "The editors are apointed and removed by the PMC informally, similar to
    how the Apache Board appoints shepherds to projects."
This needs a reference. How does Apache Board appoints shepherds?

6. The level of design details.
I think HEP should have a pretty detailed design. When people vote they
will want to be sure the design can lead to a reasonable implementation.
Should we say "implementation-ready design", rather than
"A high-level explanation of the design."
Or just
"A _detailed_ explanation of the design."

7. Typos:
successuflly, apointed, intial


On 7/12/2010 12:39 PM, Eli Collins wrote:
> A while back we started discussing on list (http://bit.ly/aFj9Ya) and
> at the contributors meeting (http://bit.ly/aj4Y7I) a more coordinated
> way to describe, socialize and shepherd enhancements to Hadoop.
> Thanks for all the feedback.  Most of it was encouraging so I wrote up
> a draft proposal with specifics to discuss here.  After incorporating
> feedback I'll send out another revision for vote.
> Thanks,
> Eli
> HEP: 1
> Title: HEP Purpose and Guidelines
> Author: Eli Collins
> Status: Draft
> What is a HEP?
> =============>
> HEP stands for Hadoop Enhancement Proposal, and is based on Python's
> PEP (Python Enhancement Proposal) [1].  A HEP is a document that
> describes a new feature, it's rationale, and issues the feature needs
> to address in order to be successuflly incorporated.
> The intent is for HEPs to be the primary mechanism for proposing
> significant new features to core Hadoop (common, HDFS and MapReduce),
> incorporating community feedback, and recording the proposal.  Going
> through the HEP process should improve the chances that a proposal is
> successful.
> While HEPs do not need to come with code, they are a mechanism to
> propose features to the community, with the intent of contributing the
> feature, rather than request the community implement a feature.
> HEPs must be consistent with Apache bylaws [2], for example, the HEP
> workflow takes place on the public Apache Hadoop lists.
> When is a HEP Required?
> ======================>
> HEPs should not impede casual contribution to Hadoop.  Small
> improvements and bugs do not require HEPs.  Not all features need
> HEPs.  While the decision is subjective, here are some guidelines to
> indicate a HEP should be considered:
> - The feature impacts backwards compatibility (eg modifies released
> public APIs in an incompatible way).
> - The feature requires that an existing component be substantially
> re-designed (eg NameNode modified to use Bookkeeper).
> - The implementation impact multiple parts of the system (eg symbolic
> links versus adding a pluggable component like a codec).
> - The feature impacts the entire development community (eg converts
> the build system to use maven).
> HEP Workflow
> ===========>
> The author of a HEP should first try to determine if their idea is
> HEP-able by sending mail to the general, or the project-specific lists