patch up on https://issues.apache.org/jira/browse/HBASE-20323
On Fri, Mar 30, 2018 at 3:07 PM, Stack <st...@duboce.net> wrote: > Purge. > > My assessment is that the OWNER project failed; valiants signed-up with the > best of intentions but because of tooling, consistency, attrition, unknowns > (pick one), the project faded soon after launch. > > Thanks, > St.Ack > > On Wed, Mar 28, 2018 at 7:42 AM, Sean Busbey <bus...@apache.org> wrote: > >> In late 2012 we tried an experiment where folks volunteered to act as >> stewards of particular functional areas. The basic idea was we'd >> require scrutiny from more folks if we didn't have anyone available >> who had self selected as familiar available at the time of review. >> >> Described like this in the ref guide currently >> >> ---- >> h3. Patch +1 Policy >> >> 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. >> >> Apache HBase is made of components. Components have one or more >> OWNERs. See the 'Description' field on the components JIRA page for >> who the current owners are by component. >> >> Patches that fit within the scope of a single Apache 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 vetoes a patch; it cannot be committed >> until the justification for the -1 is addressed. >> >> h3. Component Owner/Lieutenant >> >> Component owners are listed in the description field on this Apache >> HBase JIRA components page. The owners are listed in the 'Description' >> field rather than in the 'Component Lead' field because the latter >> only allows us list one individual whereas it is encouraged that >> components have multiple owners. >> >> Owners or component lieutenants are volunteers who are (usually, but >> not necessarily) expert in their component domain and may have an >> agenda on how they think their Apache HBase component should evolve. >> >> 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. >> >> ---- >> >> This was still around enough when I joined the project in ~2014 one of >> the things I did was sign up for a few. I would be surprised if anyone >> with < 1 year in the project (a) knows about this approach or (b) what >> areas (as defined by this effort) specifically to reach out to me >> about. I certainly haven't updated the list for which ones I feel most >> comfortable talking about now that I've been here a bit. >> >> Should we drop this effort? Seems counter to several of our community >> trends; it adds one more thing to maintain, discourages sense of >> shared ownership, requires even more reviewer bandwidth that we don't >> have. >> >> Or should we revitalize it? Would provide a better idea of our >> "reviewer coverage" and give easier pointers for e.g. folks looking >> for mentorship on learning about particular parts of our HBase. >>
