Re: Assigning JIRA fix version

This would be true in general unless a JIRA has been resolved but the feature is still in a branch. Long-running branches and sub-task JIRAs would probably exhibit this behavior. I'll check JIRA tomorrow to see if I can find any counter examples. Thanks, Nitin _

Assigning JIRA fix version

Looking at the JIRA roadmap [1] [2] we have: 12 issues fixed in 1.0.0-alpha1 78 issues fixed in 1.0.0-incubating 276 issues with empty Fix version I suspect we want all the resolved issues to show up in the changelog for 1.0.0-alpha1. This means we need to correct the Fix version field. Make s

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #182 was SUCCESSFUL (with 1222 tests)

--- Spring Data GemFire > Nightly-ApacheGeode > #182 was successful. --- Scheduled 1226 tests in total. https://build.spring.io/browse/SGF-NAG-182/ -- This

Re: Ready for release candidate?

Let me share what I typically see in high velocity ASF projects (Hadoop, etc.) We *may* be talking about the same thing though ;-) On Wed, Jan 6, 2016 at 8:27 PM, Anthony Baker wrote: > What I’m thinking (but please correct me): > > 1) Create release branch > 2) Do stuff on release branch until

Re: Source distribution

On Wed, Jan 6, 2016 at 8:17 PM, Anthony Baker wrote: > Yep. We can exclude those dirs from the source distribution if needed. Great! > Are we using Jenkins to create the release build? That's actually up to you guys. It is totally possible for a RM to just create it by hand and checkin into th

Re: Ready for release candidate?

What I’m thinking (but please correct me): 1) Create release branch 2) Do stuff on release branch until done 3) Merge release to develop and master 4) Tag master http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ Anthony > On Jan 6, 2016, at 7:14 PM, Justin Erenkrantz wrote: > >

Re: Source distribution

Yep. We can exclude those dirs from the source distribution if needed. Are we using Jenkins to create the release build? Anthony > On Jan 6, 2016, at 8:06 PM, Roman Shaposhnik wrote: > > On Wed, Jan 6, 2016 at 8:04 PM, Anthony Baker wrote: >> Those dirs only get created on a Jenkins build si

Re: Source distribution

On Wed, Jan 6, 2016 at 8:04 PM, Anthony Baker wrote: > Those dirs only get created on a Jenkins build since Jenkins sets > GRADLE_HOME_DIR to the workspace (I know this has been fixed in > recent Gradle plugins but I can’t tell which version of the plugin ASF is > using). So I guess the issue he

Re: Source distribution

Those dirs only get created on a Jenkins build since Jenkins sets GRADLE_HOME_DIR to the workspace (I know this has been fixed in recent Gradle plugins but I can’t tell which version of the plugin ASF is using). Anthony > On Jan 6, 2016, at 7:20 PM, Roman Shaposhnik wrote: > > On Wed, Jan 6,

Re: Source distribution

On Thu, Jan 7, 2016 at 3:20 AM, Roman Shaposhnik wrote: > On Wed, Jan 6, 2016 at 4:01 PM, Niall Pemberton > wrote: > > On Mon, Jan 4, 2016 at 10:43 PM, Nitin Lamba wrote: > > > >> You're right Anthony - my bad. > >> > >> I did download the archive but accidentally opened the older tar.gz from >

Re: Source distribution

On Wed, Jan 6, 2016 at 4:01 PM, Niall Pemberton wrote: > On Mon, Jan 4, 2016 at 10:43 PM, Nitin Lamba wrote: > >> You're right Anthony - my bad. >> >> I did download the archive but accidentally opened the older tar.gz from >> April, 2015: >> geode-1.0.0.0-SNAPSHOT.src.tar.gz >> (the original sou

Re: Ready for release candidate?

Isn't the more typical workflow to branch the release from develop, do the stabilization there, then create the tag. If needed, you would merge from develop to the release branch. I am not sure you would merge back from the release branch back to develop and then cut a new tag. Perhaps I am miss

Re: January 2016 Report

Looks great! I've signed off. Also, I plan to start looking into GEODE-610 this week. Thanks, Roman. On Wed, Jan 6, 2016 at 6:18 PM, William Markito wrote: > Incubator wiki updated, report delivered. > https://wiki.apache.org/incubator/January2016 > > On Wed, Jan 6, 2016 at 2:24 PM, William Mar

