Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Re: Q: re Accumulo Commit Policy? (was Re: Setting charset in getBytes())


Copy link to this message
-
Re: Q: re Accumulo Commit Policy? (was Re: Setting charset in getBytes())
On Wed, Oct 31, 2012 at 12:09 PM, Drew Farris <[EMAIL PROTECTED]> 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.

http://accumulo.apache.org/governance/lazyConsensus.html

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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB