Re: [Discuss] Adding dtest to project
I love DTest I think it is a great thing in the tool belt. One thing that I want to point out, nosettests and dtests are black-box type testing. You can not step or trace these things very easily. My dream would be if cassandra was re-entrant and it was possible to run a 3 node cluster in one JVM and set a break point. I think you could prove out many things much easier and faster. On Thu, Sep 22, 2016 at 11:44 PM, Nate McCall wrote: > [Moved from PMC as there is nothing really private involved] > > DataStax has graciously offered to contribute cassandra-dtest [0] to > the project. > > There were, however, two issues noted by Jonathan when he presented > the offer to the PMC: > > 1. dtest mixes tests for many cassandra versions together in a single > project. So having it live in the main cassandra repo, versioned by > cassandra release, doesn't really make sense. Is Infra able to create a > second repo for this, or is the "one project, one repo" mapping fixed? > > 2. DataStax did not require a CLA to contribute to dtest, so the non-DS > contributors to dtest would need to be contacted for their permission to > assign copyright to the ASF. Is the PMC willing to tackle this? > > In a brief discussion, it was deduced that #1 can be addressed by > adding apache/cassandra-dtest to the ASF repo (the example of > apache/aurora and apache/aurora-packaging was given to justify this). > > #2 will be harder as it will require tracking a few people people down > to sign ASF CLAs. > > Before we really put effort into this, I wanted to open the discussion > up about whether we are willing to take on the development of this in > the project. Thoughts? > > -Nate > > > [0] https://github.com/riptano/cassandra-dtest >
Re: [Discuss] Adding dtest to project
I think we should continue to use Dtest. Besides the improvement which Edward talked about, we should see how we can have an option in ccm to also support multiple machines if available. On Fri, Sep 23, 2016 at 7:32 AM, Edward Capriolo wrote: > I love DTest I think it is a great thing in the tool belt. One thing that I > want to point out, nosettests and dtests are black-box type testing. You > can not step or trace these things very easily. > > My dream would be if cassandra was re-entrant and it was possible to run a > 3 node cluster in one JVM and set a break point. I think you could prove > out many things much easier and faster. > > On Thu, Sep 22, 2016 at 11:44 PM, Nate McCall wrote: > > > [Moved from PMC as there is nothing really private involved] > > > > DataStax has graciously offered to contribute cassandra-dtest [0] to > > the project. > > > > There were, however, two issues noted by Jonathan when he presented > > the offer to the PMC: > > > > 1. dtest mixes tests for many cassandra versions together in a single > > project. So having it live in the main cassandra repo, versioned by > > cassandra release, doesn't really make sense. Is Infra able to create a > > second repo for this, or is the "one project, one repo" mapping fixed? > > > > 2. DataStax did not require a CLA to contribute to dtest, so the non-DS > > contributors to dtest would need to be contacted for their permission to > > assign copyright to the ASF. Is the PMC willing to tackle this? > > > > In a brief discussion, it was deduced that #1 can be addressed by > > adding apache/cassandra-dtest to the ASF repo (the example of > > apache/aurora and apache/aurora-packaging was given to justify this). > > > > #2 will be harder as it will require tracking a few people people down > > to sign ASF CLAs. > > > > Before we really put effort into this, I wanted to open the discussion > > up about whether we are willing to take on the development of this in > > the project. Thoughts? > > > > -Nate > > > > > > [0] https://github.com/riptano/cassandra-dtest > > >
cassandra-3.9 (and 3.8) release
The cassandra-3.9 branch HEAD, commit bb371ea, looks good to release (which will also be released as 3.8, changing just the version number). I'm re-running a couple jobs right now, but overall, I think we hit the goal of a clean board: http://cassci.datastax.com/view/cassandra-3.9/ If there are no objections, I'd like to roll up 3.9/3.8 and get them out the door. Should this be on one vote, since they are really the same, or do 2 votes? I'm actually not entirely sure how the build for 3.8 will work, since the branch was deleted. Should I create new branch again for 3.8 with the version edit? This sounds the most reasonable and workable with the release build process. This actually does sound like it should be 2 votes, since the commit sha will be different.. Thanks! -- Kind regards, Michael
cassandra-2.2.8 release
The cassandra-2.2 branch looks stable, has a lot of bug fixes, and Tyler had someone ask about a 2.2.8 release. Any objections to rolling this up for a vote? http://cassci.datastax.com/view/cassandra-2.2/ -- Kind regards, Michael
Re: cassandra-3.9 (and 3.8) release
Branch 3.8 off 3.9 with a commit that only changes the version in all appropriate places. Two separate votes works. -- AY On 23 September 2016 at 12:36:54, Michael Shuler (mich...@pbandjelly.org) wrote: The cassandra-3.9 branch HEAD, commit bb371ea, looks good to release (which will also be released as 3.8, changing just the version number). I'm re-running a couple jobs right now, but overall, I think we hit the goal of a clean board: http://cassci.datastax.com/view/cassandra-3.9/ If there are no objections, I'd like to roll up 3.9/3.8 and get them out the door. Should this be on one vote, since they are really the same, or do 2 votes? I'm actually not entirely sure how the build for 3.8 will work, since the branch was deleted. Should I create new branch again for 3.8 with the version edit? This sounds the most reasonable and workable with the release build process. This actually does sound like it should be 2 votes, since the commit sha will be different.. Thanks! -- Kind regards, Michael
[VOTE] Release Apache Cassandra 2.2.8
I propose the following artifacts for release as 2.2.8. sha1: e9fe96f404b6a936ac5dbceb8f3934fe0d098a97 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.8-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1125/org/apache/cassandra/apache-cassandra/2.2.8/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1125/ The Debian packages are available here: http://people.apache.org/~mshuler The vote will be open for 72 hours (longer if needed). [1]: (CHANGES.txt) https://goo.gl/3Chc0Z [2]: (NEWS.txt) https://goo.gl/0UgwXZ
Re: cassandra-2.2.8 release
There were no immediate objections and I didn't spot any in-progress tickets for 2.2.8, so go vote! -- Michael
Re: [VOTE] Release Apache Cassandra 2.2.8
+1 -- AY On 23 September 2016 at 16:04:58, Michael Shuler (mshu...@apache.org) wrote: I propose the following artifacts for release as 2.2.8. sha1: e9fe96f404b6a936ac5dbceb8f3934fe0d098a97 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.8-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1125/org/apache/cassandra/apache-cassandra/2.2.8/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1125/ The Debian packages are available here: http://people.apache.org/~mshuler The vote will be open for 72 hours (longer if needed). [1]: (CHANGES.txt) https://goo.gl/3Chc0Z [2]: (NEWS.txt) https://goo.gl/0UgwXZ
Re: cassandra-3.9 (and 3.8) release
Thanks! I'll do these release builds and start votes, first thing Monday morning, unless I find some time on Sunday. -- Michael On 09/23/2016 05:15 PM, Aleksey Yeschenko wrote: > Branch 3.8 off 3.9 with a commit that only changes the version in all > appropriate places. > > Two separate votes works. > > -- > AY > > On 23 September 2016 at 12:36:54, Michael Shuler (mich...@pbandjelly.org) > wrote: > > The cassandra-3.9 branch HEAD, commit bb371ea, looks good to release > (which will also be released as 3.8, changing just the version number). > I'm re-running a couple jobs right now, but overall, I think we hit the > goal of a clean board: http://cassci.datastax.com/view/cassandra-3.9/ > > If there are no objections, I'd like to roll up 3.9/3.8 and get them out > the door. Should this be on one vote, since they are really the same, or > do 2 votes? I'm actually not entirely sure how the build for 3.8 will > work, since the branch was deleted. Should I create new branch again for > 3.8 with the version edit? This sounds the most reasonable and workable > with the release build process. This actually does sound like it should > be 2 votes, since the commit sha will be different.. Thanks! > > -- > Kind regards, > Michael >
Re: [VOTE] Release Apache Cassandra 2.2.8
+1 On Fri, Sep 23, 2016 at 6:04 PM, Michael Shuler wrote: > I propose the following artifacts for release as 2.2.8. > > sha1: e9fe96f404b6a936ac5dbceb8f3934fe0d098a97 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/2.2.8-tentative > Artifacts: > https://repository.apache.org/content/repositories/ > orgapachecassandra-1125/org/apache/cassandra/apache-cassandra/2.2.8/ > Staging repository: > https://repository.apache.org/content/repositories/ > orgapachecassandra-1125/ > > The Debian packages are available here: http://people.apache.org/~mshuler > > The vote will be open for 72 hours (longer if needed). > > [1]: (CHANGES.txt) https://goo.gl/3Chc0Z > [2]: (NEWS.txt) https://goo.gl/0UgwXZ >
Re: [VOTE] Release Apache Cassandra 2.2.8
+1 On Friday, September 23, 2016, Brandon Williams wrote: > +1 > > On Fri, Sep 23, 2016 at 6:04 PM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 2.2.8. > > > > sha1: e9fe96f404b6a936ac5dbceb8f3934fe0d098a97 > > Git: > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > > shortlog;h=refs/tags/2.2.8-tentative > > Artifacts: > > https://repository.apache.org/content/repositories/ > > orgapachecassandra-1125/org/apache/cassandra/apache-cassandra/2.2.8/ > > Staging repository: > > https://repository.apache.org/content/repositories/ > > orgapachecassandra-1125/ > > > > The Debian packages are available here: http://people.apache.org/~ > mshuler > > > > The vote will be open for 72 hours (longer if needed). > > > > [1]: (CHANGES.txt) https://goo.gl/3Chc0Z > > [2]: (NEWS.txt) https://goo.gl/0UgwXZ > > >
Re: [VOTE] Release Apache Cassandra 2.2.8
+1 On 2016-09-23 16:04 (-0700), Michael Shuler wrote: > I propose the following artifacts for release as 2.2.8. > > sha1: e9fe96f404b6a936ac5dbceb8f3934fe0d098a97 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.8-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1125/org/apache/cassandra/apache-cassandra/2.2.8/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-1125/ > > The Debian packages are available here: http://people.apache.org/~mshuler > > The vote will be open for 72 hours (longer if needed). > > [1]: (CHANGES.txt) https://goo.gl/3Chc0Z > [2]: (NEWS.txt) https://goo.gl/0UgwXZ >
Re: cassandra-3.9 (and 3.8) release
(non-binding) -1 on releasing 2 versions with the same version number. Everything that's been communicated to the world has been that there would be a feature release, then a bug fix release a month later. This breaks that promise. On Fri, Sep 23, 2016 at 4:23 PM Michael Shuler wrote: > Thanks! I'll do these release builds and start votes, first thing Monday > morning, unless I find some time on Sunday. > > -- > Michael > > On 09/23/2016 05:15 PM, Aleksey Yeschenko wrote: > > Branch 3.8 off 3.9 with a commit that only changes the version in all > appropriate places. > > > > Two separate votes works. > > > > -- > > AY > > > > On 23 September 2016 at 12:36:54, Michael Shuler (mich...@pbandjelly.org) > wrote: > > > > The cassandra-3.9 branch HEAD, commit bb371ea, looks good to release > > (which will also be released as 3.8, changing just the version number). > > I'm re-running a couple jobs right now, but overall, I think we hit the > > goal of a clean board: http://cassci.datastax.com/view/cassandra-3.9/ > > > > If there are no objections, I'd like to roll up 3.9/3.8 and get them out > > the door. Should this be on one vote, since they are really the same, or > > do 2 votes? I'm actually not entirely sure how the build for 3.8 will > > work, since the branch was deleted. Should I create new branch again for > > 3.8 with the version edit? This sounds the most reasonable and workable > > with the release build process. This actually does sound like it should > > be 2 votes, since the commit sha will be different.. Thanks! > > > > -- > > Kind regards, > > Michael > > > >
Re: cassandra-3.9 (and 3.8) release
Both are effectively 3.9 on steroids. One month of features and improvements with 2 months of bug fixes on top. If anything, this overdelivers. -- AY On 23 September 2016 at 17:02:05, Jonathan Haddad (j...@jonhaddad.com) wrote: (non-binding) -1 on releasing 2 versions with the same version number. Everything that's been communicated to the world has been that there would be a feature release, then a bug fix release a month later. This breaks that promise. On Fri, Sep 23, 2016 at 4:23 PM Michael Shuler wrote: > Thanks! I'll do these release builds and start votes, first thing Monday > morning, unless I find some time on Sunday. > > -- > Michael > > On 09/23/2016 05:15 PM, Aleksey Yeschenko wrote: > > Branch 3.8 off 3.9 with a commit that only changes the version in all > appropriate places. > > > > Two separate votes works. > > > > -- > > AY > > > > On 23 September 2016 at 12:36:54, Michael Shuler (mich...@pbandjelly.org) > wrote: > > > > The cassandra-3.9 branch HEAD, commit bb371ea, looks good to release > > (which will also be released as 3.8, changing just the version number). > > I'm re-running a couple jobs right now, but overall, I think we hit the > > goal of a clean board: http://cassci.datastax.com/view/cassandra-3.9/ > > > > If there are no objections, I'd like to roll up 3.9/3.8 and get them out > > the door. Should this be on one vote, since they are really the same, or > > do 2 votes? I'm actually not entirely sure how the build for 3.8 will > > work, since the branch was deleted. Should I create new branch again for > > 3.8 with the version edit? This sounds the most reasonable and workable > > with the release build process. This actually does sound like it should > > be 2 votes, since the commit sha will be different.. Thanks! > > > > -- > > Kind regards, > > Michael > > > >
Re: cassandra-3.9 (and 3.8) release
Jonathan's is a pretty compelling perspective. -- Michael On 09/23/2016 07:04 PM, Aleksey Yeschenko wrote: > Both are effectively 3.9 on steroids. One month of features and > improvements with 2 months of bug fixes on top. > > If anything, this overdelivers. > > -- AY > > On 23 September 2016 at 17:02:05, Jonathan Haddad (j...@jonhaddad.com) > wrote: > > (non-binding) -1 on releasing 2 versions with the same version > number. Everything that's been communicated to the world has been > that there would be a feature release, then a bug fix release a month > later. This breaks that promise. > > On Fri, Sep 23, 2016 at 4:23 PM Michael Shuler > wrote: > >> Thanks! I'll do these release builds and start votes, first thing >> Monday morning, unless I find some time on Sunday. >> >> -- Michael >> >> On 09/23/2016 05:15 PM, Aleksey Yeschenko wrote: >>> Branch 3.8 off 3.9 with a commit that only changes the version in >>> all >> appropriate places. >>> >>> Two separate votes works. >>> >>> -- AY >>> >>> On 23 September 2016 at 12:36:54, Michael Shuler >>> (mich...@pbandjelly.org) >> wrote: >>> >>> The cassandra-3.9 branch HEAD, commit bb371ea, looks good to >>> release (which will also be released as 3.8, changing just the >>> version number). I'm re-running a couple jobs right now, but >>> overall, I think we hit the goal of a clean board: >>> http://cassci.datastax.com/view/cassandra-3.9/ >>> >>> If there are no objections, I'd like to roll up 3.9/3.8 and get >>> them out the door. Should this be on one vote, since they are >>> really the same, or do 2 votes? I'm actually not entirely sure >>> how the build for 3.8 will work, since the branch was deleted. >>> Should I create new branch again for 3.8 with the version edit? >>> This sounds the most reasonable and workable with the release >>> build process. This actually does sound like it should be 2 >>> votes, since the commit sha will be different.. Thanks! >>> >>> -- Kind regards, Michael >>> >> >> >
Re: cassandra-3.9 (and 3.8) release
Please don’t make me argue over 3.8/3.9 again. We are way, way over our original schedule at this point. Releasing 3.9 now breaks no promises. You still get more than a month of purely bug fixes in the release. And if we only do 3.8 off the current cassandra-3.9 branch, then trunk becomes the next 3.9, except it already has a ton of new features, improvements, and a non-trivial amount of bugfixes as well. We could branch off, and cherry-pick all the fixes back from trunk, but just releasing both now is a lot less work. More importantly, it would mean delaying 3.9 by another month. We’ve communicated that odd ones are to be run in production, so users stuck on 3.7 would have to wait even longer until the can upgrade further. And the delta between 3.7 and current cassandra-3.9 is pretty significant. Let’s not make people wait even longer, please? Plus, we had a consensus when this came up last time. Let’s stick to the plan, because if we keep ignoring our previous conclusions we’ll never release anything. (binding) -1 to (only) releasing the current cassandra-3.9 head as 3.8. Michael: please start both votes. For 3.8 there is consensus, for 3.9 there is consensus among PMCs. If something changed, it’ll be reflected in the vote. -- AY On 23 September 2016 at 21:39:09, Michael Shuler (mich...@pbandjelly.org) wrote: Jonathan's is a pretty compelling perspective. -- Michael On 09/23/2016 07:04 PM, Aleksey Yeschenko wrote: > Both are effectively 3.9 on steroids. One month of features and > improvements with 2 months of bug fixes on top. > > If anything, this overdelivers. > > -- AY > > On 23 September 2016 at 17:02:05, Jonathan Haddad (j...@jonhaddad.com) > wrote: > > (non-binding) -1 on releasing 2 versions with the same version > number. Everything that's been communicated to the world has been > that there would be a feature release, then a bug fix release a month > later. This breaks that promise. > > On Fri, Sep 23, 2016 at 4:23 PM Michael Shuler > wrote: > >> Thanks! I'll do these release builds and start votes, first thing >> Monday morning, unless I find some time on Sunday. >> >> -- Michael >> >> On 09/23/2016 05:15 PM, Aleksey Yeschenko wrote: >>> Branch 3.8 off 3.9 with a commit that only changes the version in >>> all >> appropriate places. >>> >>> Two separate votes works. >>> >>> -- AY >>> >>> On 23 September 2016 at 12:36:54, Michael Shuler >>> (mich...@pbandjelly.org) >> wrote: >>> >>> The cassandra-3.9 branch HEAD, commit bb371ea, looks good to >>> release (which will also be released as 3.8, changing just the >>> version number). I'm re-running a couple jobs right now, but >>> overall, I think we hit the goal of a clean board: >>> http://cassci.datastax.com/view/cassandra-3.9/ >>> >>> If there are no objections, I'd like to roll up 3.9/3.8 and get >>> them out the door. Should this be on one vote, since they are >>> really the same, or do 2 votes? I'm actually not entirely sure >>> how the build for 3.8 will work, since the branch was deleted. >>> Should I create new branch again for 3.8 with the version edit? >>> This sounds the most reasonable and workable with the release >>> build process. This actually does sound like it should be 2 >>> votes, since the commit sha will be different.. Thanks! >>> >>> -- Kind regards, Michael >>> >> >> >
Re: cassandra-3.9 (and 3.8) release
Thanks for all the detail. I do appreciate your time in replying. I'm not fond of the idea of trying to cherry-pick trunk and delay further.. This has just been an odd and unorthodox moment in time to adopt release management, and I simply wish to do what's best for users. It's late, and I need to be up early for an event tomorrow. I'll build both releases Monday or sooner and get votes going. -- Michael On 09/24/2016 12:05 AM, Aleksey Yeschenko wrote: > Please don’t make me argue over 3.8/3.9 again. We are way, way over > our original schedule at this point. > > Releasing 3.9 now breaks no promises. You still get more than a month > of purely bug fixes in the release. > > And if we only do 3.8 off the current cassandra-3.9 branch, then > trunk becomes the next 3.9, except it already has a ton of new > features, improvements, and a non-trivial amount of bugfixes as > well. > > We could branch off, and cherry-pick all the fixes back from trunk, > but just releasing both now is a lot less work. > > More importantly, it would mean delaying 3.9 by another month. We’ve > communicated that odd ones are to be run in production, so users > stuck on 3.7 would have to wait even longer until the can upgrade > further. And the delta between 3.7 and current cassandra-3.9 is > pretty significant. Let’s not make people wait even longer, please? > > Plus, we had a consensus when this came up last time. Let’s stick to > the plan, because if we keep ignoring our previous conclusions we’ll > never release anything. > > (binding) -1 to (only) releasing the current cassandra-3.9 head as > 3.8. > > Michael: please start both votes. For 3.8 there is consensus, for 3.9 > there is consensus among PMCs. If something changed, it’ll be > reflected in the vote. > > -- AY > > On 23 September 2016 at 21:39:09, Michael Shuler > (mich...@pbandjelly.org) wrote: > > Jonathan's is a pretty compelling perspective. > > -- Michael > > On 09/23/2016 07:04 PM, Aleksey Yeschenko wrote: >> Both are effectively 3.9 on steroids. One month of features and >> improvements with 2 months of bug fixes on top. >> >> If anything, this overdelivers. >> >> -- AY >> >> On 23 September 2016 at 17:02:05, Jonathan Haddad >> (j...@jonhaddad.com) wrote: >> >> (non-binding) -1 on releasing 2 versions with the same version >> number. Everything that's been communicated to the world has been >> that there would be a feature release, then a bug fix release a >> month later. This breaks that promise. >> >> On Fri, Sep 23, 2016 at 4:23 PM Michael Shuler >> wrote: >> >>> Thanks! I'll do these release builds and start votes, first thing >>> Monday morning, unless I find some time on Sunday. >>> >>> -- Michael >>> >>> On 09/23/2016 05:15 PM, Aleksey Yeschenko wrote: Branch 3.8 off 3.9 with a commit that only changes the version in all >>> appropriate places. Two separate votes works. -- AY On 23 September 2016 at 12:36:54, Michael Shuler (mich...@pbandjelly.org) >>> wrote: The cassandra-3.9 branch HEAD, commit bb371ea, looks good to release (which will also be released as 3.8, changing just the version number). I'm re-running a couple jobs right now, but overall, I think we hit the goal of a clean board: http://cassci.datastax.com/view/cassandra-3.9/ If there are no objections, I'd like to roll up 3.9/3.8 and get them out the door. Should this be on one vote, since they are really the same, or do 2 votes? I'm actually not entirely sure how the build for 3.8 will work, since the branch was deleted. Should I create new branch again for 3.8 with the version edit? This sounds the most reasonable and workable with the release build process. This actually does sound like it should be 2 votes, since the commit sha will be different.. Thanks! -- Kind regards, Michael >>> >>> >> > >