Re: January 2016 Report

Incubator wiki updated, report delivered. https://wiki.apache.org/incubator/January2016 On Wed, Jan 6, 2016 at 2:24 PM, William Markito wrote: > Thanks for the feedback Niall. I'm editing that and adding it to the > Incubator wiki > > On Wed, Jan 6, 2016 at 2:09 PM, Niall Pemberton > wrote: >

Re: [DISCUSS] Generalized criteria for becoming an Apache Geode Committer

After the discussion on private@geode, I personally came away liking this criteria the best - A person should become a committer at the point at which it is obvious that I'd rather have them check directly into SCM than merge the patch myself based on the contributions I've seen from them so far.

Re: Source distribution

Yes, makes sense to merge GEODE-610 before the release branch. Thanks! @William - sure, whatever we decide; I'm easy :) - Nitin From: William Markito Sent: Wednesday, January 6, 2016 5:26 PM To: dev Subject: Re: Source distribution +1 for keeping incubat

releaseType?

I was looking in our gradle.properties file: versionNumber = 1.0.0-incubating releaseType = SNAPSHOT I’m not sure what the releaseType should be for a non-SNAPSHOT release :-) Given that version is set to: version = versionNumber + '-' + releaseType I'm wondering if we

Re: [DISCUSS] Generalized criteria for becoming an Apache Geode Committer

Just for measure - what does it take to show up as a top contributor for wiki changes in Apache Geode in the last 30 days? http://projects.bitergia.com/apache-geode/browser/confluence.html 1 change. It might sound like I'm asking for a lot, but its not. Just needs to be more comprehensive, not

[DISCUSS] Generalized criteria for becoming an Apache Geode Committer

With the occasion of a request to vote in our first additional committer, its become clear that we don't have clear criteria for when someone should become a committer. The steps for becoming a committer are listed here in the wiki: https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+comm

Re: Source distribution

+1 for keeping incubating as part of the version since it's required during incubation. For the name of the branch, we're keeping it tied to the version names, so if the version has it, so the branch On Wed, Jan 6, 2016 at 5:09 PM, Anthony Baker wrote: > Also, I should merge the initial ch

Re: Source distribution

Also, I should merge the initial changes on feature/GEODE-610 to develop before creating the release branch. There was an earlier thread requesting feedback on that work [1]. Anthony [1] http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201601.mbox/%3c7889921b-97eb-4ecd-8f39-9fbdfe

Re: Review Request 42008: GEODE-701: fix double free in unit test

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/42008/#review113157 --- Ship it! Ship It! - Scott Jewell On Jan. 7, 2016, 1:03 a.m., Da

Re: Source distribution

In my mind, git release branch is internal so we can pick a naming convention and stick to it. Only suggestion there is to drop 'incubating'. If there are divergent views, suggest we call a quick vote and take action by Friday. Thoughts? Also, the artifacts/ contents will be reviewed by mentors

Review Request 42008: GEODE-701: fix double free in unit test

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/42008/ --- Review request for geode, Scott Jewell and Swapnil Bawaskar. Bugs: GEODE-701

Re: Source distribution

I can create the release branch if we’re in agreement on the name: release/1.0.0-incubating-alpha1 I’ve done an initial round of work on GEODE-610. I think we need input and review from our mentors in order to mark it as resolved. If you have other suggestions for how to continue that please

Re: Source distribution

The DISCLAIMER language looks accurate from [1]! Anthony, Who can help create a release branch in git? I certainly don't have the git karma to do it. Also, we can merge LICENSE, NOTICE and DISCLAIMER directly into this release branch whenever it is ready? Also, do you know if anyone is workin

Re: Source distribution

Is there a good reason to use the Jenkins artifacts? Seems like it would be preferable to create artifacts from a clean working dir (or maybe fix Jenkins to put temporary files elsewhere). The DISCLAIMER should look like this I believe: Apache Geode is an effort undergoing incubation at The Ap

Re: Ready for release candidate?

Sorry, to be more specific: After release work is complete, we then merge it on master and develop again, tag it and delete the release branch. On Wed, Jan 6, 2016 at 4:02 PM, William Markito wrote: > That's not what I understood. > > My understanding is that we would call for the release and

Re: Ready for release candidate?

