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 also gives a good base for deciding when to branch.
Adam On Wed, Oct 31, 2012 at 12:09 PM, Drew Farris <[email protected]> wrote: > Related to the discussion of the getBytes() issue, I had a question about > commit policy in the Accumulo project. > > Has there been any discussion regarding commit policy in general in the > Accumulo project? Are there certain times where committing an approach when > it is under discussion is acceptable (e.g; on non-releases branches) and > other cases (e.g close to code freezes) where it is not? > > In other Apache projects I've worked on, when there is active discussion of > a change or feature on the list, the developers would refrain from > committing said change until consensus was reached.In order to exchange and > review proposed changes, patches would be attached to the JIRA issue as > patches generated with svn diff / git diff, so that those participating in > the discussion could review. In cases where proposed changes could not > effectively be communicated via patches, branches would be created, but > these were typically rare. > > 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. > > Thanks, > > Drew >
