Failing tests 2016-09-15

2016-09-15 Thread Joel Knighton
cassandra-3.9: No new runs trunk === testall: 6 failures org.apache.cassandra.cql3.KeyCacheCqlTest .test2iKeyCachePathsShallowIndexEntry org.apache.cassandra.cql3.KeyCacheCqlTest .test2iKeyCachePathsShallowIndexEntry-compression

Re: Proposal - 3.5.1

2016-09-15 Thread Mick Semb Wever
Totally agree with all the frustrations felt by Jon here. TL;DR Here's a proposal for 4.0 and beyond: that is puts together the comments from Benedict, Jon, Tyler, Jeremy, and Ed; - keep bimonthly feature releases, - revert from tick-tock to SemVer numbering scheme, - during the release vote

Re: [VOTE] Release Apache Cassandra 3.0.9

2016-09-15 Thread Sam Tunnicliffe
+1 On 15 Sep 2016 19:58, "Jake Luciani" wrote: > I propose the following artifacts for release as 3.0.9. > > sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/3.0.9-tentative > Artifacts: >

Re: [VOTE] Release Apache Cassandra 3.0.9

2016-09-15 Thread Jason Brown
+1 On Thu, Sep 15, 2016 at 3:20 PM, Nate McCall wrote: > +1 > > On Fri, Sep 16, 2016 at 6:57 AM, Jake Luciani wrote: > > > I propose the following artifacts for release as 3.0.9. > > > > sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 > > Git: > >

Re: [VOTE] Release Apache Cassandra 3.0.9

2016-09-15 Thread Nate McCall
+1 On Fri, Sep 16, 2016 at 6:57 AM, Jake Luciani wrote: > I propose the following artifacts for release as 3.0.9. > > sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/3.0.9-tentative >

Re: Proposal - 3.5.1

2016-09-15 Thread Jonathan Haddad
If the releases can be tagged as alpha / beta so that people don't accidentally put it in prod (or at least, will do so less), that would be totally reasonable. On Thu, Sep 15, 2016 at 12:27 PM Tyler Hobbs wrote: > On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith < >

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
Yes, agreed. I'm advocating a different cadence, not a random cadence. On Thursday, 15 September 2016, Tyler Hobbs wrote: > On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith < > bened...@apache.org > > wrote: > > > Feature releases don't have to be on

Re: Proposal - 3.5.1

2016-09-15 Thread Tyler Hobbs
On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith wrote: > Feature releases don't have to be on the same cadence as bug fixes. They're > naturally different beasts. > With the exception of critical bug fixes (which can warrant an immediate release), I think keeping a

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
Feature releases don't have to be on the same cadence as bug fixes. They're naturally different beasts. Why not stick with monthly feature releases, but mark every third (or sixth) as a supported release that gets quarterly updates for 2-3 quarters? On Thursday, 15 September 2016, Tyler Hobbs

Re: Proposal - 3.5.1

2016-09-15 Thread Tyler Hobbs
I agree that regular (monthly) releases, and smaller, more frequent feature releases are the best part of tick/tock. The downside of tick/tock, as mentioned above, is that there isn't enough time for user feedback and testing to catch new bugs before the next feature release. I would personally

Re: Proposal - 3.5.1

2016-09-15 Thread Jeremy Hanna
Right - I think like Jake and others have said, it seems appropriate to do something at this point. Would a clearer, more liberal backport policy to the odd versions be worthwhile until we find our footing? As Jeremiah said, it does seem like the big bang 3.0 release has caused much of the

Re: [VOTE] Release Apache Cassandra 3.0.9

2016-09-15 Thread Tyler Hobbs
+1 On Thu, Sep 15, 2016 at 1:57 PM, Jake Luciani wrote: > I propose the following artifacts for release as 3.0.9. > > sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > shortlog;h=refs/tags/3.0.9-tentative >

Re: [VOTE] Release Apache Cassandra 3.0.9

2016-09-15 Thread Aleksey Yeschenko
+1 --  AY On 15 September 2016 at 11:58:24, Jake Luciani (j...@apache.org) wrote: I propose the following artifacts for release as 3.0.9. sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.9-tentative

Re: Proposal - 3.5.1

2016-09-15 Thread Jonathan Haddad
I don't think it's binary - we don't have to do year long insanity or bleeding edge crazyness. How about a release every 3 months, with each release accepting 6 months of patches? (oldstable & newstable) Also provide nightly builds & stick to the idea of stable trunk. The issue is the number

