accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Havanki (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1834) ReviewBoard guidelines
Date Tue, 04 Mar 2014 15:47:23 GMT


Bill Havanki commented on ACCUMULO-1834:

In light of the bylaw effort, here is some information to help us decide on RB's role. This
information is current as of this writing, but the bylaws have not yet been approved.

Code changes will be approved by lazy approval, meaning automatically after one day except
if there is a veto. In case of a veto, consensus approval is required (+3 binding votes, no

There is no requirement for RtC. No specifics on RtC vs. CtR are in the bylaws, but decisions
on that are deferred to a separate document.

So, I see two roles for RB:

1. As a way to provide an optional review before committing, as Christopher suggests. This
would not absolutely require any ship-its because we start with lazy approval.
2. As a way to provide a review for consensus approval after a code change veto. As Christopher
points out, we may need to post a "\[VOTE]" to dev.

A contributor could use other means for the above, like pointing to patches posted to Jira,
but RB is there and may be convenient.

> ReviewBoard guidelines
> ----------------------
>                 Key: ACCUMULO-1834
>                 URL:
>             Project: Accumulo
>          Issue Type: Task
>          Components: docs
>            Reporter: Josh Elser
>              Labels: Documentation
> We currently don't have any guidelines on how we should be using reviewboard.
> For example -- How many "ship it"'s are needed to merit consensus? How do we make sure
that reviews get applied after consensus is reached?
> Figure out what to do and then write it down.

This message was sent by Atlassian JIRA

View raw message