You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@helix.apache.org by Patrick Hunt <ph...@apache.org> on 2013/08/02 06:50:53 UTC

Re: Enforcing review before commit

On Wed, Jul 31, 2013 at 10:16 AM, kishore g <g....@gmail.com> wrote:
> Hi Pat,
>
> Do you know how patches are reviewed and applied in other projects. We want
> to enforce review and then commit policy for Helix. I am looking at some
> best practices out there.

Depends on the project. Many projects in the lucene lineage (e.g.
hadoop/zk/hive/pig/...) use jira attachments (patches) for
submission/tracking. contributors submit the patch via jira and
committers review/commit to svn. Only committers can commit code to
svn at apache. These tend to be RTC based projects.

Some projects use CTR, which is also fine. Tends to result in faster
development. However sometimes things can get in before they get
proper review. The community needs to keep an eye on commits and look
for issues. (often the case regardless)

I like RTC via jira because it makes things easier to track. It tends
to be a slower process though...

Patrick

Re: Enforcing review before commit

Posted by Patrick Hunt <ph...@apache.org>.
There's a precommit job on jenkins:
https://builds.apache.org//view/S-Z/view/ZooKeeper/job/PreCommit-ZOOKEEPER-Build/
when you attach a patch to a jira it runs this job, which includes
applying the patch to trunk.

I'm not very familiar with the details, Giri might be able to point
you in the right direction though.

Patrick

On Fri, Aug 2, 2013 at 11:42 AM, kishore g <g....@gmail.com> wrote:
> I see this HadoopQA update on every patch in zookeeper. Example:
> https://issues.apache.org/jira/browse/ZOOKEEPER-1731
>
> How is this setup.
>
> thanks,
> Kishore G
>
>
> On Thu, Aug 1, 2013 at 9:50 PM, Patrick Hunt <ph...@apache.org> wrote:
>
>> On Wed, Jul 31, 2013 at 10:16 AM, kishore g <g....@gmail.com> wrote:
>> > Hi Pat,
>> >
>> > Do you know how patches are reviewed and applied in other projects. We
>> want
>> > to enforce review and then commit policy for Helix. I am looking at some
>> > best practices out there.
>>
>> Depends on the project. Many projects in the lucene lineage (e.g.
>> hadoop/zk/hive/pig/...) use jira attachments (patches) for
>> submission/tracking. contributors submit the patch via jira and
>> committers review/commit to svn. Only committers can commit code to
>> svn at apache. These tend to be RTC based projects.
>>
>> Some projects use CTR, which is also fine. Tends to result in faster
>> development. However sometimes things can get in before they get
>> proper review. The community needs to keep an eye on commits and look
>> for issues. (often the case regardless)
>>
>> I like RTC via jira because it makes things easier to track. It tends
>> to be a slower process though...
>>
>> Patrick
>>

Re: Enforcing review before commit

Posted by kishore g <g....@gmail.com>.
I see this HadoopQA update on every patch in zookeeper. Example:
https://issues.apache.org/jira/browse/ZOOKEEPER-1731

How is this setup.

thanks,
Kishore G


On Thu, Aug 1, 2013 at 9:50 PM, Patrick Hunt <ph...@apache.org> wrote:

> On Wed, Jul 31, 2013 at 10:16 AM, kishore g <g....@gmail.com> wrote:
> > Hi Pat,
> >
> > Do you know how patches are reviewed and applied in other projects. We
> want
> > to enforce review and then commit policy for Helix. I am looking at some
> > best practices out there.
>
> Depends on the project. Many projects in the lucene lineage (e.g.
> hadoop/zk/hive/pig/...) use jira attachments (patches) for
> submission/tracking. contributors submit the patch via jira and
> committers review/commit to svn. Only committers can commit code to
> svn at apache. These tend to be RTC based projects.
>
> Some projects use CTR, which is also fine. Tends to result in faster
> development. However sometimes things can get in before they get
> proper review. The community needs to keep an eye on commits and look
> for issues. (often the case regardless)
>
> I like RTC via jira because it makes things easier to track. It tends
> to be a slower process though...
>
> Patrick
>