Re: geode contribution process proposal
Other approach is to create dependency tree for tests (what tests depends on which code) and CI to run only the impacted tests for the corresponding code change (refer http://google-engtools.blogspot.in/2011/06/testing-at-speed-and-scale-of-google.html). I am not sure how dependency tree will be maintain, but if they are doing it then there must be some way. Running multiple tests simultaneously on same machine helps to quickly certify the change. I think we do it for dunit. Thanks, Rahul On Thu, Jun 18, 2015 at 12:20 AM, Roman Shaposhnik wrote: > On Tue, Jun 16, 2015 at 3:13 PM, jun aoki wrote: > > Anthony, thank you for providing the info. It is straightforward while > > developing. > > > > Some of us think we should run all tests (several hours according to Dan) > > and there are good reasons to do so. > > Roman, if you know the answer, please let us know; is it OK to occupy > > jenkins slaves for several hours on each test-patch on builds.a.o? Is > there > > any guideline we should follow in order to use builds.a.o? > > Quick answer: it is ok to start doing it. Go ahead! > > Longer answer: this really is a self-throttling question. If at some point > the > rate of patch submission will exceed the Jenkins capacity you may want > to invest in reducing the time it takes for tests required for test > patch to run. > After all, the whole point of the exerisze here is to increase the > confidence > of however is reviewing the patch by looking at test-patch reports. If > waiting > for those reports takes days -- it'll stop being acceptable. > > Thanks, > Roman. >
Re: geode contribution process proposal
On Tue, Jun 16, 2015 at 3:13 PM, jun aoki wrote: > Anthony, thank you for providing the info. It is straightforward while > developing. > > Some of us think we should run all tests (several hours according to Dan) > and there are good reasons to do so. > Roman, if you know the answer, please let us know; is it OK to occupy > jenkins slaves for several hours on each test-patch on builds.a.o? Is there > any guideline we should follow in order to use builds.a.o? Quick answer: it is ok to start doing it. Go ahead! Longer answer: this really is a self-throttling question. If at some point the rate of patch submission will exceed the Jenkins capacity you may want to invest in reducing the time it takes for tests required for test patch to run. After all, the whole point of the exerisze here is to increase the confidence of however is reviewing the patch by looking at test-patch reports. If waiting for those reports takes days -- it'll stop being acceptable. Thanks, Roman.
Re: geode contribution process proposal
Anthony, thank you for providing the info. It is straightforward while developing. Some of us think we should run all tests (several hours according to Dan) and there are good reasons to do so. Roman, if you know the answer, please let us know; is it OK to occupy jenkins slaves for several hours on each test-patch on builds.a.o? Is there any guideline we should follow in order to use builds.a.o? On Tue, Jun 16, 2015 at 2:31 PM, Anthony Baker wrote: > What I’m speaking of is a development process where you > > 1) write some code > 2) run some relevant tests > 3) repeat until done > > You can do that with gradle as follows (just as examples): > > gradle :gemfire-core:test -Dtest.single=ArrayUtilsJUnitTest > gradle :gemfire-core:test -Dtest.single=com/gemstone/gemfire/internal/util/ > gradle :gemfire-core:integrationTest > -DintegrationTest.single=DistributedSystemFactoryIntegrationJUnitTest > > > An optimized CI subset (maximum coverage / minimum runtime) could be > created but I think it would be better to first get all of the tests pulled > into the project and make sure we’re getting consistent, stable results. > > Anthony > > > On Jun 16, 2015, at 1:57 PM, jun aoki wrote: > > > > I've made a root ticket and a few sub tasks > > https://issues.apache.org/jira/browse/GEODE-59 > > for the CI work. > > > > Anthony, I'm also interested in how to execute a subset of tests. Let me > > know! > > > > On Mon, Jun 15, 2015 at 10:25 PM, Roman Shaposhnik > > > wrote: > > > >> On Mon, Jun 15, 2015 at 7:04 PM, Anthony Baker > wrote: > >>> I typically use a smaller subset of tests while iterating on a change. > >>> Once I believe it is solid I’ll run the full set before I commit. > >> > >> Is there a gradle task to run that subset? > >> > >> Thanks, > >> Roman. > >> > > > > > > > > -- > > -jun > > -- -jun
Re: geode contribution process proposal
Thank you William, I've got the access! On Tue, Jun 16, 2015 at 2:01 PM, William Markito wrote: > Thanks Jun!! > > Permissions on JIRA should be fine now. > > On Tue, Jun 16, 2015 at 1:58 PM, jun aoki wrote: > > > Could anyone give me access to change Assignee so that I can assign the > CI > > task to myself? > > > > On Tue, Jun 16, 2015 at 1:57 PM, jun aoki wrote: > > > > > I've made a root ticket and a few sub tasks > > > https://issues.apache.org/jira/browse/GEODE-59 > > > for the CI work. > > > > > > Anthony, I'm also interested in how to execute a subset of tests. Let > me > > > know! > > > > > > On Mon, Jun 15, 2015 at 10:25 PM, Roman Shaposhnik < > ro...@shaposhnik.org > > > > > > wrote: > > > > > >> On Mon, Jun 15, 2015 at 7:04 PM, Anthony Baker > > wrote: > > >> > I typically use a smaller subset of tests while iterating on a > change. > > >> > Once I believe it is solid I’ll run the full set before I commit. > > >> > > >> Is there a gradle task to run that subset? > > >> > > >> Thanks, > > >> Roman. > > >> > > > > > > > > > > > > -- > > > -jun > > > > > > > > > > > -- > > -jun > > > > > > -- > > William Markito Oliveira > > -- For questions about Apache Geode, please write to > *dev@geode.incubator.apache.org > * > -- -jun
Re: geode contribution process proposal
What I’m speaking of is a development process where you 1) write some code 2) run some relevant tests 3) repeat until done You can do that with gradle as follows (just as examples): gradle :gemfire-core:test -Dtest.single=ArrayUtilsJUnitTest gradle :gemfire-core:test -Dtest.single=com/gemstone/gemfire/internal/util/ gradle :gemfire-core:integrationTest -DintegrationTest.single=DistributedSystemFactoryIntegrationJUnitTest An optimized CI subset (maximum coverage / minimum runtime) could be created but I think it would be better to first get all of the tests pulled into the project and make sure we’re getting consistent, stable results. Anthony > On Jun 16, 2015, at 1:57 PM, jun aoki wrote: > > I've made a root ticket and a few sub tasks > https://issues.apache.org/jira/browse/GEODE-59 > for the CI work. > > Anthony, I'm also interested in how to execute a subset of tests. Let me > know! > > On Mon, Jun 15, 2015 at 10:25 PM, Roman Shaposhnik > wrote: > >> On Mon, Jun 15, 2015 at 7:04 PM, Anthony Baker wrote: >>> I typically use a smaller subset of tests while iterating on a change. >>> Once I believe it is solid I’ll run the full set before I commit. >> >> Is there a gradle task to run that subset? >> >> Thanks, >> Roman. >> > > > > -- > -jun
Re: geode contribution process proposal
Thanks Jun!! Permissions on JIRA should be fine now. On Tue, Jun 16, 2015 at 1:58 PM, jun aoki wrote: > Could anyone give me access to change Assignee so that I can assign the CI > task to myself? > > On Tue, Jun 16, 2015 at 1:57 PM, jun aoki wrote: > > > I've made a root ticket and a few sub tasks > > https://issues.apache.org/jira/browse/GEODE-59 > > for the CI work. > > > > Anthony, I'm also interested in how to execute a subset of tests. Let me > > know! > > > > On Mon, Jun 15, 2015 at 10:25 PM, Roman Shaposhnik > > > wrote: > > > >> On Mon, Jun 15, 2015 at 7:04 PM, Anthony Baker > wrote: > >> > I typically use a smaller subset of tests while iterating on a change. > >> > Once I believe it is solid I’ll run the full set before I commit. > >> > >> Is there a gradle task to run that subset? > >> > >> Thanks, > >> Roman. > >> > > > > > > > > -- > > -jun > > > > > > -- > -jun > -- William Markito Oliveira -- For questions about Apache Geode, please write to *dev@geode.incubator.apache.org *
Re: geode contribution process proposal
I've made a root ticket and a few sub tasks https://issues.apache.org/jira/browse/GEODE-59 for the CI work. Anthony, I'm also interested in how to execute a subset of tests. Let me know! On Mon, Jun 15, 2015 at 10:25 PM, Roman Shaposhnik wrote: > On Mon, Jun 15, 2015 at 7:04 PM, Anthony Baker wrote: > > I typically use a smaller subset of tests while iterating on a change. > > Once I believe it is solid I’ll run the full set before I commit. > > Is there a gradle task to run that subset? > > Thanks, > Roman. > -- -jun
Re: geode contribution process proposal
Could anyone give me access to change Assignee so that I can assign the CI task to myself? On Tue, Jun 16, 2015 at 1:57 PM, jun aoki wrote: > I've made a root ticket and a few sub tasks > https://issues.apache.org/jira/browse/GEODE-59 > for the CI work. > > Anthony, I'm also interested in how to execute a subset of tests. Let me > know! > > On Mon, Jun 15, 2015 at 10:25 PM, Roman Shaposhnik > wrote: > >> On Mon, Jun 15, 2015 at 7:04 PM, Anthony Baker wrote: >> > I typically use a smaller subset of tests while iterating on a change. >> > Once I believe it is solid I’ll run the full set before I commit. >> >> Is there a gradle task to run that subset? >> >> Thanks, >> Roman. >> > > > > -- > -jun > -- -jun
Re: geode contribution process proposal
On Mon, Jun 15, 2015 at 7:04 PM, Anthony Baker wrote: > I typically use a smaller subset of tests while iterating on a change. > Once I believe it is solid I’ll run the full set before I commit. Is there a gradle task to run that subset? Thanks, Roman.
Re: geode contribution process proposal
I typically use a smaller subset of tests while iterating on a change. Once I believe it is solid I’ll run the full set before I commit. Anthony > On Jun 15, 2015, at 5:28 PM, Dan Smith wrote: > > I think getting reasonable coverage from the pure unit tests is good goal. > I know Mark has done some work in the past to get code coverage reports for > these different categories working with jenkins, maybe we can get that > integrated with the geode CI. I think a combination of these unit tests and > module specific categories could help some get the fast feedback as Ashvin > suggested. > > I also agree with Ashvin that the full test suite should be required for > commits. One of the problems with commit-then-test is that it becomes hard > to track down who broke the tests if there are a lot of changes going in. > > -Dan > > On Mon, Jun 15, 2015 at 5:05 PM, Ashvin A wrote: > >> Hi, >> >> We need a fast verification method for testing any changes, I agree. I >> think test categories/groups is a step in the correct direction. Then as a >> developer, I can quickly verify my changes at the module level. As Kirk >> said, we will invest in writing new tests and also identifying and fixing >> tests taking very long. >> >> However I think it is important to execute all tests before committing any >> changes. New developers will prefer shortcuts, but it is very difficult to >> weed out bugs later. I would not encourage reduced test set as a commit >> criteria. I fear that tests will be ignored once a reduced set is created. >> >> $.01 >> >> Thanks, >> Ashvin >> >> On Mon, Jun 15, 2015 at 4:39 PM, Kirk Lund wrote: >> >>> Hi Jun, >>> >>> Here's some info on Geode tests. >>> >>> 1) junit >>> >>> These are unit tests involving mocks as well as end-to-end functional >>> tests. These are currently marked with @Category(UnitTest.class) or >>> @Category(IntegrationTest.class). >>> >>> We need to encourage Geode developers to write a lot of more of the >>> UnitTest category tests. There's really not enough of these at this point >>> in time. There needs to be a strong commitment to writing these unit >> tests >>> and refactoring older code to make it easier or even possible for certain >>> classes. >>> >>> 2) dunit >>> >>> The majority of developer tests are "dunit" tests which extend >>> DistributedTestCase. These create and manipulate 6 JVMs. Think of these >> as >>> end-to-end functional tests for a cluster. Unfortunately it take hours to >>> execute them all and there are some reliability issues in these tests. >> I'm >>> working on replacing DistributedTestCase with a custom junit runner so >> that >>> the syntax of these tests can be updated to using JUnit 4 annotations and >>> rules. >>> >>> 3) hydra >>> >>> These are bigger QA-developed tests that run longer and may use many more >>> JVMs than a dunit. Moving hydra and these tests into Geode is further >> down >>> the road after moving the rest of the dunit tests. >>> >>> >>> On Mon, Jun 15, 2015 at 4:00 PM, jun aoki wrote: >>> Hi Dan, Unit testing is super important for open source projects, so I'm glad >>> some high quality testing is coming in to the project! Along with Roman's comment, it will be nice those tests ; 1. are unit level test where mocks are appropriately used and no >> running instances are required. (IMO, unit test should be lightweight, and more heavy integration tests should be done separately) 2. completes up to 30mins so that contributors can get a quicker >>> feedback. (we are hoping to get hundreds of contributors so be aware of this! :) >> ) As Roman suggested, should the unit test of GEODE-6 have basic >> acceptance tests (can be subset of the several-hour test set) and the open source >> CI should only tests the subset coverage? On Mon, Jun 15, 2015 at 10:07 AM, Roman Shaposhnik < >> ro...@shaposhnik.org wrote: > On Mon, Jun 15, 2015 at 9:42 AM, Dan Smith >> wrote: >> Welcome Jun! >> >> I like all of your suggestions! One thing to be aware of regarding >>> the CI >> jobs is that the test time is going to go up a lot once GEODE-6 is >> resolved. We'll be adding several hours of tests. That will make having a >> test patch CI job all that more valuable, but it also affects how >>> much >> resources need to be devoted to that. > > Does it just mean that we'd have to have a 'smoke test' testsuite? > > Thanks, > Roman. > -- -jun >>> >>
Re: geode contribution process proposal
I think getting reasonable coverage from the pure unit tests is good goal. I know Mark has done some work in the past to get code coverage reports for these different categories working with jenkins, maybe we can get that integrated with the geode CI. I think a combination of these unit tests and module specific categories could help some get the fast feedback as Ashvin suggested. I also agree with Ashvin that the full test suite should be required for commits. One of the problems with commit-then-test is that it becomes hard to track down who broke the tests if there are a lot of changes going in. -Dan On Mon, Jun 15, 2015 at 5:05 PM, Ashvin A wrote: > Hi, > > We need a fast verification method for testing any changes, I agree. I > think test categories/groups is a step in the correct direction. Then as a > developer, I can quickly verify my changes at the module level. As Kirk > said, we will invest in writing new tests and also identifying and fixing > tests taking very long. > > However I think it is important to execute all tests before committing any > changes. New developers will prefer shortcuts, but it is very difficult to > weed out bugs later. I would not encourage reduced test set as a commit > criteria. I fear that tests will be ignored once a reduced set is created. > > $.01 > > Thanks, > Ashvin > > On Mon, Jun 15, 2015 at 4:39 PM, Kirk Lund wrote: > > > Hi Jun, > > > > Here's some info on Geode tests. > > > > 1) junit > > > > These are unit tests involving mocks as well as end-to-end functional > > tests. These are currently marked with @Category(UnitTest.class) or > > @Category(IntegrationTest.class). > > > > We need to encourage Geode developers to write a lot of more of the > > UnitTest category tests. There's really not enough of these at this point > > in time. There needs to be a strong commitment to writing these unit > tests > > and refactoring older code to make it easier or even possible for certain > > classes. > > > > 2) dunit > > > > The majority of developer tests are "dunit" tests which extend > > DistributedTestCase. These create and manipulate 6 JVMs. Think of these > as > > end-to-end functional tests for a cluster. Unfortunately it take hours to > > execute them all and there are some reliability issues in these tests. > I'm > > working on replacing DistributedTestCase with a custom junit runner so > that > > the syntax of these tests can be updated to using JUnit 4 annotations and > > rules. > > > > 3) hydra > > > > These are bigger QA-developed tests that run longer and may use many more > > JVMs than a dunit. Moving hydra and these tests into Geode is further > down > > the road after moving the rest of the dunit tests. > > > > > > On Mon, Jun 15, 2015 at 4:00 PM, jun aoki wrote: > > > > > Hi Dan, > > > > > > Unit testing is super important for open source projects, so I'm glad > > some > > > high quality testing is coming in to the project! > > > > > > Along with Roman's comment, it will be nice those tests ; > > > 1. are unit level test where mocks are appropriately used and no > running > > > instances are required. (IMO, unit test should be lightweight, and more > > > heavy integration tests should be done separately) > > > 2. completes up to 30mins so that contributors can get a quicker > > feedback. > > > (we are hoping to get hundreds of contributors so be aware of this! :) > ) > > > > > > As Roman suggested, should the unit test of GEODE-6 have basic > acceptance > > > tests (can be subset of the several-hour test set) and the open source > CI > > > should only tests the subset coverage? > > > > > > > > > On Mon, Jun 15, 2015 at 10:07 AM, Roman Shaposhnik < > ro...@shaposhnik.org > > > > > > wrote: > > > > > > > On Mon, Jun 15, 2015 at 9:42 AM, Dan Smith > wrote: > > > > > Welcome Jun! > > > > > > > > > > I like all of your suggestions! One thing to be aware of regarding > > the > > > CI > > > > > jobs is that the test time is going to go up a lot once GEODE-6 is > > > > > resolved. We'll be adding several hours of tests. That will make > > > having a > > > > > test patch CI job all that more valuable, but it also affects how > > much > > > > > resources need to be devoted to that. > > > > > > > > Does it just mean that we'd have to have a 'smoke test' testsuite? > > > > > > > > Thanks, > > > > Roman. > > > > > > > > > > > > > > > > -- > > > -jun > > > > > >
Re: geode contribution process proposal
On Mon, Jun 15, 2015 at 5:05 PM, Ashvin A wrote: > Hi, > > We need a fast verification method for testing any changes, I agree. I > think test categories/groups is a step in the correct direction. Then as a > developer, I can quickly verify my changes at the module level. As Kirk > said, we will invest in writing new tests and also identifying and fixing > tests taking very long. > > However I think it is important to execute all tests before committing any > changes. New developers will prefer shortcuts, but it is very difficult to > weed out bugs later. I would not encourage reduced test set as a commit > criteria. I fear that tests will be ignored once a reduced set is created. Yup. And that's exactly why the pipeline that Jun built for Amabari has *two* independent jobs running tests. One for reporting back to the JIRA (via testpatch) and the other to test the health of the branch once the commit is made. Both are important. Thanks, Roman.
Re: geode contribution process proposal
Hi, We need a fast verification method for testing any changes, I agree. I think test categories/groups is a step in the correct direction. Then as a developer, I can quickly verify my changes at the module level. As Kirk said, we will invest in writing new tests and also identifying and fixing tests taking very long. However I think it is important to execute all tests before committing any changes. New developers will prefer shortcuts, but it is very difficult to weed out bugs later. I would not encourage reduced test set as a commit criteria. I fear that tests will be ignored once a reduced set is created. $.01 Thanks, Ashvin On Mon, Jun 15, 2015 at 4:39 PM, Kirk Lund wrote: > Hi Jun, > > Here's some info on Geode tests. > > 1) junit > > These are unit tests involving mocks as well as end-to-end functional > tests. These are currently marked with @Category(UnitTest.class) or > @Category(IntegrationTest.class). > > We need to encourage Geode developers to write a lot of more of the > UnitTest category tests. There's really not enough of these at this point > in time. There needs to be a strong commitment to writing these unit tests > and refactoring older code to make it easier or even possible for certain > classes. > > 2) dunit > > The majority of developer tests are "dunit" tests which extend > DistributedTestCase. These create and manipulate 6 JVMs. Think of these as > end-to-end functional tests for a cluster. Unfortunately it take hours to > execute them all and there are some reliability issues in these tests. I'm > working on replacing DistributedTestCase with a custom junit runner so that > the syntax of these tests can be updated to using JUnit 4 annotations and > rules. > > 3) hydra > > These are bigger QA-developed tests that run longer and may use many more > JVMs than a dunit. Moving hydra and these tests into Geode is further down > the road after moving the rest of the dunit tests. > > > On Mon, Jun 15, 2015 at 4:00 PM, jun aoki wrote: > > > Hi Dan, > > > > Unit testing is super important for open source projects, so I'm glad > some > > high quality testing is coming in to the project! > > > > Along with Roman's comment, it will be nice those tests ; > > 1. are unit level test where mocks are appropriately used and no running > > instances are required. (IMO, unit test should be lightweight, and more > > heavy integration tests should be done separately) > > 2. completes up to 30mins so that contributors can get a quicker > feedback. > > (we are hoping to get hundreds of contributors so be aware of this! :) ) > > > > As Roman suggested, should the unit test of GEODE-6 have basic acceptance > > tests (can be subset of the several-hour test set) and the open source CI > > should only tests the subset coverage? > > > > > > On Mon, Jun 15, 2015 at 10:07 AM, Roman Shaposhnik > > > wrote: > > > > > On Mon, Jun 15, 2015 at 9:42 AM, Dan Smith wrote: > > > > Welcome Jun! > > > > > > > > I like all of your suggestions! One thing to be aware of regarding > the > > CI > > > > jobs is that the test time is going to go up a lot once GEODE-6 is > > > > resolved. We'll be adding several hours of tests. That will make > > having a > > > > test patch CI job all that more valuable, but it also affects how > much > > > > resources need to be devoted to that. > > > > > > Does it just mean that we'd have to have a 'smoke test' testsuite? > > > > > > Thanks, > > > Roman. > > > > > > > > > > > -- > > -jun > > >
Re: geode contribution process proposal
Hi Jun, Here's some info on Geode tests. 1) junit These are unit tests involving mocks as well as end-to-end functional tests. These are currently marked with @Category(UnitTest.class) or @Category(IntegrationTest.class). We need to encourage Geode developers to write a lot of more of the UnitTest category tests. There's really not enough of these at this point in time. There needs to be a strong commitment to writing these unit tests and refactoring older code to make it easier or even possible for certain classes. 2) dunit The majority of developer tests are "dunit" tests which extend DistributedTestCase. These create and manipulate 6 JVMs. Think of these as end-to-end functional tests for a cluster. Unfortunately it take hours to execute them all and there are some reliability issues in these tests. I'm working on replacing DistributedTestCase with a custom junit runner so that the syntax of these tests can be updated to using JUnit 4 annotations and rules. 3) hydra These are bigger QA-developed tests that run longer and may use many more JVMs than a dunit. Moving hydra and these tests into Geode is further down the road after moving the rest of the dunit tests. On Mon, Jun 15, 2015 at 4:00 PM, jun aoki wrote: > Hi Dan, > > Unit testing is super important for open source projects, so I'm glad some > high quality testing is coming in to the project! > > Along with Roman's comment, it will be nice those tests ; > 1. are unit level test where mocks are appropriately used and no running > instances are required. (IMO, unit test should be lightweight, and more > heavy integration tests should be done separately) > 2. completes up to 30mins so that contributors can get a quicker feedback. > (we are hoping to get hundreds of contributors so be aware of this! :) ) > > As Roman suggested, should the unit test of GEODE-6 have basic acceptance > tests (can be subset of the several-hour test set) and the open source CI > should only tests the subset coverage? > > > On Mon, Jun 15, 2015 at 10:07 AM, Roman Shaposhnik > wrote: > > > On Mon, Jun 15, 2015 at 9:42 AM, Dan Smith wrote: > > > Welcome Jun! > > > > > > I like all of your suggestions! One thing to be aware of regarding the > CI > > > jobs is that the test time is going to go up a lot once GEODE-6 is > > > resolved. We'll be adding several hours of tests. That will make > having a > > > test patch CI job all that more valuable, but it also affects how much > > > resources need to be devoted to that. > > > > Does it just mean that we'd have to have a 'smoke test' testsuite? > > > > Thanks, > > Roman. > > > > > > -- > -jun >
Re: geode contribution process proposal
Hi Dan, Unit testing is super important for open source projects, so I'm glad some high quality testing is coming in to the project! Along with Roman's comment, it will be nice those tests ; 1. are unit level test where mocks are appropriately used and no running instances are required. (IMO, unit test should be lightweight, and more heavy integration tests should be done separately) 2. completes up to 30mins so that contributors can get a quicker feedback. (we are hoping to get hundreds of contributors so be aware of this! :) ) As Roman suggested, should the unit test of GEODE-6 have basic acceptance tests (can be subset of the several-hour test set) and the open source CI should only tests the subset coverage? On Mon, Jun 15, 2015 at 10:07 AM, Roman Shaposhnik wrote: > On Mon, Jun 15, 2015 at 9:42 AM, Dan Smith wrote: > > Welcome Jun! > > > > I like all of your suggestions! One thing to be aware of regarding the CI > > jobs is that the test time is going to go up a lot once GEODE-6 is > > resolved. We'll be adding several hours of tests. That will make having a > > test patch CI job all that more valuable, but it also affects how much > > resources need to be devoted to that. > > Does it just mean that we'd have to have a 'smoke test' testsuite? > > Thanks, > Roman. > -- -jun
Re: geode contribution process proposal
On Mon, Jun 15, 2015 at 9:42 AM, Dan Smith wrote: > Welcome Jun! > > I like all of your suggestions! One thing to be aware of regarding the CI > jobs is that the test time is going to go up a lot once GEODE-6 is > resolved. We'll be adding several hours of tests. That will make having a > test patch CI job all that more valuable, but it also affects how much > resources need to be devoted to that. Does it just mean that we'd have to have a 'smoke test' testsuite? Thanks, Roman.
Re: geode contribution process proposal
Welcome Jun! I like all of your suggestions! One thing to be aware of regarding the CI jobs is that the test time is going to go up a lot once GEODE-6 is resolved. We'll be adding several hours of tests. That will make having a test patch CI job all that more valuable, but it also affects how much resources need to be devoted to that. I also really like how clear and concise the Ambari contribution page is. We should work on merging some of that with these wiki pages: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57903992 https://cwiki.apache.org/confluence/display/GEODE/Criteria+for+Code+Submissions -Dan > > On Mon, Jun 15, 2015 at 8:38 AM, Bruce Schuchardt > wrote: > >> +1 >> >> >> Le 6/12/2015 6:36 PM, jun aoki a écrit : >> >>> Hi Geode community >>> >>> My name is Jun Aoki and I work for Pivotal's Ambari project, and am super >>> excited to contribute to Geode! >>> >>> I'd like to propose a few things about contribution process. >>> >>> The Geode community should have a clear cut process to open up to anybody >>> who are interested in contributing to Geode. >>> e.g. Apache Ambari community has adopted a contribution process >>> https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute >>> Ambari's workflow >>> >>> https://docs.google.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit >>> >>> >>> >>> I am listing a few tasks that can be Jira tickets of Geode. >>> - test-patch CI job to make sure submitted patches to Geode jira has >>> minimum quality (Apache RAT pass, being able to compile, unit test added, >>> etc) >>> - commit CI job to make sure master branch passes the unit test upon >>> patch >>> commits. >>> - Geode build environment within Docker to enable anybody and any OS and >>> any environment can build Geode as long as there is Docker. >>> >>> e.g. jobs serve for ambari >>> https://builds.apache.org/view/A-D/view/Ambari/ >>> >>> >>> Please let me know if my proposals are good for the Geode community, >>> then I >>> will make tickets and will work on them. >>> >>> - jun >>> >>> >> >
Re: geode contribution process proposal
+1 Le 6/12/2015 6:36 PM, jun aoki a écrit : Hi Geode community My name is Jun Aoki and I work for Pivotal's Ambari project, and am super excited to contribute to Geode! I'd like to propose a few things about contribution process. The Geode community should have a clear cut process to open up to anybody who are interested in contributing to Geode. e.g. Apache Ambari community has adopted a contribution process https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute Ambari's workflow https://docs.google.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit I am listing a few tasks that can be Jira tickets of Geode. - test-patch CI job to make sure submitted patches to Geode jira has minimum quality (Apache RAT pass, being able to compile, unit test added, etc) - commit CI job to make sure master branch passes the unit test upon patch commits. - Geode build environment within Docker to enable anybody and any OS and any environment can build Geode as long as there is Docker. e.g. jobs serve for ambari https://builds.apache.org/view/A-D/view/Ambari/ Please let me know if my proposals are good for the Geode community, then I will make tickets and will work on them. - jun
Re: geode contribution process proposal
Welcome Jun. Suds Sent from my iPhone > On Jun 13, 2015, at 9:16 AM, Kirk Lund wrote: > > +1 > > Welcome Jun! > >> On Friday, June 12, 2015, jun aoki wrote: >> >> Hi Geode community >> >> My name is Jun Aoki and I work for Pivotal's Ambari project, and am super >> excited to contribute to Geode! >> >> I'd like to propose a few things about contribution process. >> >> The Geode community should have a clear cut process to open up to anybody >> who are interested in contributing to Geode. >> e.g. Apache Ambari community has adopted a contribution process >> https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute >> Ambari's workflow >> >> https://docs.google.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit >> >> >> >> I am listing a few tasks that can be Jira tickets of Geode. >> - test-patch CI job to make sure submitted patches to Geode jira has >> minimum quality (Apache RAT pass, being able to compile, unit test added, >> etc) >> - commit CI job to make sure master branch passes the unit test upon patch >> commits. >> - Geode build environment within Docker to enable anybody and any OS and >> any environment can build Geode as long as there is Docker. >> >> e.g. jobs serve for ambari >> https://builds.apache.org/view/A-D/view/Ambari/ >> >> >> Please let me know if my proposals are good for the Geode community, then I >> will make tickets and will work on them. >> >> - jun >>
Re: geode contribution process proposal
+1 Welcome Jun! On Friday, June 12, 2015, jun aoki wrote: > Hi Geode community > > My name is Jun Aoki and I work for Pivotal's Ambari project, and am super > excited to contribute to Geode! > > I'd like to propose a few things about contribution process. > > The Geode community should have a clear cut process to open up to anybody > who are interested in contributing to Geode. > e.g. Apache Ambari community has adopted a contribution process > https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute > Ambari's workflow > > https://docs.google.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit > > > > I am listing a few tasks that can be Jira tickets of Geode. > - test-patch CI job to make sure submitted patches to Geode jira has > minimum quality (Apache RAT pass, being able to compile, unit test added, > etc) > - commit CI job to make sure master branch passes the unit test upon patch > commits. > - Geode build environment within Docker to enable anybody and any OS and > any environment can build Geode as long as there is Docker. > > e.g. jobs serve for ambari > https://builds.apache.org/view/A-D/view/Ambari/ > > > Please let me know if my proposals are good for the Geode community, then I > will make tickets and will work on them. > > - jun >
Re: geode contribution process proposal
Welcome to geode Jun. I like your ideas. Suds Sent from my iPhone > On Jun 12, 2015, at 6:36 PM, jun aoki wrote: > > Hi Geode community > > My name is Jun Aoki and I work for Pivotal's Ambari project, and am super > excited to contribute to Geode! > > I'd like to propose a few things about contribution process. > > The Geode community should have a clear cut process to open up to anybody > who are interested in contributing to Geode. > e.g. Apache Ambari community has adopted a contribution process > https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute > Ambari's workflow > https://docs.google.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit > > > > I am listing a few tasks that can be Jira tickets of Geode. > - test-patch CI job to make sure submitted patches to Geode jira has > minimum quality (Apache RAT pass, being able to compile, unit test added, > etc) > - commit CI job to make sure master branch passes the unit test upon patch > commits. > - Geode build environment within Docker to enable anybody and any OS and > any environment can build Geode as long as there is Docker. > > e.g. jobs serve for ambari > https://builds.apache.org/view/A-D/view/Ambari/ > > > Please let me know if my proposals are good for the Geode community, then I > will make tickets and will work on them. > > - jun
Re: geode contribution process proposal
+1 Taking a proven process is a great idea. Thanks On Fri, 12 Jun 2015 at 22:25 William Markito wrote: > ++1 > > These are all pretty awesome ideas and I'd say a must have for a sane and > healthy build/release/community process. > > Thanks a lot. > > > On Jun 12, 2015, at 6:36 PM, jun aoki wrote: > > > > Hi Geode community > > > > My name is Jun Aoki and I work for Pivotal's Ambari project, and am > super excited to contribute to Geode! > > > > I'd like to propose a few things about contribution process. > > > > The Geode community should have a clear cut process to open up to > anybody who are interested in contributing to Geode. > > e.g. Apache Ambari community has adopted a contribution process > > https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute > > Ambari's workflow > > > https://docs.google.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit > > > > > > > > I am listing a few tasks that can be Jira tickets of Geode. > > - test-patch CI job to make sure submitted patches to Geode jira has > minimum quality (Apache RAT pass, being able to compile, unit test added, > etc) > > - commit CI job to make sure master branch passes the unit test upon > patch commits. > > - Geode build environment within Docker to enable anybody and any OS and > any environment can build Geode as long as there is Docker. > > > > e.g. jobs serve for ambari > > https://builds.apache.org/view/A-D/view/Ambari/ > > > > > > Please let me know if my proposals are good for the Geode community, > then I will make tickets and will work on them. > > > > - jun > > >
Re: geode contribution process proposal
++1 These are all pretty awesome ideas and I'd say a must have for a sane and healthy build/release/community process. Thanks a lot. > On Jun 12, 2015, at 6:36 PM, jun aoki wrote: > > Hi Geode community > > My name is Jun Aoki and I work for Pivotal's Ambari project, and am super > excited to contribute to Geode! > > I'd like to propose a few things about contribution process. > > The Geode community should have a clear cut process to open up to anybody who > are interested in contributing to Geode. > e.g. Apache Ambari community has adopted a contribution process > https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute > Ambari's workflow > https://docs.google.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit > > > > I am listing a few tasks that can be Jira tickets of Geode. > - test-patch CI job to make sure submitted patches to Geode jira has minimum > quality (Apache RAT pass, being able to compile, unit test added, etc) > - commit CI job to make sure master branch passes the unit test upon patch > commits. > - Geode build environment within Docker to enable anybody and any OS and any > environment can build Geode as long as there is Docker. > > e.g. jobs serve for ambari > https://builds.apache.org/view/A-D/view/Ambari/ > > > Please let me know if my proposals are good for the Geode community, then I > will make tickets and will work on them. > > - jun >
geode contribution process proposal
Hi Geode community My name is Jun Aoki and I work for Pivotal's Ambari project, and am super excited to contribute to Geode! I'd like to propose a few things about contribution process. The Geode community should have a clear cut process to open up to anybody who are interested in contributing to Geode. e.g. Apache Ambari community has adopted a contribution process https://cwiki.apache.org/confluence/display/AMBARI/How+to+Contribute Ambari's workflow https://docs.google.com/document/d/1hz7qjGKkNeckMibEs67ZmAa2kxjie0zkG6H_IiC2RgA/edit I am listing a few tasks that can be Jira tickets of Geode. - test-patch CI job to make sure submitted patches to Geode jira has minimum quality (Apache RAT pass, being able to compile, unit test added, etc) - commit CI job to make sure master branch passes the unit test upon patch commits. - Geode build environment within Docker to enable anybody and any OS and any environment can build Geode as long as there is Docker. e.g. jobs serve for ambari https://builds.apache.org/view/A-D/view/Ambari/ Please let me know if my proposals are good for the Geode community, then I will make tickets and will work on them. - jun
