+1 See reviews.apache.org.
Cheers, Adam 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 > 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. > >> >
