Looks good to me. Though I'm somewhat absent in the code base these days, I'll volunteer for the nebulous areas of: "filesystem integration" and performance
-Todd On Thu, Sep 20, 2012 at 1:39 PM, Stack <st...@duboce.net> wrote: > Here is the paragraph I will add to the community chapter of our book > on what I think we worked out by way of policy over the course of this > discussion. > > In the below, I dropped the term 'lieutenant' and instead use 'owner'. > Owner is from Todds' recounting of how google does it above. Owner, > unlike lieutenant, undoes any implication of hierarchy. > > > PATCH +1'ing POLICY[1] > > The below policy is something we put in place 09/2012. It is a > suggested policy rather than a hard requirement. We want to try it > first to see if it works before we cast it in stone. > > HBase is made of components[2]. Components have one or more > owners[3]. See the 'Description' field on [1] for who the current > owners are by component. > > Patches that fit within the scope of a single HBase component require, > at least, a +1 by one of the component's owners before commit. If > owners are absent -- busy or otherwise -- two +1s by non-owners will > suffice. > > Patches that span components need at least two +1s before they can be > committed, preferably +1s by owners of components touched by the > x-component patch (TODO: This needs tightening up but I think fine for > first pass). > > Any -1 on a patch by anyone vetos a patch; it cannot be committed > until the justification for the -1 is addressed. > > > 1. http://search-hadoop.com/m/jtoYcKNU7l1 and > 2. > https://issues.apache.org/jira/plugins/servlet/project-config/HBASE/components. > 3. Link to Component Owners section (follows) > > > COMPONENT OWNERS > > Component owners are listed in the description field on this page [1]. > They are listed in the description field rather than in the 'Component > Lead' field because the latter only allows us list one individual > whereas components are encouraged to have multiple owners. > > Owners are volunteers who are (usually, but not necessarily) expert in > their component domain and may have an agenda on how they think their > HBase component should evolve. > > Duties: > > + Owners will try and review patches that land within their component's scope. > + If applicable, if an owner has an agenda, they will publish their > goals or the design toward which they are driving their component > > If you would like to be volunteer as a component owner, just write the > dev list and we'll sign you up. Owners do not need to be committers. > > > Let me know if you'd add or edit above. Otherwise I'll add it to the > refguide in next day or so. > > St.Ack > P.S. I will edit the current list of components and add in those who > have volunteered so far on this thread. Thanks. -- Todd Lipcon Software Engineer, Cloudera
