Agreed, I would like to see review board used more for any sort of conflicting changes. I completely forgot about it when i wrote up about patches.
John On Wed, Oct 31, 2012 at 1:48 PM, Adam Fuchs <[email protected]> wrote: > +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. > > >> > > >