[VOTE] Release Apache Cassandra 3.0.9

2016-09-15 Thread Jake Luciani
I propose the following artifacts for release as 3.0.9. sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.9-tentative Artifacts:

Re: Proposal - 3.5.1

2016-09-15 Thread Jeremiah D Jordan
Because tick-tock started based off of the 3.0 big bang “we broke everything” release I don’t think we can judge wether or not it is working until we are another 6 months in. AKA when we would have been releasing the next big bang release. Right now a lot if not most of the bugs in a given

Re: Proposal - 3.5.1

2016-09-15 Thread Jake Luciani
I'm pretty sure everyone will agree Tick-Tock didn't go well and needs to change. The problem for me is going back to the old way doesn't sound great. There are parts of tick-tock I really like, for example, the cadence and limited scope per release. I know at the summit there were a lot of

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
I agree tick-tock is a failure. But for two reasons IMO: 1) Ultimately, the users are the real testers and it takes a while for a release to percolate into the wild for feedback. The reality is that a release doesn't have its tires properly kicked for at least three months after it's cut. So

Re: Proposal - 3.5.1

2016-09-15 Thread Jeff Jirsa
I know we’ve got a lot of folks following the dev list without a lot of background, so let’s make sure we get some context here so everyone can be on the same page. Going to preface this wall of text by saying I’m +1 on a 3.5.1 (and 3.3.1, etc) if it’s done AFTER 3.9 (I think we need to get

Re: Proposal - 3.5.1

2016-09-15 Thread Benedict Elliott Smith
It's worth noting more clearly that 3.5 is an arbitrary point in time. All 3.X releases < 3.6 are affected. If we backport to 3.5, it seems like 3.1 and 3.3 should get the same treatment. I do recall commitments to backport critical fixes, but exactly what the bar is was never well defined. I

Re: Proposal - 3.5.1

2016-09-15 Thread Dave Lester
How would cutting a 3.5.1 release possibly confuse users of the software? It would be easy to document the change and to send release notes. Given the bug’s critical nature and that it's a minor fix, I’m +1 (non-binding) to a new release. Dave > On Sep 15, 2016, at 7:18 AM, Jeremiah D Jordan

Re: Proposal - 3.5.1

2016-09-15 Thread Edward Capriolo
Where did we come from? We came from a place where we would say, "You probably do not want to run 2.0.X until it reaches 2.0.6" One thing about Cassandra is we get into a situation where we can only go forward. For example, when you update from version X to version Y, version Y might start

Re: Proposal - 3.5.1

2016-09-15 Thread Jeremiah D Jordan
I’m with Jeff on this, 3.7 (bug fixes on 3.6) has already been released with the fix. Since the fix applies cleanly anyone is free to put it on top of 3.5 on their own if they like, but I see no reason to put out a 3.5.1 right now and confuse people further. -Jeremiah > On Sep 15, 2016, at

Re: Proposal - 3.5.1

2016-09-15 Thread Jonathan Haddad
As I follow up, I suppose I'm only advocating for a fix to the odd releases. Sadly, Tick Tock versioning is misleading. If tick tock were to continue (and I'm very much against how it currently works) the whole even-features odd-fixes thing needs to stop ASAP, all it does it confuse people. The

Re: Failing tests 2016-09-14

2016-09-15 Thread Oleksandr Petrov
> SelectTest start to be pretty big. Agree, I've started to get that feeling as well. On Thu, Sep 15, 2016 at 9:42 AM Benjamin Lerer wrote: > SelectTest start to be pretty big. It makes sense to splitting it into > separate TestClasses. For example we could extract

Re: Failing tests 2016-09-14

2016-09-15 Thread Benjamin Lerer
SelectTest start to be pretty big. It makes sense to splitting it into separate TestClasses. For example we could extract all the filtering tests into a new TestClass: FilteringTest or SelectWithFilteringTest. On Thu, Sep 15, 2016 at 8:34 AM, Oleksandr Petrov < oleksandr.pet...@gmail.com> wrote:

Re: Failing tests 2016-09-14

2016-09-15 Thread Oleksandr Petrov
> CASSANDRA-11031 Yes, sorry for delay with #11031 dtests. I've ran updated dtests yesterday and they were clean to merge. I just wanted to make sure someone else takes a quick glance. By now they're merged, so hopefully today it's going to be better. As regards environmental timeouts, it looks