You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hama.apache.org by "Edward J. Yoon" <ed...@apache.org> on 2013/03/15 05:08:10 UTC
[DISCUSS] Community Policies to prevent conflicts
Hey all,
We are seeing some conflicts between committers (especially me and
Thomas?) and a growing number of somewhat arrogant, self-centred
actions. However, I believe that all began with misunderstandings,
misreadings, and insufficient discussions, (we didn't mean it). Let's
don't argue anymore since everyone has different sides.
Here's my suggestions:
1. The RoadMap should be discussed on dev@ and all decisions should be
described on Wiki[1].
2. Observance of HowToCommit[2] is required of every committers.
We might want to edit some plans/policies of RoadMap and HowToCommit.
Please feel free to edit them.
And, 3. Discussion in very polite terms.
My only worry is whether we can be able to follow HowToCommit process
everytime. As you know we're only have 3 active committers (= PMCs).
Any other ideas?
1. http://wiki.apache.org/hama/RoadMap
2. http://wiki.apache.org/hama/HowToCommit
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [DISCUSS] Community Policies to prevent conflicts
Posted by "Edward J. Yoon" <ed...@apache.org>.
If there's no more opinions/objections/suggestions, let's follow the
policies. I've updated Guide for Hama Committers[1] page.
>> - Voting for an appropriate time window that a committer can assume silence
>> as a +1 on his patch.
Should we vote for this?
1. http://wiki.apache.org/hama/HowToCommit
On Tue, Mar 19, 2013 at 11:27 AM, Edward J. Yoon <ed...@apache.org> wrote:
>>> - Voting for an appropriate time window that a committer can assume silence
>>> as a +1 on his patch.
>
> If it's a trivial issue and every unit tests can be passed, I think we
> don't need to wait until reviewed.
>
> And, we should not change the unit test logic to avoid build failure.
> I think it is one of the causes of creating additional bugs.
>
> On Sun, Mar 17, 2013 at 3:46 PM, Tommaso Teofili
> <to...@gmail.com> wrote:
>> I generally agree with Ed's proposal.
>>
>>
>> 2013/3/15 Suraj Menon <su...@apache.org>
>>
>>> +1 Thank you for the information Edward and we start afresh. I think things
>>> should be lot simpler within a small team like ours. I am touching on
>>> topics related to code and commit protocol here.
>>>
>>> We are trying to get a resolution on three points and the voting could be
>>> done in appropriate channel. Let me know if this is the correct place to do
>>> the votings.
>>> - Voting for/against "Review then commit" policy
>>>
>>
>> sure, we can vote for that (I think a reasonable compromise could be what
>> Doug Cutting comments here
>> https://issues.apache.org/jira/browse/HADOOP-8248?focusedCommentId=13247658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13247658)
>> however we can probably create a [DISCUSS] thread before and
>> eventually
>> vote afterwards so that we can collect different opinions before voting.
>>
>>
>>> - Voting for an appropriate time window that a committer can assume silence
>>> as a +1 on his patch.
>>>
>>
>> I think this is part of the above commit policy so I wouldn't say this is
>> needed.
>>
>>
>>> - Voting for whether a commit should reflect documentation on Wiki.
>>>
>>
>> Do you mean asking for documentation for some specific issues?
>> We can probably discuss also that in a separate thread.
>>
>> Tommaso
>>
>>
>>
>>>
>>> Thanks,
>>> Suraj
>>>
>>> On Fri, Mar 15, 2013 at 12:08 AM, Edward J. Yoon <edwardyoon@apache.org
>>> >wrote:
>>>
>>> > Hey all,
>>> >
>>> > We are seeing some conflicts between committers (especially me and
>>> > Thomas?) and a growing number of somewhat arrogant, self-centred
>>> > actions. However, I believe that all began with misunderstandings,
>>> > misreadings, and insufficient discussions, (we didn't mean it). Let's
>>> > don't argue anymore since everyone has different sides.
>>> >
>>> > Here's my suggestions:
>>> >
>>> > 1. The RoadMap should be discussed on dev@ and all decisions should be
>>> > described on Wiki[1].
>>> > 2. Observance of HowToCommit[2] is required of every committers.
>>> >
>>> > We might want to edit some plans/policies of RoadMap and HowToCommit.
>>> > Please feel free to edit them.
>>> >
>>> > And, 3. Discussion in very polite terms.
>>> >
>>> > My only worry is whether we can be able to follow HowToCommit process
>>> > everytime. As you know we're only have 3 active committers (= PMCs).
>>> >
>>> > Any other ideas?
>>> >
>>> > 1. http://wiki.apache.org/hama/RoadMap
>>> > 2. http://wiki.apache.org/hama/HowToCommit
>>> >
>>> > --
>>> > Best Regards, Edward J. Yoon
>>> > @eddieyoon
>>> >
>>>
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [DISCUSS] Community Policies to prevent conflicts
Posted by "Edward J. Yoon" <ed...@apache.org>.
>> - Voting for an appropriate time window that a committer can assume silence
>> as a +1 on his patch.
If it's a trivial issue and every unit tests can be passed, I think we
don't need to wait until reviewed.
And, we should not change the unit test logic to avoid build failure.
I think it is one of the causes of creating additional bugs.
On Sun, Mar 17, 2013 at 3:46 PM, Tommaso Teofili
<to...@gmail.com> wrote:
> I generally agree with Ed's proposal.
>
>
> 2013/3/15 Suraj Menon <su...@apache.org>
>
>> +1 Thank you for the information Edward and we start afresh. I think things
>> should be lot simpler within a small team like ours. I am touching on
>> topics related to code and commit protocol here.
>>
>> We are trying to get a resolution on three points and the voting could be
>> done in appropriate channel. Let me know if this is the correct place to do
>> the votings.
>> - Voting for/against "Review then commit" policy
>>
>
> sure, we can vote for that (I think a reasonable compromise could be what
> Doug Cutting comments here
> https://issues.apache.org/jira/browse/HADOOP-8248?focusedCommentId=13247658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13247658)
> however we can probably create a [DISCUSS] thread before and
> eventually
> vote afterwards so that we can collect different opinions before voting.
>
>
>> - Voting for an appropriate time window that a committer can assume silence
>> as a +1 on his patch.
>>
>
> I think this is part of the above commit policy so I wouldn't say this is
> needed.
>
>
>> - Voting for whether a commit should reflect documentation on Wiki.
>>
>
> Do you mean asking for documentation for some specific issues?
> We can probably discuss also that in a separate thread.
>
> Tommaso
>
>
>
>>
>> Thanks,
>> Suraj
>>
>> On Fri, Mar 15, 2013 at 12:08 AM, Edward J. Yoon <edwardyoon@apache.org
>> >wrote:
>>
>> > Hey all,
>> >
>> > We are seeing some conflicts between committers (especially me and
>> > Thomas?) and a growing number of somewhat arrogant, self-centred
>> > actions. However, I believe that all began with misunderstandings,
>> > misreadings, and insufficient discussions, (we didn't mean it). Let's
>> > don't argue anymore since everyone has different sides.
>> >
>> > Here's my suggestions:
>> >
>> > 1. The RoadMap should be discussed on dev@ and all decisions should be
>> > described on Wiki[1].
>> > 2. Observance of HowToCommit[2] is required of every committers.
>> >
>> > We might want to edit some plans/policies of RoadMap and HowToCommit.
>> > Please feel free to edit them.
>> >
>> > And, 3. Discussion in very polite terms.
>> >
>> > My only worry is whether we can be able to follow HowToCommit process
>> > everytime. As you know we're only have 3 active committers (= PMCs).
>> >
>> > Any other ideas?
>> >
>> > 1. http://wiki.apache.org/hama/RoadMap
>> > 2. http://wiki.apache.org/hama/HowToCommit
>> >
>> > --
>> > Best Regards, Edward J. Yoon
>> > @eddieyoon
>> >
>>
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [DISCUSS] Community Policies to prevent conflicts
Posted by Tommaso Teofili <to...@gmail.com>.
I generally agree with Ed's proposal.
2013/3/15 Suraj Menon <su...@apache.org>
> +1 Thank you for the information Edward and we start afresh. I think things
> should be lot simpler within a small team like ours. I am touching on
> topics related to code and commit protocol here.
>
> We are trying to get a resolution on three points and the voting could be
> done in appropriate channel. Let me know if this is the correct place to do
> the votings.
> - Voting for/against "Review then commit" policy
>
sure, we can vote for that (I think a reasonable compromise could be what
Doug Cutting comments here
https://issues.apache.org/jira/browse/HADOOP-8248?focusedCommentId=13247658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13247658)
however we can probably create a [DISCUSS] thread before and
eventually
vote afterwards so that we can collect different opinions before voting.
> - Voting for an appropriate time window that a committer can assume silence
> as a +1 on his patch.
>
I think this is part of the above commit policy so I wouldn't say this is
needed.
> - Voting for whether a commit should reflect documentation on Wiki.
>
Do you mean asking for documentation for some specific issues?
We can probably discuss also that in a separate thread.
Tommaso
>
> Thanks,
> Suraj
>
> On Fri, Mar 15, 2013 at 12:08 AM, Edward J. Yoon <edwardyoon@apache.org
> >wrote:
>
> > Hey all,
> >
> > We are seeing some conflicts between committers (especially me and
> > Thomas?) and a growing number of somewhat arrogant, self-centred
> > actions. However, I believe that all began with misunderstandings,
> > misreadings, and insufficient discussions, (we didn't mean it). Let's
> > don't argue anymore since everyone has different sides.
> >
> > Here's my suggestions:
> >
> > 1. The RoadMap should be discussed on dev@ and all decisions should be
> > described on Wiki[1].
> > 2. Observance of HowToCommit[2] is required of every committers.
> >
> > We might want to edit some plans/policies of RoadMap and HowToCommit.
> > Please feel free to edit them.
> >
> > And, 3. Discussion in very polite terms.
> >
> > My only worry is whether we can be able to follow HowToCommit process
> > everytime. As you know we're only have 3 active committers (= PMCs).
> >
> > Any other ideas?
> >
> > 1. http://wiki.apache.org/hama/RoadMap
> > 2. http://wiki.apache.org/hama/HowToCommit
> >
> > --
> > Best Regards, Edward J. Yoon
> > @eddieyoon
> >
>
Re: [DISCUSS] Community Policies to prevent conflicts
Posted by "Edward J. Yoon" <ed...@apache.org>.
I'd recommend creating different thread for each item.
On Sat, Mar 16, 2013 at 2:49 AM, Edward J. Yoon <ed...@apache.org> wrote:
> +1
>
> On Sat, Mar 16, 2013 at 12:49 AM, Suraj Menon <su...@apache.org> wrote:
>> +1 Thank you for the information Edward and we start afresh. I think things
>> should be lot simpler within a small team like ours. I am touching on
>> topics related to code and commit protocol here.
>>
>> We are trying to get a resolution on three points and the voting could be
>> done in appropriate channel. Let me know if this is the correct place to do
>> the votings.
>> - Voting for/against "Review then commit" policy
>> - Voting for an appropriate time window that a committer can assume silence
>> as a +1 on his patch.
>> - Voting for whether a commit should reflect documentation on Wiki.
>>
>> Thanks,
>> Suraj
>>
>> On Fri, Mar 15, 2013 at 12:08 AM, Edward J. Yoon <ed...@apache.org>wrote:
>>
>>> Hey all,
>>>
>>> We are seeing some conflicts between committers (especially me and
>>> Thomas?) and a growing number of somewhat arrogant, self-centred
>>> actions. However, I believe that all began with misunderstandings,
>>> misreadings, and insufficient discussions, (we didn't mean it). Let's
>>> don't argue anymore since everyone has different sides.
>>>
>>> Here's my suggestions:
>>>
>>> 1. The RoadMap should be discussed on dev@ and all decisions should be
>>> described on Wiki[1].
>>> 2. Observance of HowToCommit[2] is required of every committers.
>>>
>>> We might want to edit some plans/policies of RoadMap and HowToCommit.
>>> Please feel free to edit them.
>>>
>>> And, 3. Discussion in very polite terms.
>>>
>>> My only worry is whether we can be able to follow HowToCommit process
>>> everytime. As you know we're only have 3 active committers (= PMCs).
>>>
>>> Any other ideas?
>>>
>>> 1. http://wiki.apache.org/hama/RoadMap
>>> 2. http://wiki.apache.org/hama/HowToCommit
>>>
>>> --
>>> Best Regards, Edward J. Yoon
>>> @eddieyoon
>>>
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [DISCUSS] Community Policies to prevent conflicts
Posted by "Edward J. Yoon" <ed...@apache.org>.
+1
On Sat, Mar 16, 2013 at 12:49 AM, Suraj Menon <su...@apache.org> wrote:
> +1 Thank you for the information Edward and we start afresh. I think things
> should be lot simpler within a small team like ours. I am touching on
> topics related to code and commit protocol here.
>
> We are trying to get a resolution on three points and the voting could be
> done in appropriate channel. Let me know if this is the correct place to do
> the votings.
> - Voting for/against "Review then commit" policy
> - Voting for an appropriate time window that a committer can assume silence
> as a +1 on his patch.
> - Voting for whether a commit should reflect documentation on Wiki.
>
> Thanks,
> Suraj
>
> On Fri, Mar 15, 2013 at 12:08 AM, Edward J. Yoon <ed...@apache.org>wrote:
>
>> Hey all,
>>
>> We are seeing some conflicts between committers (especially me and
>> Thomas?) and a growing number of somewhat arrogant, self-centred
>> actions. However, I believe that all began with misunderstandings,
>> misreadings, and insufficient discussions, (we didn't mean it). Let's
>> don't argue anymore since everyone has different sides.
>>
>> Here's my suggestions:
>>
>> 1. The RoadMap should be discussed on dev@ and all decisions should be
>> described on Wiki[1].
>> 2. Observance of HowToCommit[2] is required of every committers.
>>
>> We might want to edit some plans/policies of RoadMap and HowToCommit.
>> Please feel free to edit them.
>>
>> And, 3. Discussion in very polite terms.
>>
>> My only worry is whether we can be able to follow HowToCommit process
>> everytime. As you know we're only have 3 active committers (= PMCs).
>>
>> Any other ideas?
>>
>> 1. http://wiki.apache.org/hama/RoadMap
>> 2. http://wiki.apache.org/hama/HowToCommit
>>
>> --
>> Best Regards, Edward J. Yoon
>> @eddieyoon
>>
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [DISCUSS] Community Policies to prevent conflicts
Posted by Suraj Menon <su...@apache.org>.
+1 Thank you for the information Edward and we start afresh. I think things
should be lot simpler within a small team like ours. I am touching on
topics related to code and commit protocol here.
We are trying to get a resolution on three points and the voting could be
done in appropriate channel. Let me know if this is the correct place to do
the votings.
- Voting for/against "Review then commit" policy
- Voting for an appropriate time window that a committer can assume silence
as a +1 on his patch.
- Voting for whether a commit should reflect documentation on Wiki.
Thanks,
Suraj
On Fri, Mar 15, 2013 at 12:08 AM, Edward J. Yoon <ed...@apache.org>wrote:
> Hey all,
>
> We are seeing some conflicts between committers (especially me and
> Thomas?) and a growing number of somewhat arrogant, self-centred
> actions. However, I believe that all began with misunderstandings,
> misreadings, and insufficient discussions, (we didn't mean it). Let's
> don't argue anymore since everyone has different sides.
>
> Here's my suggestions:
>
> 1. The RoadMap should be discussed on dev@ and all decisions should be
> described on Wiki[1].
> 2. Observance of HowToCommit[2] is required of every committers.
>
> We might want to edit some plans/policies of RoadMap and HowToCommit.
> Please feel free to edit them.
>
> And, 3. Discussion in very polite terms.
>
> My only worry is whether we can be able to follow HowToCommit process
> everytime. As you know we're only have 3 active committers (= PMCs).
>
> Any other ideas?
>
> 1. http://wiki.apache.org/hama/RoadMap
> 2. http://wiki.apache.org/hama/HowToCommit
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
>