accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <>
Subject Re: Q: re Accumulo Commit Policy? (was Re: Setting charset in getBytes())
Date Wed, 31 Oct 2012 17:01:19 GMT
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
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

> On Wed, Oct 31, 2012 at 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 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,
> was created to do
> just that.
> >> Drew said:
> >> 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.
> In normal situations (i.e., in the past) I recall waiting for a
> consensus to develop.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message