accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: Q: re Accumulo Commit Policy? (was Re: Setting charset in getBytes())
Date Wed, 31 Oct 2012 17:03:03 GMT
On Wed, Oct 31, 2012 at 12:09 PM, Drew Farris <> wrote:
> Related to the discussion of the getBytes() issue, I had a question about
> commit policy in the Accumulo project.
> Has there been any discussion regarding commit policy in general in the
> Accumulo project? Are there certain times where committing an approach when
> it is under discussion is acceptable (e.g; on non-releases branches) and
> other cases (e.g close to code freezes) where it is not?
> In other Apache projects I've worked on, when there is active discussion of
> a change or feature on the list, the developers would refrain from
> committing said change until consensus was reached.In order to exchange and
> review proposed changes, patches would be attached to the JIRA issue as
> patches generated with svn diff / git diff, so that those participating in
> the discussion could review. In cases where proposed changes could not
> effectively be communicated via patches, branches would be created, but
> these were typically rare.
> I haven't been closely following how things have worked with Accumulo, but
> I did notice that the getBytes() stuff had been checked in. Just wondering
> if this is the norm, or how things should work.

I think we decided in the beginning to operate under the following policy.

Below is excerpt from this document.

    Sometimes a member of the community will believe a specific action is the
    correct one for the community but are not sure enough to proceed
with the work
    under the lazy consensus model. In these circumstances they can state Lazy
    Consensus is in operation.

    What this means is that they make a proposal and state that they will start
    implementing it in 72 hours unless someone objects. 72 hours is
chosen because
    it accounts for different timezones and non-apache commitments.

> Thanks,
> Drew

View raw message