That's not what I understood. My understanding is that we would call for the release and create a branch from develop and do the remaining work for the release there AND let develop continue it's flow. After release work is complete, we then merge it on master, tag it and delete the release branc

Re: Source distribution

On Mon, Jan 4, 2016 at 10:43 PM, Nitin Lamba wrote: > You're right Anthony - my bad. > > I did download the archive but accidentally opened the older tar.gz from > April, 2015: > geode-1.0.0.0-SNAPSHOT.src.tar.gz > (the original source contributed to Apache). > > All's good now. Yes, did notice f

Re: Ready for release candidate?

So to be clear, even though we are creating a release branch, nothing should be checked in to develop that is not intended for the 1.0.0 release. I'm fine with that. It does mean as we get close to 1.0.0 we will need to "lock down" develop so we don't check things in that might break the 1.0.0 rele

Re: Ready for release candidate?

+1 On Wed, Jan 6, 2016 at 3:38 PM, Anthony Baker wrote: > I was expecting we would always create release branches from develop. > > > > On Jan 6, 2016, at 3:35 PM, Dan Smith wrote: > > > >> > >> I believe we are farther away from the actual '1.0.0' release, so it > does > >> not make sense to h

Re: Ready for release candidate?

I was expecting we would always create release branches from develop. > On Jan 6, 2016, at 3:35 PM, Dan Smith wrote: > >> >> I believe we are farther away from the actual '1.0.0' release, so it does >> not make sense to have the long standing release branch. >> > > Maybe I'm confused about w

Re: Ready for release candidate?

> > I believe we are farther away from the actual '1.0.0' release, so it does > not make sense to have the long standing release branch. > Maybe I'm confused about where the next alpha or beta branch will be created from. Are you thinking it will be created from the release-1.0.0-alpha branch, or

Re: Ready for release candidate?

My thought is that the release branch should be short-lived (in this case hopefully < 2 weeks). I think it should match the version (which would be 1.0.0-incubating-alpha1). Then we can have subsequent release branches for 1.0.0-incubating-alpha2, etc. I would say that even though alpha1, alp

[GitHub] incubator-geode pull request: GEODE-712: Move junit asserts out of...

Github user dschneider-pivotal commented on the pull request: https://github.com/apache/incubator-geode/pull/68#issuecomment-169497119 This change looks good and the modified unit test still passes --- If your project is set up for it, you can reply to this email and have your reply a

[GitHub] incubator-geode pull request: GEODE-712: Move junit asserts out of...

Github user asfgit closed the pull request at: https://github.com/apache/incubator-geode/pull/68 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature

Re: Ready for release candidate?

I like Dan's idea thought not sure if this would comply with git flow process or interpreting 'releases' more strictly. Is it possible to have one git branch for the release version (1.0.0) but use tags for different 'stages' alpha1, alpha2, RC, etc? In my mind, alpha1, alpha2, beta, RC are par

Re: Ready for release candidate?

I believe we are farther away from the actual '1.0.0' release, so it does not make sense to have the long standing release branch. Since '1.0.0-ALPHA' is the release name, I would expect the branch name to match. This goes for any 'beta', M1, M2, Mx, then final '1.0.0' release branch. Those are my

Re: Ready for release candidate?

One question on the name of the release branch. Shouldn't we be calling it release/1.0.0-incubating and just tag alpha versions off of that branch? Why have multiple branches for the same release? -Dan On Wed, Jan 6, 2016 at 2:58 PM, Anthony Baker wrote: > I suggest that we’re pretty much ready

Ready for release candidate?

