-Re: Q: re Accumulo Commit Policy? (was Re: Setting charset in getBytes())
On Wed, Oct 31, 2012 at 1:01 PM, John Vines <[EMAIL PROTECTED]> wrote:
> Not wanting to merge is a terrible reason to commit a patch. A patch file
> would have been more then sufficient until we reached a consensus on
A slight deviation. I have used review board for potentially
disruptive changes. When I used it, I got excellent feedback from the
community that greatly improved my patches. A nice tool to be aware
of if you have a patch that you are uneasy about.
> implementation. The worst case is that the patch had to be merged properly,
> which someone would have had to do. We are a community, and if one person
> does not have the resources to merge a patch due to code changes there are
> plenty of others here who are willing to do it.
> That said, patch files should be the way to go for any sort of contested
> implementation. It gives the community a chance to see that implementation
> firsthand without there being dedication to it. I do not think code should
> ever be committed if there is still reasonable discourse about the
> implementation being had. For the record, I also feel that time shouldn't
> be spent on implementation which is under review, simply because it could
> be a waste of time, with exception for cases where code samples will help
> the discussion.
> On Wed, Oct 31, 2012 at 12:44 PM, David Medinets
> <[EMAIL PROTECTED]>wrote:
>> On Wed, Oct 31, 2012 at 12:18 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:
>> > I think the core policy should be if you think your change is at all
>> > to be rolled back then don't commit it. This applies to tickets with
>> > 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 particular change required a fair bit of analysis (i.e., looking
>> at over a thousand method calls). I could only devote that time due to
>> Hurricane Sandy barreling down on me. If I had held off on my commit
>> and the source code changed, I would have some merging to do. And
>> maybe no time to do that. So my time and analysis would have been
>> wasted. With the commit, the analysis has been made concrete and the
>> community can more forward. In fact,
>> https://issues.apache.org/jira/browse/ACCUMULO-840 was created to do
>> just that.
>> >> Drew said:
>> >> I haven't been closely following how things have worked with Accumulo,
>> >> I did notice that the getBytes() stuff had been checked in. Just
>> >> if this is the norm, or how things should work.
>> In normal situations (i.e., in the past) I recall waiting for a
>> consensus to develop.