You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by Lars Francke <la...@gmail.com> on 2016/04/11 15:38:12 UTC
Reviews & commits (RTC/CTR), contributions, bylaws
Hi,
I've been a long-time contributor to Hive (5 or so years) and have been
voted in as a committer and I'm very grateful for that. I also understand
that my situation is different than most or lots of committers as I'm not
working for one of the big companies (Facebook, Cloudera, Hortonworks etc.)
where you can just ask someone sitting next to you to do a review.
I'd really like to contribute more than I do currently but the process of
getting patches in is painful for me (and other 'outside' contributors) as
it is hard to get reviews & things committed. The nature of most of my
patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
understand that these are not the most interesting patches to review and
are easy to miss. I don't blame anyone for this situation as I totally
understand it and have been on the other side of this for other projects.
Is there anything we can do to make it easier for me and others like me to
contribute here? I absolutely see the value in having "cleaner" code and
when done in small batches it's usually not very disruptive either.
The bylaws currently require a +1 from a committer who has not authored the
patch. Knox for example has a different policy [2] where they distinguish
between major features and minor things which can be committed freely.
Hive could adopt something similar or like a middle ground. These are just
two suggestions:
1) Allow minor changes (up to the committers discretion) without requiring
an extra +1
2) Allow minor changes (up to the committers discretion) with Lazy approval
(i.e. wait 24 hours)
Sorry for the long rant but I'd love some feedback on this and am looking
forward to contributing more in the future.
Cheers,
Lars
[1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
[2] <https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Jörn Franke <jo...@gmail.com>.
Hi Lars,
I think this is a valid concern and your proposal sounds good to me.
Best regards
> On 11 Apr 2016, at 15:38, Lars Francke <la...@gmail.com> wrote:
>
> Hi,
>
> I've been a long-time contributor to Hive (5 or so years) and have been
> voted in as a committer and I'm very grateful for that. I also understand
> that my situation is different than most or lots of committers as I'm not
> working for one of the big companies (Facebook, Cloudera, Hortonworks etc.)
> where you can just ask someone sitting next to you to do a review.
>
> I'd really like to contribute more than I do currently but the process of
> getting patches in is painful for me (and other 'outside' contributors) as
> it is hard to get reviews & things committed. The nature of most of my
> patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
> understand that these are not the most interesting patches to review and
> are easy to miss. I don't blame anyone for this situation as I totally
> understand it and have been on the other side of this for other projects.
>
> Is there anything we can do to make it easier for me and others like me to
> contribute here? I absolutely see the value in having "cleaner" code and
> when done in small batches it's usually not very disruptive either.
>
> The bylaws currently require a +1 from a committer who has not authored the
> patch. Knox for example has a different policy [2] where they distinguish
> between major features and minor things which can be committed freely.
>
> Hive could adopt something similar or like a middle ground. These are just
> two suggestions:
>
> 1) Allow minor changes (up to the committers discretion) without requiring
> an extra +1
> 2) Allow minor changes (up to the committers discretion) with Lazy approval
> (i.e. wait 24 hours)
>
> Sorry for the long rant but I'd love some feedback on this and am looking
> forward to contributing more in the future.
>
> Cheers,
> Lars
>
> [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
> [2] <https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Lars Francke <la...@gmail.com>.
Hi everyone,
could a few more PMC members please head over to the user@ mailing list and
vote?
Thank you!
On Thu, Apr 14, 2016 at 9:14 AM, Lars Francke <la...@gmail.com>
wrote:
> Okay I have started a VOTE thread on the user@ mailing list (as per the
> bylaws). I would appreciate it if you could head over there and vote :)
>
> Thank you!
>
> On Thu, Apr 14, 2016 at 12:41 AM, Lars Francke <la...@gmail.com>
> wrote:
>
>> Thanks for the +1 Alan.
>>
>> I agree that we're leaving potential contributions on the floor. Doing
>> more reviews is definitely a very good step in the right direction. Thank
>> you! I see this Bylaws change as another (small) step in the right
>> direction. I'm sure we can come up with more ideas.
>>
>> I'll start a VOTE thread on the user@ mailing list.
>>
>> On Tue, Apr 12, 2016 at 5:32 PM, Alan Gates <al...@gmail.com> wrote:
>>
>>> I’m +1 on this change of allowing simple cleanup changes without
>>> requiring a full review.
>>>
>>> But jumping to this fix obscures a bigger problem we have as a
>>> community. This fix only works for committers, not for non-committers who
>>> may also contribute such patches. And it doesn’t solve the situation for
>>> non-trivial patches. We’re leaving potential contributions on the floor
>>> and keeping people out of our community. We need to solve this.
>>>
>>> One thing I’ve been doing over the last few months is set up a filter in
>>> JIRA for components that I know well (metastore, acid, etc.) and then put a
>>> recurring task in my task tracker app to review a patch every day.
>>> Realistically I manage 2-3 reviews a week, but that’s 1-2 more than I was
>>> doing before. I encourage my fellow committers to find something that
>>> works for them. We need to improve the health of our community.
>>>
>>> Alan.
>>>
>>> > On Apr 12, 2016, at 07:56, Lars Francke <la...@gmail.com>
>>> wrote:
>>> >
>>> > Thanks Thejas for the suggestion & others for jumping in. That seems
>>> fine
>>> > for me. 2 days also seems good. Holidays are different in almost every
>>> > country so I wouldn't exclude those.
>>> >
>>> > I have followed the procedure used for the last Bylaws change and
>>> created a
>>> > new Wiki page here: <
>>> >
>>> https://cwiki.apache.org/confluence/display/Hive/Proposed+Changes+to+Hive+Project+Bylaws+-+April+2016
>>> >> .
>>> >
>>> > It includes this paragraph: "Minor issues (e.g. typos, code style
>>> issues,
>>> > JavaDoc changes. At committer's discretion) can be committed after
>>> > soliciting feedback/review on the mailing list and not receiving
>>> feedback
>>> > within 2 days."
>>> > I'm not a native speaker so feedback is welcome.
>>> >
>>> > I also fixed three typos in the Bylaws (and marked them as changed): <
>>> >
>>> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=62691925&selectedPageVersions=3&selectedPageVersions=2
>>> >>
>>> >
>>> > Once the discussion settles down I'll open a vote thread on the user@
>>> > mailing list which requires a 2/3 majority of all active PMC members. I
>>> > couldn't find a definition of "active" though.
>>> >
>>> > On Mon, Apr 11, 2016 at 10:26 PM, Thejas Nair <th...@gmail.com>
>>> wrote:
>>> >
>>> >> I agree we have a problem here. At least patches as small as this
>>> >> shouldn't take too long to get reviewed.
>>> >>
>>> >> Knox seems to consider a very large set of patches as being under CTR
>>> >> process.
>>> >> I think hive is very large and mature project that I would lean
>>> >> towards RTC process for most issues. I think we can make an exception
>>> >> for very minor patches such as fixing typos and and checkstyle issues.
>>> >> Maybe the process can be to solicit reviews for such minor patches by
>>> >> sending an email to dev@ list and if no response is seen in 2 days,
>>> go
>>> >> ahead and commit it ?
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Apr 11, 2016 at 6:38 AM, Lars Francke <lars.francke@gmail.com
>>> >
>>> >> wrote:
>>> >>> Hi,
>>> >>>
>>> >>> I've been a long-time contributor to Hive (5 or so years) and have
>>> been
>>> >>> voted in as a committer and I'm very grateful for that. I also
>>> understand
>>> >>> that my situation is different than most or lots of committers as
>>> I'm not
>>> >>> working for one of the big companies (Facebook, Cloudera, Hortonworks
>>> >> etc.)
>>> >>> where you can just ask someone sitting next to you to do a review.
>>> >>>
>>> >>> I'd really like to contribute more than I do currently but the
>>> process of
>>> >>> getting patches in is painful for me (and other 'outside'
>>> contributors)
>>> >> as
>>> >>> it is hard to get reviews & things committed. The nature of most of
>>> my
>>> >>> patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
>>> >>> understand that these are not the most interesting patches to review
>>> and
>>> >>> are easy to miss. I don't blame anyone for this situation as I
>>> totally
>>> >>> understand it and have been on the other side of this for other
>>> projects.
>>> >>>
>>> >>> Is there anything we can do to make it easier for me and others like
>>> me
>>> >> to
>>> >>> contribute here? I absolutely see the value in having "cleaner" code
>>> and
>>> >>> when done in small batches it's usually not very disruptive either.
>>> >>>
>>> >>> The bylaws currently require a +1 from a committer who has not
>>> authored
>>> >> the
>>> >>> patch. Knox for example has a different policy [2] where they
>>> distinguish
>>> >>> between major features and minor things which can be committed
>>> freely.
>>> >>>
>>> >>> Hive could adopt something similar or like a middle ground. These are
>>> >> just
>>> >>> two suggestions:
>>> >>>
>>> >>> 1) Allow minor changes (up to the committers discretion) without
>>> >> requiring
>>> >>> an extra +1
>>> >>> 2) Allow minor changes (up to the committers discretion) with Lazy
>>> >> approval
>>> >>> (i.e. wait 24 hours)
>>> >>>
>>> >>> Sorry for the long rant but I'd love some feedback on this and am
>>> looking
>>> >>> forward to contributing more in the future.
>>> >>>
>>> >>> Cheers,
>>> >>> Lars
>>> >>>
>>> >>> [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
>>> >>> [2] <
>>> >> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process
>>> >
>>> >>
>>>
>>>
>>
>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Lars Francke <la...@gmail.com>.
Okay I have started a VOTE thread on the user@ mailing list (as per the
bylaws). I would appreciate it if you could head over there and vote :)
Thank you!
On Thu, Apr 14, 2016 at 12:41 AM, Lars Francke <la...@gmail.com>
wrote:
> Thanks for the +1 Alan.
>
> I agree that we're leaving potential contributions on the floor. Doing
> more reviews is definitely a very good step in the right direction. Thank
> you! I see this Bylaws change as another (small) step in the right
> direction. I'm sure we can come up with more ideas.
>
> I'll start a VOTE thread on the user@ mailing list.
>
> On Tue, Apr 12, 2016 at 5:32 PM, Alan Gates <al...@gmail.com> wrote:
>
>> I’m +1 on this change of allowing simple cleanup changes without
>> requiring a full review.
>>
>> But jumping to this fix obscures a bigger problem we have as a
>> community. This fix only works for committers, not for non-committers who
>> may also contribute such patches. And it doesn’t solve the situation for
>> non-trivial patches. We’re leaving potential contributions on the floor
>> and keeping people out of our community. We need to solve this.
>>
>> One thing I’ve been doing over the last few months is set up a filter in
>> JIRA for components that I know well (metastore, acid, etc.) and then put a
>> recurring task in my task tracker app to review a patch every day.
>> Realistically I manage 2-3 reviews a week, but that’s 1-2 more than I was
>> doing before. I encourage my fellow committers to find something that
>> works for them. We need to improve the health of our community.
>>
>> Alan.
>>
>> > On Apr 12, 2016, at 07:56, Lars Francke <la...@gmail.com> wrote:
>> >
>> > Thanks Thejas for the suggestion & others for jumping in. That seems
>> fine
>> > for me. 2 days also seems good. Holidays are different in almost every
>> > country so I wouldn't exclude those.
>> >
>> > I have followed the procedure used for the last Bylaws change and
>> created a
>> > new Wiki page here: <
>> >
>> https://cwiki.apache.org/confluence/display/Hive/Proposed+Changes+to+Hive+Project+Bylaws+-+April+2016
>> >> .
>> >
>> > It includes this paragraph: "Minor issues (e.g. typos, code style
>> issues,
>> > JavaDoc changes. At committer's discretion) can be committed after
>> > soliciting feedback/review on the mailing list and not receiving
>> feedback
>> > within 2 days."
>> > I'm not a native speaker so feedback is welcome.
>> >
>> > I also fixed three typos in the Bylaws (and marked them as changed): <
>> >
>> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=62691925&selectedPageVersions=3&selectedPageVersions=2
>> >>
>> >
>> > Once the discussion settles down I'll open a vote thread on the user@
>> > mailing list which requires a 2/3 majority of all active PMC members. I
>> > couldn't find a definition of "active" though.
>> >
>> > On Mon, Apr 11, 2016 at 10:26 PM, Thejas Nair <th...@gmail.com>
>> wrote:
>> >
>> >> I agree we have a problem here. At least patches as small as this
>> >> shouldn't take too long to get reviewed.
>> >>
>> >> Knox seems to consider a very large set of patches as being under CTR
>> >> process.
>> >> I think hive is very large and mature project that I would lean
>> >> towards RTC process for most issues. I think we can make an exception
>> >> for very minor patches such as fixing typos and and checkstyle issues.
>> >> Maybe the process can be to solicit reviews for such minor patches by
>> >> sending an email to dev@ list and if no response is seen in 2 days, go
>> >> ahead and commit it ?
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Apr 11, 2016 at 6:38 AM, Lars Francke <la...@gmail.com>
>> >> wrote:
>> >>> Hi,
>> >>>
>> >>> I've been a long-time contributor to Hive (5 or so years) and have
>> been
>> >>> voted in as a committer and I'm very grateful for that. I also
>> understand
>> >>> that my situation is different than most or lots of committers as I'm
>> not
>> >>> working for one of the big companies (Facebook, Cloudera, Hortonworks
>> >> etc.)
>> >>> where you can just ask someone sitting next to you to do a review.
>> >>>
>> >>> I'd really like to contribute more than I do currently but the
>> process of
>> >>> getting patches in is painful for me (and other 'outside'
>> contributors)
>> >> as
>> >>> it is hard to get reviews & things committed. The nature of most of my
>> >>> patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
>> >>> understand that these are not the most interesting patches to review
>> and
>> >>> are easy to miss. I don't blame anyone for this situation as I totally
>> >>> understand it and have been on the other side of this for other
>> projects.
>> >>>
>> >>> Is there anything we can do to make it easier for me and others like
>> me
>> >> to
>> >>> contribute here? I absolutely see the value in having "cleaner" code
>> and
>> >>> when done in small batches it's usually not very disruptive either.
>> >>>
>> >>> The bylaws currently require a +1 from a committer who has not
>> authored
>> >> the
>> >>> patch. Knox for example has a different policy [2] where they
>> distinguish
>> >>> between major features and minor things which can be committed freely.
>> >>>
>> >>> Hive could adopt something similar or like a middle ground. These are
>> >> just
>> >>> two suggestions:
>> >>>
>> >>> 1) Allow minor changes (up to the committers discretion) without
>> >> requiring
>> >>> an extra +1
>> >>> 2) Allow minor changes (up to the committers discretion) with Lazy
>> >> approval
>> >>> (i.e. wait 24 hours)
>> >>>
>> >>> Sorry for the long rant but I'd love some feedback on this and am
>> looking
>> >>> forward to contributing more in the future.
>> >>>
>> >>> Cheers,
>> >>> Lars
>> >>>
>> >>> [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
>> >>> [2] <
>> >> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>
>> >>
>>
>>
>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Lars Francke <la...@gmail.com>.
Thanks for the +1 Alan.
I agree that we're leaving potential contributions on the floor. Doing more
reviews is definitely a very good step in the right direction. Thank you! I
see this Bylaws change as another (small) step in the right direction. I'm
sure we can come up with more ideas.
I'll start a VOTE thread on the user@ mailing list.
On Tue, Apr 12, 2016 at 5:32 PM, Alan Gates <al...@gmail.com> wrote:
> I’m +1 on this change of allowing simple cleanup changes without requiring
> a full review.
>
> But jumping to this fix obscures a bigger problem we have as a community.
> This fix only works for committers, not for non-committers who may also
> contribute such patches. And it doesn’t solve the situation for
> non-trivial patches. We’re leaving potential contributions on the floor
> and keeping people out of our community. We need to solve this.
>
> One thing I’ve been doing over the last few months is set up a filter in
> JIRA for components that I know well (metastore, acid, etc.) and then put a
> recurring task in my task tracker app to review a patch every day.
> Realistically I manage 2-3 reviews a week, but that’s 1-2 more than I was
> doing before. I encourage my fellow committers to find something that
> works for them. We need to improve the health of our community.
>
> Alan.
>
> > On Apr 12, 2016, at 07:56, Lars Francke <la...@gmail.com> wrote:
> >
> > Thanks Thejas for the suggestion & others for jumping in. That seems fine
> > for me. 2 days also seems good. Holidays are different in almost every
> > country so I wouldn't exclude those.
> >
> > I have followed the procedure used for the last Bylaws change and
> created a
> > new Wiki page here: <
> >
> https://cwiki.apache.org/confluence/display/Hive/Proposed+Changes+to+Hive+Project+Bylaws+-+April+2016
> >> .
> >
> > It includes this paragraph: "Minor issues (e.g. typos, code style issues,
> > JavaDoc changes. At committer's discretion) can be committed after
> > soliciting feedback/review on the mailing list and not receiving feedback
> > within 2 days."
> > I'm not a native speaker so feedback is welcome.
> >
> > I also fixed three typos in the Bylaws (and marked them as changed): <
> >
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=62691925&selectedPageVersions=3&selectedPageVersions=2
> >>
> >
> > Once the discussion settles down I'll open a vote thread on the user@
> > mailing list which requires a 2/3 majority of all active PMC members. I
> > couldn't find a definition of "active" though.
> >
> > On Mon, Apr 11, 2016 at 10:26 PM, Thejas Nair <th...@gmail.com>
> wrote:
> >
> >> I agree we have a problem here. At least patches as small as this
> >> shouldn't take too long to get reviewed.
> >>
> >> Knox seems to consider a very large set of patches as being under CTR
> >> process.
> >> I think hive is very large and mature project that I would lean
> >> towards RTC process for most issues. I think we can make an exception
> >> for very minor patches such as fixing typos and and checkstyle issues.
> >> Maybe the process can be to solicit reviews for such minor patches by
> >> sending an email to dev@ list and if no response is seen in 2 days, go
> >> ahead and commit it ?
> >>
> >>
> >>
> >>
> >> On Mon, Apr 11, 2016 at 6:38 AM, Lars Francke <la...@gmail.com>
> >> wrote:
> >>> Hi,
> >>>
> >>> I've been a long-time contributor to Hive (5 or so years) and have been
> >>> voted in as a committer and I'm very grateful for that. I also
> understand
> >>> that my situation is different than most or lots of committers as I'm
> not
> >>> working for one of the big companies (Facebook, Cloudera, Hortonworks
> >> etc.)
> >>> where you can just ask someone sitting next to you to do a review.
> >>>
> >>> I'd really like to contribute more than I do currently but the process
> of
> >>> getting patches in is painful for me (and other 'outside' contributors)
> >> as
> >>> it is hard to get reviews & things committed. The nature of most of my
> >>> patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
> >>> understand that these are not the most interesting patches to review
> and
> >>> are easy to miss. I don't blame anyone for this situation as I totally
> >>> understand it and have been on the other side of this for other
> projects.
> >>>
> >>> Is there anything we can do to make it easier for me and others like me
> >> to
> >>> contribute here? I absolutely see the value in having "cleaner" code
> and
> >>> when done in small batches it's usually not very disruptive either.
> >>>
> >>> The bylaws currently require a +1 from a committer who has not authored
> >> the
> >>> patch. Knox for example has a different policy [2] where they
> distinguish
> >>> between major features and minor things which can be committed freely.
> >>>
> >>> Hive could adopt something similar or like a middle ground. These are
> >> just
> >>> two suggestions:
> >>>
> >>> 1) Allow minor changes (up to the committers discretion) without
> >> requiring
> >>> an extra +1
> >>> 2) Allow minor changes (up to the committers discretion) with Lazy
> >> approval
> >>> (i.e. wait 24 hours)
> >>>
> >>> Sorry for the long rant but I'd love some feedback on this and am
> looking
> >>> forward to contributing more in the future.
> >>>
> >>> Cheers,
> >>> Lars
> >>>
> >>> [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
> >>> [2] <
> >> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>
> >>
>
>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Alan Gates <al...@gmail.com>.
I’m +1 on this change of allowing simple cleanup changes without requiring a full review.
But jumping to this fix obscures a bigger problem we have as a community. This fix only works for committers, not for non-committers who may also contribute such patches. And it doesn’t solve the situation for non-trivial patches. We’re leaving potential contributions on the floor and keeping people out of our community. We need to solve this.
One thing I’ve been doing over the last few months is set up a filter in JIRA for components that I know well (metastore, acid, etc.) and then put a recurring task in my task tracker app to review a patch every day. Realistically I manage 2-3 reviews a week, but that’s 1-2 more than I was doing before. I encourage my fellow committers to find something that works for them. We need to improve the health of our community.
Alan.
> On Apr 12, 2016, at 07:56, Lars Francke <la...@gmail.com> wrote:
>
> Thanks Thejas for the suggestion & others for jumping in. That seems fine
> for me. 2 days also seems good. Holidays are different in almost every
> country so I wouldn't exclude those.
>
> I have followed the procedure used for the last Bylaws change and created a
> new Wiki page here: <
> https://cwiki.apache.org/confluence/display/Hive/Proposed+Changes+to+Hive+Project+Bylaws+-+April+2016
>> .
>
> It includes this paragraph: "Minor issues (e.g. typos, code style issues,
> JavaDoc changes. At committer's discretion) can be committed after
> soliciting feedback/review on the mailing list and not receiving feedback
> within 2 days."
> I'm not a native speaker so feedback is welcome.
>
> I also fixed three typos in the Bylaws (and marked them as changed): <
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=62691925&selectedPageVersions=3&selectedPageVersions=2
>>
>
> Once the discussion settles down I'll open a vote thread on the user@
> mailing list which requires a 2/3 majority of all active PMC members. I
> couldn't find a definition of "active" though.
>
> On Mon, Apr 11, 2016 at 10:26 PM, Thejas Nair <th...@gmail.com> wrote:
>
>> I agree we have a problem here. At least patches as small as this
>> shouldn't take too long to get reviewed.
>>
>> Knox seems to consider a very large set of patches as being under CTR
>> process.
>> I think hive is very large and mature project that I would lean
>> towards RTC process for most issues. I think we can make an exception
>> for very minor patches such as fixing typos and and checkstyle issues.
>> Maybe the process can be to solicit reviews for such minor patches by
>> sending an email to dev@ list and if no response is seen in 2 days, go
>> ahead and commit it ?
>>
>>
>>
>>
>> On Mon, Apr 11, 2016 at 6:38 AM, Lars Francke <la...@gmail.com>
>> wrote:
>>> Hi,
>>>
>>> I've been a long-time contributor to Hive (5 or so years) and have been
>>> voted in as a committer and I'm very grateful for that. I also understand
>>> that my situation is different than most or lots of committers as I'm not
>>> working for one of the big companies (Facebook, Cloudera, Hortonworks
>> etc.)
>>> where you can just ask someone sitting next to you to do a review.
>>>
>>> I'd really like to contribute more than I do currently but the process of
>>> getting patches in is painful for me (and other 'outside' contributors)
>> as
>>> it is hard to get reviews & things committed. The nature of most of my
>>> patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
>>> understand that these are not the most interesting patches to review and
>>> are easy to miss. I don't blame anyone for this situation as I totally
>>> understand it and have been on the other side of this for other projects.
>>>
>>> Is there anything we can do to make it easier for me and others like me
>> to
>>> contribute here? I absolutely see the value in having "cleaner" code and
>>> when done in small batches it's usually not very disruptive either.
>>>
>>> The bylaws currently require a +1 from a committer who has not authored
>> the
>>> patch. Knox for example has a different policy [2] where they distinguish
>>> between major features and minor things which can be committed freely.
>>>
>>> Hive could adopt something similar or like a middle ground. These are
>> just
>>> two suggestions:
>>>
>>> 1) Allow minor changes (up to the committers discretion) without
>> requiring
>>> an extra +1
>>> 2) Allow minor changes (up to the committers discretion) with Lazy
>> approval
>>> (i.e. wait 24 hours)
>>>
>>> Sorry for the long rant but I'd love some feedback on this and am looking
>>> forward to contributing more in the future.
>>>
>>> Cheers,
>>> Lars
>>>
>>> [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
>>> [2] <
>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>
>>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Lars Francke <la...@gmail.com>.
Thanks Thejas for the suggestion & others for jumping in. That seems fine
for me. 2 days also seems good. Holidays are different in almost every
country so I wouldn't exclude those.
I have followed the procedure used for the last Bylaws change and created a
new Wiki page here: <
https://cwiki.apache.org/confluence/display/Hive/Proposed+Changes+to+Hive+Project+Bylaws+-+April+2016
>.
It includes this paragraph: "Minor issues (e.g. typos, code style issues,
JavaDoc changes. At committer's discretion) can be committed after
soliciting feedback/review on the mailing list and not receiving feedback
within 2 days."
I'm not a native speaker so feedback is welcome.
I also fixed three typos in the Bylaws (and marked them as changed): <
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=62691925&selectedPageVersions=3&selectedPageVersions=2
>
Once the discussion settles down I'll open a vote thread on the user@
mailing list which requires a 2/3 majority of all active PMC members. I
couldn't find a definition of "active" though.
On Mon, Apr 11, 2016 at 10:26 PM, Thejas Nair <th...@gmail.com> wrote:
> I agree we have a problem here. At least patches as small as this
> shouldn't take too long to get reviewed.
>
> Knox seems to consider a very large set of patches as being under CTR
> process.
> I think hive is very large and mature project that I would lean
> towards RTC process for most issues. I think we can make an exception
> for very minor patches such as fixing typos and and checkstyle issues.
> Maybe the process can be to solicit reviews for such minor patches by
> sending an email to dev@ list and if no response is seen in 2 days, go
> ahead and commit it ?
>
>
>
>
> On Mon, Apr 11, 2016 at 6:38 AM, Lars Francke <la...@gmail.com>
> wrote:
> > Hi,
> >
> > I've been a long-time contributor to Hive (5 or so years) and have been
> > voted in as a committer and I'm very grateful for that. I also understand
> > that my situation is different than most or lots of committers as I'm not
> > working for one of the big companies (Facebook, Cloudera, Hortonworks
> etc.)
> > where you can just ask someone sitting next to you to do a review.
> >
> > I'd really like to contribute more than I do currently but the process of
> > getting patches in is painful for me (and other 'outside' contributors)
> as
> > it is hard to get reviews & things committed. The nature of most of my
> > patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
> > understand that these are not the most interesting patches to review and
> > are easy to miss. I don't blame anyone for this situation as I totally
> > understand it and have been on the other side of this for other projects.
> >
> > Is there anything we can do to make it easier for me and others like me
> to
> > contribute here? I absolutely see the value in having "cleaner" code and
> > when done in small batches it's usually not very disruptive either.
> >
> > The bylaws currently require a +1 from a committer who has not authored
> the
> > patch. Knox for example has a different policy [2] where they distinguish
> > between major features and minor things which can be committed freely.
> >
> > Hive could adopt something similar or like a middle ground. These are
> just
> > two suggestions:
> >
> > 1) Allow minor changes (up to the committers discretion) without
> requiring
> > an extra +1
> > 2) Allow minor changes (up to the committers discretion) with Lazy
> approval
> > (i.e. wait 24 hours)
> >
> > Sorry for the long rant but I'd love some feedback on this and am looking
> > forward to contributing more in the future.
> >
> > Cheers,
> > Lars
> >
> > [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
> > [2] <
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>
>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Sergey Shelukhin <se...@hortonworks.com>.
2 days may be too short… One can submit all the patches on Friday night
and commit on Sunday ;)
On 16/4/11, 17:43, "Prasanth Jayachandran" <pj...@hortonworks.com>
wrote:
>Also, it will be good to add “NO PRECOMMIT TESTS” in the description of
>the jira
>if the patches are really small and does not affect any tests
>(checkstyles, typos etc.)
>to avoid occupying a slot in the precommit queue which could be
>overloaded sometimes.
>
>+1 for 2 days no response on dev-list.
>
>Thanks
>Prasanth
>
>> On Apr 11, 2016, at 7:36 PM, Lefty Leverenz <le...@gmail.com>
>>wrote:
>>
>>>
>>> Maybe the process can be to solicit reviews for such minor patches by
>>> sending an email to dev@ list and if no response is seen in 2 days, go
>>> ahead and commit it ?
>>>
>>
>> Two days seems reasonable, perhaps excluding weekends and major
>>holidays.
>>
>> -- Lefty
>>
>> On Mon, Apr 11, 2016 at 1:26 PM, Thejas Nair <th...@gmail.com>
>>wrote:
>>
>>> I agree we have a problem here. At least patches as small as this
>>> shouldn't take too long to get reviewed.
>>>
>>> Knox seems to consider a very large set of patches as being under CTR
>>> process.
>>> I think hive is very large and mature project that I would lean
>>> towards RTC process for most issues. I think we can make an exception
>>> for very minor patches such as fixing typos and and checkstyle issues.
>>> Maybe the process can be to solicit reviews for such minor patches by
>>> sending an email to dev@ list and if no response is seen in 2 days, go
>>> ahead and commit it ?
>>>
>>>
>>>
>>>
>>> On Mon, Apr 11, 2016 at 6:38 AM, Lars Francke <la...@gmail.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> I've been a long-time contributor to Hive (5 or so years) and have
>>>>been
>>>> voted in as a committer and I'm very grateful for that. I also
>>>>understand
>>>> that my situation is different than most or lots of committers as I'm
>>>>not
>>>> working for one of the big companies (Facebook, Cloudera, Hortonworks
>>> etc.)
>>>> where you can just ask someone sitting next to you to do a review.
>>>>
>>>> I'd really like to contribute more than I do currently but the
>>>>process of
>>>> getting patches in is painful for me (and other 'outside'
>>>>contributors)
>>> as
>>>> it is hard to get reviews & things committed. The nature of most of my
>>>> patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
>>>> understand that these are not the most interesting patches to review
>>>>and
>>>> are easy to miss. I don't blame anyone for this situation as I totally
>>>> understand it and have been on the other side of this for other
>>>>projects.
>>>>
>>>> Is there anything we can do to make it easier for me and others like
>>>>me
>>> to
>>>> contribute here? I absolutely see the value in having "cleaner" code
>>>>and
>>>> when done in small batches it's usually not very disruptive either.
>>>>
>>>> The bylaws currently require a +1 from a committer who has not
>>>>authored
>>> the
>>>> patch. Knox for example has a different policy [2] where they
>>>>distinguish
>>>> between major features and minor things which can be committed freely.
>>>>
>>>> Hive could adopt something similar or like a middle ground. These are
>>> just
>>>> two suggestions:
>>>>
>>>> 1) Allow minor changes (up to the committers discretion) without
>>> requiring
>>>> an extra +1
>>>> 2) Allow minor changes (up to the committers discretion) with Lazy
>>> approval
>>>> (i.e. wait 24 hours)
>>>>
>>>> Sorry for the long rant but I'd love some feedback on this and am
>>>>looking
>>>> forward to contributing more in the future.
>>>>
>>>> Cheers,
>>>> Lars
>>>>
>>>> [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
>>>> [2] <
>>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>
>>>
>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Prasanth Jayachandran <pj...@hortonworks.com>.
Also, it will be good to add “NO PRECOMMIT TESTS” in the description of the jira
if the patches are really small and does not affect any tests (checkstyles, typos etc.)
to avoid occupying a slot in the precommit queue which could be overloaded sometimes.
+1 for 2 days no response on dev-list.
Thanks
Prasanth
> On Apr 11, 2016, at 7:36 PM, Lefty Leverenz <le...@gmail.com> wrote:
>
>>
>> Maybe the process can be to solicit reviews for such minor patches by
>> sending an email to dev@ list and if no response is seen in 2 days, go
>> ahead and commit it ?
>>
>
> Two days seems reasonable, perhaps excluding weekends and major holidays.
>
> -- Lefty
>
> On Mon, Apr 11, 2016 at 1:26 PM, Thejas Nair <th...@gmail.com> wrote:
>
>> I agree we have a problem here. At least patches as small as this
>> shouldn't take too long to get reviewed.
>>
>> Knox seems to consider a very large set of patches as being under CTR
>> process.
>> I think hive is very large and mature project that I would lean
>> towards RTC process for most issues. I think we can make an exception
>> for very minor patches such as fixing typos and and checkstyle issues.
>> Maybe the process can be to solicit reviews for such minor patches by
>> sending an email to dev@ list and if no response is seen in 2 days, go
>> ahead and commit it ?
>>
>>
>>
>>
>> On Mon, Apr 11, 2016 at 6:38 AM, Lars Francke <la...@gmail.com>
>> wrote:
>>> Hi,
>>>
>>> I've been a long-time contributor to Hive (5 or so years) and have been
>>> voted in as a committer and I'm very grateful for that. I also understand
>>> that my situation is different than most or lots of committers as I'm not
>>> working for one of the big companies (Facebook, Cloudera, Hortonworks
>> etc.)
>>> where you can just ask someone sitting next to you to do a review.
>>>
>>> I'd really like to contribute more than I do currently but the process of
>>> getting patches in is painful for me (and other 'outside' contributors)
>> as
>>> it is hard to get reviews & things committed. The nature of most of my
>>> patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
>>> understand that these are not the most interesting patches to review and
>>> are easy to miss. I don't blame anyone for this situation as I totally
>>> understand it and have been on the other side of this for other projects.
>>>
>>> Is there anything we can do to make it easier for me and others like me
>> to
>>> contribute here? I absolutely see the value in having "cleaner" code and
>>> when done in small batches it's usually not very disruptive either.
>>>
>>> The bylaws currently require a +1 from a committer who has not authored
>> the
>>> patch. Knox for example has a different policy [2] where they distinguish
>>> between major features and minor things which can be committed freely.
>>>
>>> Hive could adopt something similar or like a middle ground. These are
>> just
>>> two suggestions:
>>>
>>> 1) Allow minor changes (up to the committers discretion) without
>> requiring
>>> an extra +1
>>> 2) Allow minor changes (up to the committers discretion) with Lazy
>> approval
>>> (i.e. wait 24 hours)
>>>
>>> Sorry for the long rant but I'd love some feedback on this and am looking
>>> forward to contributing more in the future.
>>>
>>> Cheers,
>>> Lars
>>>
>>> [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
>>> [2] <
>> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>
>>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Lefty Leverenz <le...@gmail.com>.
>
> Maybe the process can be to solicit reviews for such minor patches by
> sending an email to dev@ list and if no response is seen in 2 days, go
> ahead and commit it ?
>
Two days seems reasonable, perhaps excluding weekends and major holidays.
-- Lefty
On Mon, Apr 11, 2016 at 1:26 PM, Thejas Nair <th...@gmail.com> wrote:
> I agree we have a problem here. At least patches as small as this
> shouldn't take too long to get reviewed.
>
> Knox seems to consider a very large set of patches as being under CTR
> process.
> I think hive is very large and mature project that I would lean
> towards RTC process for most issues. I think we can make an exception
> for very minor patches such as fixing typos and and checkstyle issues.
> Maybe the process can be to solicit reviews for such minor patches by
> sending an email to dev@ list and if no response is seen in 2 days, go
> ahead and commit it ?
>
>
>
>
> On Mon, Apr 11, 2016 at 6:38 AM, Lars Francke <la...@gmail.com>
> wrote:
> > Hi,
> >
> > I've been a long-time contributor to Hive (5 or so years) and have been
> > voted in as a committer and I'm very grateful for that. I also understand
> > that my situation is different than most or lots of committers as I'm not
> > working for one of the big companies (Facebook, Cloudera, Hortonworks
> etc.)
> > where you can just ask someone sitting next to you to do a review.
> >
> > I'd really like to contribute more than I do currently but the process of
> > getting patches in is painful for me (and other 'outside' contributors)
> as
> > it is hard to get reviews & things committed. The nature of most of my
> > patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
> > understand that these are not the most interesting patches to review and
> > are easy to miss. I don't blame anyone for this situation as I totally
> > understand it and have been on the other side of this for other projects.
> >
> > Is there anything we can do to make it easier for me and others like me
> to
> > contribute here? I absolutely see the value in having "cleaner" code and
> > when done in small batches it's usually not very disruptive either.
> >
> > The bylaws currently require a +1 from a committer who has not authored
> the
> > patch. Knox for example has a different policy [2] where they distinguish
> > between major features and minor things which can be committed freely.
> >
> > Hive could adopt something similar or like a middle ground. These are
> just
> > two suggestions:
> >
> > 1) Allow minor changes (up to the committers discretion) without
> requiring
> > an extra +1
> > 2) Allow minor changes (up to the committers discretion) with Lazy
> approval
> > (i.e. wait 24 hours)
> >
> > Sorry for the long rant but I'd love some feedback on this and am looking
> > forward to contributing more in the future.
> >
> > Cheers,
> > Lars
> >
> > [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
> > [2] <
> https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>
>
Re: Reviews & commits (RTC/CTR), contributions, bylaws
Posted by Thejas Nair <th...@gmail.com>.
I agree we have a problem here. At least patches as small as this
shouldn't take too long to get reviewed.
Knox seems to consider a very large set of patches as being under CTR process.
I think hive is very large and mature project that I would lean
towards RTC process for most issues. I think we can make an exception
for very minor patches such as fixing typos and and checkstyle issues.
Maybe the process can be to solicit reviews for such minor patches by
sending an email to dev@ list and if no response is seen in 2 days, go
ahead and commit it ?
On Mon, Apr 11, 2016 at 6:38 AM, Lars Francke <la...@gmail.com> wrote:
> Hi,
>
> I've been a long-time contributor to Hive (5 or so years) and have been
> voted in as a committer and I'm very grateful for that. I also understand
> that my situation is different than most or lots of committers as I'm not
> working for one of the big companies (Facebook, Cloudera, Hortonworks etc.)
> where you can just ask someone sitting next to you to do a review.
>
> I'd really like to contribute more than I do currently but the process of
> getting patches in is painful for me (and other 'outside' contributors) as
> it is hard to get reviews & things committed. The nature of most of my
> patches is very minor[1] (fixing typos, checkstyle issues etc.) and I
> understand that these are not the most interesting patches to review and
> are easy to miss. I don't blame anyone for this situation as I totally
> understand it and have been on the other side of this for other projects.
>
> Is there anything we can do to make it easier for me and others like me to
> contribute here? I absolutely see the value in having "cleaner" code and
> when done in small batches it's usually not very disruptive either.
>
> The bylaws currently require a +1 from a committer who has not authored the
> patch. Knox for example has a different policy [2] where they distinguish
> between major features and minor things which can be committed freely.
>
> Hive could adopt something similar or like a middle ground. These are just
> two suggestions:
>
> 1) Allow minor changes (up to the committers discretion) without requiring
> an extra +1
> 2) Allow minor changes (up to the committers discretion) with Lazy approval
> (i.e. wait 24 hours)
>
> Sorry for the long rant but I'd love some feedback on this and am looking
> forward to contributing more in the future.
>
> Cheers,
> Lars
>
> [1] e.g. <https://issues.apache.org/jira/browse/HIVE-12467>
> [2] <https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process>