I suggest that we’re pretty much ready to begin creating the alpha1 release. I think the first step in the process is to create a release branch (release/1.0.0-incubating-alpha1) and publish it. From there we can finalize any further changes needed (like updates for GEODE-610, gradle.propertie

Re: January 2016 Report

Thanks for the feedback Niall. I'm editing that and adding it to the Incubator wiki On Wed, Jan 6, 2016 at 2:09 PM, Niall Pemberton wrote: > I comment I have is that "GEODE-610" wont mean anything to the IPMC or > board, so I would suggest rephrasing this to something like "The only item > pend

Re: Review Request 41836: GEODE-719: Add error logs while cache.xml processing

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41836/#review113145 --- gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/Gem

Re: January 2016 Report

I comment I have is that "GEODE-610" wont mean anything to the IPMC or board, so I would suggest rephrasing this to something like "The only item pending for the Alpha-1 release is completion of the LICENSE and NOTICE file review (GEODE-610)". Niall On Wed, Jan 6, 2016 at 3:34 AM, William Markit

[GitHub] incubator-geode pull request: GEODE-712: Move junit asserts out of...

GitHub user gemzdude opened a pull request: https://github.com/apache/incubator-geode/pull/68 GEODE-712: Move junit asserts out of finally block This change prevents the assert in the finally block from "swallowing" the thrown exception. The next time this test fails, we can reo

Review Request 41991: GEODE-245 QueryMonitor cancellation is being ignored by query using CompactRangeIndex

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41991/ --- Review request for geode, anilkumar gingade, Bruce Schuchardt, Hitesh Khamesra,

Re: Review Request 41992: Upgrade log4j2 from 2.1 to 2.5

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41992/#review113137 --- Ship it! Ship It! - Jens Deppe On Jan. 6, 2016, 7:58 p.m., Kirk

Re: Review Request 41992: Upgrade log4j2 from 2.1 to 2.5

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41992/#review113133 --- Ship it! Ship It! - Jinmei Liao On Jan. 6, 2016, 7:58 p.m., Kir

Re: January 2016 Report

Resending now just with the description from the website as suggested by Dave. - - Geode Apache Geode is a distributed, in-memory database with strong data consistency, built to support transactional applications wit

Review Request 41992: Upgrade log4j2 from 2.1 to 2.5

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41992/ --- Review request for geode, Jens Deppe and Jinmei Liao. Bugs: GEODE-374 https

[GitHub] incubator-geode pull request: GEODE-401: upgrade log4j from 2.1 to...

Github user kirklund commented on the pull request: https://github.com/apache/incubator-geode/pull/67#issuecomment-169412679 I'll go ahead and pull in these changes to test and commit. --- If your project is set up for it, you can reply to this email and have your reply appear on Git

Re: Propose new committer - Jinmei Liao

On top of great advice from Niall let me remind everybody of two things: 1. Our private@geode subscription stands at 29 right now, compared to many more initial committers 2. If you happen to be on the list of initial committers make sure to subscribe to the private mailing list by

RE: Propose new committer - Jinmei Liao

Hi, The best list of the type of things to disucss on private lists is here: http://www.apache.org/dev/pmc.html#mailing-list-naming-policy Some info on private list etiquette: http://www.apache.org/foundation/how-it-works.html#confidential Niall -Original Message- From: Kirk Lund

Re: Propose new committer - Jinmei Liao

Is there a FAQ somewhere that explains what all private@geode is for? I've wondered what its purpose is several times now. -Kirk On Wed, Jan 6, 2016 at 9:51 AM, Gregory Chase wrote: > Please make specific requests about individuals to > priv...@geode.incubator.apache.org - one of the main reas

Re: Review Request 41802: GEODE-14: Integration of GemFire Session Replication and Hibernate modules

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41802/#review113095 --- Ship it! Ship It! - Dan Smith On Jan. 6, 2016, 4:25 p.m., Jens

Re: Propose new committer - Jinmei Liao

Please make specific requests about individuals to priv...@geode.incubator.apache.org - one of the main reasons we have a private mail group. Thanks :) -Greg On Wed, Jan 6, 2016 at 9:50 AM, Jens Deppe wrote: > Hello, > > Jinmei Liao has been working on Geode since November and has consistently

Propose new committer - Jinmei Liao

Hello, Jinmei Liao has been working on Geode since November and has consistently provided pull requests as a contributor since then (currently 14 pull requests). I'd like to propose that her status be upgraded to committer. Thanks --Jens

Re: Review for GemFire Session Replication and Hibernate Modules

Probably once we decide we are ready to begin the release process we should create a release/XXX branch following the gitflow process. Anthony > On Jan 6, 2016, at 9:02 AM, Jens Deppe wrote: > > I can merge any time. I'm OK to wait (or not) as needed. > > --Jens > > On Wed, Jan 6, 2016 at 8:

Re: January 2016 Report

+1. Thanks William! --Mark On Wed, Jan 6, 2016 at 9:26 AM, Dan Smith wrote: > +1 Looks good to me! > > -Dan > > On Wed, Jan 6, 2016 at 9:18 AM, Kirk Lund wrote: > > > +1 looks good. Thanks William! > > > > > > On Wed, Jan 6, 2016 at 8:57 AM, Anthony Baker wrote: > > > > > Thanks William, look

