You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Ashvin A <aa...@gmail.com> on 2015/05/05 18:56:27 UTC
Verify impact of a pull request
Hi,
We are working on finalizing the dev process and I may be jumping on this
question sooner. If so, please ignore my mail.
I saw a couple of pull requests today. As a committer, how will I know if
the contributor has executed all the unit tests and the patch is well
tested? Will the infrastructure automatically reject the change if it
breaks the build?
Thanks !
Ashvin
Re: Verify impact of a pull request
Posted by Dan Smith <ds...@pivotal.io>.
I think it would be nice to have infrastructure that can automatically run
tests on a pull request.
The current test suite for geode is fairly small because we didn't get the
majority of the tests into the initial commit of geode. Those tests should
be available in not too long to be merged into geode. Assuming the
community wants the tests to be a requirement for committing (I'm strongly
in favor of that!), then running the tests will take hours. That may be a
burden on someone developing on a laptop without access to other hardware.
-Dan
On Tue, May 5, 2015 at 3:37 PM, William Markito <wm...@pivotal.io> wrote:
> Some details are already here:
>
>
> https://cwiki.apache.org/confluence/display/GEODE/Criteria+for+Code+Submissions
>
> On Tue, May 5, 2015 at 3:34 PM, William Markito <wm...@pivotal.io>
> wrote:
>
> > Hi Ashvin,
> >
> > That's indeed part of a bigger discussion regarding governance model,
> > review process and criteria for PR's.
> >
> > This get discussed and proposed, but my understanding is that indeed
> there
> > will be a process that after reviewed and accepted, these changes will go
> > into the nightly builds and if they break the build it will generate a
> new
> > JIRA to track what happened and fix the issues.
> >
> > It's part of the committer responsibility to run such tests before
> > actually committing and the review process can ensure that prior to
> accept
> > the PR.
> >
> >
> >
> > On Tue, May 5, 2015 at 9:56 AM, Ashvin A <aa...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> We are working on finalizing the dev process and I may be jumping on
> this
> >> question sooner. If so, please ignore my mail.
> >>
> >> I saw a couple of pull requests today. As a committer, how will I know
> if
> >> the contributor has executed all the unit tests and the patch is well
> >> tested? Will the infrastructure automatically reject the change if it
> >> breaks the build?
> >>
> >> Thanks !
> >> Ashvin
> >>
> >
> >
> >
> > --
> >
> > William Markito Oliveira
> > Enterprise Architect
> > *http://www.pivotal.io/ <http://www.pivotal.io/>*
> > For prompt responses to questions on GemFire/GemFireXD, please write to
> *rtds-dev-ea
> > at pivotal.io <http://pivotal.io>*
> >
>
>
>
> --
>
> William Markito Oliveira
> Enterprise Architect
> *http://www.pivotal.io/ <http://www.pivotal.io/>*
> For prompt responses to questions on GemFire/GemFireXD, please write
> to *rtds-dev-ea
> at pivotal.io <http://pivotal.io>*
>
Re: Verify impact of a pull request
Posted by William Markito <wm...@pivotal.io>.
Some details are already here:
https://cwiki.apache.org/confluence/display/GEODE/Criteria+for+Code+Submissions
On Tue, May 5, 2015 at 3:34 PM, William Markito <wm...@pivotal.io> wrote:
> Hi Ashvin,
>
> That's indeed part of a bigger discussion regarding governance model,
> review process and criteria for PR's.
>
> This get discussed and proposed, but my understanding is that indeed there
> will be a process that after reviewed and accepted, these changes will go
> into the nightly builds and if they break the build it will generate a new
> JIRA to track what happened and fix the issues.
>
> It's part of the committer responsibility to run such tests before
> actually committing and the review process can ensure that prior to accept
> the PR.
>
>
>
> On Tue, May 5, 2015 at 9:56 AM, Ashvin A <aa...@gmail.com> wrote:
>
>> Hi,
>>
>> We are working on finalizing the dev process and I may be jumping on this
>> question sooner. If so, please ignore my mail.
>>
>> I saw a couple of pull requests today. As a committer, how will I know if
>> the contributor has executed all the unit tests and the patch is well
>> tested? Will the infrastructure automatically reject the change if it
>> breaks the build?
>>
>> Thanks !
>> Ashvin
>>
>
>
>
> --
>
> William Markito Oliveira
> Enterprise Architect
> *http://www.pivotal.io/ <http://www.pivotal.io/>*
> For prompt responses to questions on GemFire/GemFireXD, please write to *rtds-dev-ea
> at pivotal.io <http://pivotal.io>*
>
--
William Markito Oliveira
Enterprise Architect
*http://www.pivotal.io/ <http://www.pivotal.io/>*
For prompt responses to questions on GemFire/GemFireXD, please write
to *rtds-dev-ea
at pivotal.io <http://pivotal.io>*
Re: Verify impact of a pull request
Posted by William Markito <wm...@pivotal.io>.
Hi Ashvin,
That's indeed part of a bigger discussion regarding governance model,
review process and criteria for PR's.
This get discussed and proposed, but my understanding is that indeed there
will be a process that after reviewed and accepted, these changes will go
into the nightly builds and if they break the build it will generate a new
JIRA to track what happened and fix the issues.
It's part of the committer responsibility to run such tests before actually
committing and the review process can ensure that prior to accept the PR.
On Tue, May 5, 2015 at 9:56 AM, Ashvin A <aa...@gmail.com> wrote:
> Hi,
>
> We are working on finalizing the dev process and I may be jumping on this
> question sooner. If so, please ignore my mail.
>
> I saw a couple of pull requests today. As a committer, how will I know if
> the contributor has executed all the unit tests and the patch is well
> tested? Will the infrastructure automatically reject the change if it
> breaks the build?
>
> Thanks !
> Ashvin
>
--
William Markito Oliveira
Enterprise Architect
*http://www.pivotal.io/ <http://www.pivotal.io/>*
For prompt responses to questions on GemFire/GemFireXD, please write
to *rtds-dev-ea
at pivotal.io <http://pivotal.io>*
Re: Verify impact of a pull request
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, May 5, 2015 at 7:38 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> I think what you're talking about is CI automation to make sure that
> all newly submitted patches are being validated. Hadoop ecosystem
> project have had great success with test-patch type of validation on
> builds.apache.org. We can go the same route.
>
> Thoughts?
+1.
There should be a set of local tests that all contributors should run
before submitting a patch, but it'd be real nice to build up an
automated test suite that runs distributed multi-machine tests. (I
have no clue if Hadoop is already doing such things already.)
Cheers. -- justin
Re: Verify impact of a pull request
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, May 5, 2015 at 9:56 AM, Ashvin A <aa...@gmail.com> wrote:
> Hi,
>
> We are working on finalizing the dev process and I may be jumping on this
> question sooner. If so, please ignore my mail.
>
> I saw a couple of pull requests today. As a committer, how will I know if
> the contributor has executed all the unit tests and the patch is well
> tested? Will the infrastructure automatically reject the change if it
> breaks the build?
I think what you're talking about is CI automation to make sure that
all newly submitted patches are being validated. Hadoop ecosystem
project have had great success with test-patch type of validation on
builds.apache.org. We can go the same route.
Thoughts?
Thanks,
Roman.