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

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
>

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

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.

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

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

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

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

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.

CTR communities deal with this all the time. In a CTR community,
people who make changes are prepared to unmake, remake, or otherwise
adjust changes as needed to achieve consensus. RTC communities do it
the other way around. For the sake of collective sanity, I'd encourage
this group to clarify that it is one or the other, and not try to
achieve too much of a hybrid.
>
>> 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.
>>>

On Wed, Oct 31, 2012 at 1:49 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
> 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.
>
> CTR communities deal with this all the time. In a CTR community,
> people who make changes are prepared to unmake, remake, or otherwise
> adjust changes as needed to achieve consensus. RTC communities do it
> the other way around. For the sake of collective sanity, I'd encourage
> this group to clarify that it is one or the other, and not try to
> achieve too much of a hybrid.

Good point.  We are currently a CTR community.  I am not advocating
for changing that in any way.  I just wanted to point out that review
board is a great tool to use on a voluntary basis.

Since we have chosen CTR, we should just go with it.  Review the
commits and changes them as needed as consensus develops.   No need to
spend too much time worrying about whether or not a commit should have
been made.  I agree with you point about a hybrid, it does seem like
it could get really confusing.

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

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.

I think we decided in the beginning to operate under the following policy.

http://accumulo.apache.org/governance/lazyConsensus.html

Below is excerpt from this document.

    Sometimes a member of the community will believe a specific action is the
    correct one for the community but are not sure enough to proceed
with the work
    under the lazy consensus model. In these circumstances they can state Lazy
    Consensus is in operation.

    What this means is that they make a proposal and state that they will start
    implementing it in 72 hours unless someone objects. 72 hours is
chosen because
    it accounts for different timezones and non-apache commitments.

>
> Thanks,
>
> Drew