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. > > 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 -- 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, >> 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. >>
