-Re: Q: re Accumulo Commit Policy? (was Re: Setting charset in getBytes())
On Wed, Oct 31, 2012 at 1:38 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
> 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
> > 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
> > 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
> > firsthand without there being dedication to it. I do not think code
> > 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.
> > John
> > 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
> >> 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 --
> >> > 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
> >> 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.