I'm not sure I like part of your wording, Adam, but I agree with what you and
Drew are saying.
For example, I could be very convinced that my implementation is correct and
should be included; however,
everyone else on the team could disagree and I would be overruled. I like Drew's
original wording of "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".
Including the 'active debates'
clause is very important.
I'd like to see the policy/recommendation phrased in such a way that
discourages the likelihood of someone
having to revert someone else's code because a consensus wasn't first achieved
on a hot topic.
On 10/31/12 12:18 PM, Adam Fuchs 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 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