Re: January 2016 Report

+1 Looks good to me! -Dan On Wed, Jan 6, 2016 at 9:18 AM, Kirk Lund wrote: > +1 looks good. Thanks William! > > > On Wed, Jan 6, 2016 at 8:57 AM, Anthony Baker wrote: > > > Thanks William, looks good! > > > > > On Jan 6, 2016, at 4:43 AM, Justin Erenkrantz > > wrote: > > > > > > Looks good to

[GitHub] incubator-geode pull request: GEODE-574: for --ciphers and --proto...

Github user asfgit closed the pull request at: https://github.com/apache/incubator-geode/pull/65 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature

Re: January 2016 Report

+1 looks good. Thanks William! On Wed, Jan 6, 2016 at 8:57 AM, Anthony Baker wrote: > Thanks William, looks good! > > > On Jan 6, 2016, at 4:43 AM, Justin Erenkrantz > wrote: > > > > Looks good to me. I do like the description on the site better...YMMV. > > > > When you add it to the Wiki, pl

Re: Review Request 41802: GEODE-14: Integration of GemFire Session Replication and Hibernate modules

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41802/#review113088 --- Ship it! As long as RAT runs successfully and Pivotal specific sup

Re: Review Request 41802: GEODE-14: Integration of GemFire Session Replication and Hibernate modules

> On Jan. 6, 2016, 12:51 a.m., Mark Bretl wrote: > > All the shell/bat scripts need to be updated for the jar file changes. > > > > Build changes look good, however, since all the subprojects are going be > > added, that means every Geode build will build the modules? Not sure if we > > want t

[GitHub] incubator-geode pull request: GEODE-401: upgrade log4j from 2.1 to...

GitHub user jinmeiliao opened a pull request: https://github.com/apache/incubator-geode/pull/67 GEODE-401: upgrade log4j from 2.1 to 2.5. Remove our own configuratio… …n watcher since log4j now has an almost the same implementation. You can merge this pull request into a Git rep

Re: Review for GemFire Session Replication and Hibernate Modules

I can merge any time. I'm OK to wait (or not) as needed. --Jens On Wed, Jan 6, 2016 at 8:55 AM, Anthony Baker wrote: > How close are you to merging? I think we’re probably *really* close to > being ready for an alpha1 release and it would be nice not to have to redo > all the IP work before th

Re: January 2016 Report

Thanks William, looks good! > On Jan 6, 2016, at 4:43 AM, Justin Erenkrantz wrote: > > Looks good to me. I do like the description on the site better...YMMV. > > When you add it to the Wiki, please feel free to mark I have signed off. > > Cheers. -- justin > > On Tue, Jan 5, 2016 at 10:34 P

Re: Review for GemFire Session Replication and Hibernate Modules

How close are you to merging? I think we’re probably *really* close to being ready for an alpha1 release and it would be nice not to have to redo all the IP work before then. Anthony > On Jan 5, 2016, at 6:15 PM, Jens Deppe wrote: > > Yes, that's right. All of the tests are categorized appr

Re: Review Request 41802: GEODE-14: Integration of GemFire Session Replication and Hibernate modules

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41802/ --- (Updated Jan. 6, 2016, 4:25 p.m.) Review request for geode. Changes ---

Re: Review Request 41802: GEODE-14: Integration of GemFire Session Replication and Hibernate modules

> On Jan. 6, 2016, 12:51 a.m., Mark Bretl wrote: > > All the shell/bat scripts need to be updated for the jar file changes. > > > > Build changes look good, however, since all the subprojects are going be > > added, that means every Geode build will build the modules? Not sure if we > > want t

Re: January 2016 Report

Looks good to me. I do like the description on the site better...YMMV. When you add it to the Wiki, please feel free to mark I have signed off. Cheers. -- justin On Tue, Jan 5, 2016 at 10:34 PM, William Markito wrote: > Hi folks, please review the following report to be posted about Geode > >

Build failed in Jenkins: Geode-nightly #337

See Changes: [sbawaskar] GEODE-719: Add error logs while cache.xml processing [jdeppe] GEODE-718 GEODE-725: Ensure that test resources are cleaned up from [bschuchardt] GEODE-430 CI failure -- [..