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 Plain View
Accumulo >> mail # dev >> Re: Q: re Accumulo Commit Policy? (was Re: Setting charset in getBytes())


+
Adam Fuchs 2012-10-31, 16:18
Copy link to this message
-
Re: Q: re Accumulo Commit Policy? (was Re: Setting charset in getBytes())
I'm not sure I like part of your wording, Adam, but I agree with what you and Drew are saying.

For example, I could be very convinced that my implementation is correct and should be included; however,
everyone else on the team could disagree and I would be overruled. I like Drew's
original wording of "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". Including the 'active debates'
clause is very important.

I'd like to see the policy/recommendation phrased in such a way that discourages the likelihood of someone
having to revert someone else's code because a consensus wasn't first achieved on a hot topic.

On 10/31/12 12:18 PM, Adam Fuchs wrote:

> I think the core policy should be if you think your change is at all likely
> to be rolled back then don't commit it. This applies to tickets with active
> debates. I also don't think we need to be heavy handed in policy -- shame
> of roll back is enough motivation and the cost isn't that high. This also
> gives a good base for deciding when to branch.
>
> Adam
>
>
> 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.
>>
>> Thanks,
>>
>> Drew
>>
+
David Medinets 2012-10-31, 16:44
+
John Vines 2012-10-31, 17:01
+
Keith Turner 2012-10-31, 17:38
+
Adam Fuchs 2012-10-31, 17:48
+
John Vines 2012-10-31, 17:49
+
Benson Margulies 2012-10-31, 17:49
+
Keith Turner 2012-10-31, 18:17
+
Keith Turner 2012-10-31, 17:03
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