You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Andrew Bayer <an...@gmail.com> on 2014/07/01 00:38:20 UTC
Re: Okay to get ball rolling for pull requests?
Screw gerrit, we've already got the Jenkins Enterprise GitHub pull
request builder plugin enabled on builds.apache.org - it needs some
validation still and hooks to be set up by Infra on the GitHub repos,
but once that's done, you can have a job that watches for pull
requests, builds them, and comments on the pull request with the build
results.
As to that script - how is it being run? I assume by hand by Spark committers?
A.
On Mon, Jun 30, 2014 at 1:30 PM, Jay Vyas <ja...@gmail.com> wrote:
> push the merge button…… Almost - but not quite !
>
> Sorry for the lack of clarity --- as i recently learned of this process. I've gotten up to speed on the details: Here they are:
>
> I'll walk through the way this script
> https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py
> is used…..
>
>
> 1) Rather than actually submitting a patch, the user submits a pull request and a branch is created
> by the commiter, automatically using the script:
> run_cmd("git fetch %s pull/%s/head:%s" % (PR_REMOTE_NAME, pr_num, pr_branch_name))
>
> 2) Then, the script checks via github api if the patch is mergeable.
>
> pr = get_json("%s/pulls/%s" % (GITHUB_API_BASE, pr_num))
>
> 3) Then, the pull request is merged and pushed to apache:
> merge_hash = merge_pr(pr_num, target_ref)
>
>
Re: Okay to get ball rolling for pull requests?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Jun 30, 2014 at 10:08 PM, Jay Vyas <ja...@gmail.com> wrote:
> The actual script is done by the commiters. You can read about the process in the spark commiter guidelines:
>
> https://cwiki.apache.org/confluence/display/SPARK/Wiki+Homepage
This makes sense now.
> So the steps would be
>
> 1) Adopt the script for processing pull requests
>
> 2) Add it to our bigtop repo
>
> 3) Create a pull request and test the script for comitting it.
>
> Some might dispute one issue here : The patch system record of is a little diluted.
>
> Is that a big deal? Im not sure . I think its a tough decision - its no simple answer.
> If losing track of patches builds a significantly more vibrant ecosystem, i think its an okay tradeoff.
>
> Any other opinions on this?
Well, whatever automation we create to make the patch validation
and acceptance experience smoother is great.
That said, personally, I'd like to maintain two constraints:
1. all non-trivial changes MUST have a JIRA ID associated with them
2. any fixed for JIRAs that go into our code-base MUST have a
patch attached to a JIRA and be explicitly reviewed and +1ed.
Does this sounds reasonable?
Thanks,
Roman.
Re: Okay to get ball rolling for pull requests?
Posted by Jay Vyas <ja...@gmail.com>.
The actual script is done by the commiters. You can read about the process in the spark commiter guidelines:
https://cwiki.apache.org/confluence/display/SPARK/Wiki+Homepage
So the steps would be
1) Adopt the script for processing pull requests
2) Add it to our bigtop repo
3) Create a pull request and test the script for comitting it.
Some might dispute one issue here : The patch system record of is a little diluted.
Is that a big deal? Im not sure . I think its a tough decision - its no simple answer. If losing track of patches builds a significantly more vibrant ecosystem, i think its an okay tradeoff.
Any other opinions on this?
On Jun 30, 2014, at 6:38 PM, Andrew Bayer <an...@gmail.com> wrote:
> builds
Re: Okay to get ball rolling for pull requests?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
I think that should be fine. Anything that keep the JIRA thread
and only allows humans to +1 can be automated everywhere else.
Thanks,
Roman.
P.S. ASF sort of frowns on bots interacting with JIRA too much
on the write path -- but to me this is a minor issue.
On Tue, Jul 1, 2014 at 12:37 PM, Jay Vyas <ja...@gmail.com> wrote:
> Okay. Is it okay if a bot +1s the patch on behalf of a commiter ?
>
> That way commiter can directly merge a pull request (from their perspective), by running a script which turns the levers and knobs in the jira?
>
> Leave any final thoughts here.....Now that we are all in reasonabley same page --- Ill create a jira outlining this task!!!
>
>> On Jul 1, 2014, at 2:30 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>
>>> On Mon, Jun 30, 2014 at 3:38 PM, Andrew Bayer <an...@gmail.com> wrote:
>>> Screw gerrit, we've already got the Jenkins Enterprise GitHub pull
>>> request builder plugin enabled on builds.apache.org - it needs some
>>> validation still and hooks to be set up by Infra on the GitHub repos,
>>> but once that's done, you can have a job that watches for pull
>>> requests, builds them, and comments on the pull request with the build
>>> results.
>>
>> This would be awesome path forward, actually. I especially like the
>> possibility for an automated patch validation.
>>
>> Thanks,
>> Roman.
Re: Okay to get ball rolling for pull requests?
Posted by Jay Vyas <ja...@gmail.com>.
s/+1/Resolves
Sorry about the confusion : Im not suggesting bots review patches and +1 them :)
On Jul 1, 2014, at 3:37 PM, Jay Vyas <ja...@gmail.com> wrote:
> reasonabley
Re: Okay to get ball rolling for pull requests?
Posted by Jay Vyas <ja...@gmail.com>.
Okay. Is it okay if a bot +1s the patch on behalf of a commiter ?
That way commiter can directly merge a pull request (from their perspective), by running a script which turns the levers and knobs in the jira?
Leave any final thoughts here.....Now that we are all in reasonabley same page --- Ill create a jira outlining this task!!!
> On Jul 1, 2014, at 2:30 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
>> On Mon, Jun 30, 2014 at 3:38 PM, Andrew Bayer <an...@gmail.com> wrote:
>> Screw gerrit, we've already got the Jenkins Enterprise GitHub pull
>> request builder plugin enabled on builds.apache.org - it needs some
>> validation still and hooks to be set up by Infra on the GitHub repos,
>> but once that's done, you can have a job that watches for pull
>> requests, builds them, and comments on the pull request with the build
>> results.
>
> This would be awesome path forward, actually. I especially like the
> possibility for an automated patch validation.
>
> Thanks,
> Roman.
Re: Okay to get ball rolling for pull requests?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Jun 30, 2014 at 3:38 PM, Andrew Bayer <an...@gmail.com> wrote:
> Screw gerrit, we've already got the Jenkins Enterprise GitHub pull
> request builder plugin enabled on builds.apache.org - it needs some
> validation still and hooks to be set up by Infra on the GitHub repos,
> but once that's done, you can have a job that watches for pull
> requests, builds them, and comments on the pull request with the build
> results.
This would be awesome path forward, actually. I especially like the
possibility for an automated patch validation.
Thanks,
Roman.