I've been able to reproduce both SASI statics (saved sstables, going to
take a closer look) and 11031 tests with novnode (looks like paging problem
that was not appearing when all parts of partition key were locked), will
create a Jira ticket today.
On Fri, Sep 16, 2016 at 7:24 AM Joel Knighton
w
cassandra-3.9: No new runs
trunk
===
testall: 6 failures
org.apache.cassandra.cql3.KeyCacheCqlTest
.test2iKeyCachePathsShallowIndexEntry
org.apache.cassandra.cql3.KeyCacheCqlTest
.test2iKeyCachePathsShallowIndexEntry-compression
CASSA
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
+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:
> https://repository.
+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:
> > http://git-wip-us.apache.org/repos/asf?p=cassand
+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
> Artifacts:
> https://re
+1
On Thu, Sep 15, 2016 at 2: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
> Artifacts:
> https://re
It is funny you say this:
"tick-tock started based off of the 3.0 big bang “we broke everything”
release"
*"Brain battles itself over short-term rewards, long-term goals"*
https://www.princeton.edu/pr/news/04/q4/1014-brain.htm
*Normalization of deviance in software: how broken practices become
s
+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
> Artifacts:
> https://re
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 <
> bened...@apache.org
>
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 the same cadence as bug fixes.
> They
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 regular cadence makes
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 w
+1
On 9/15/16, 11:57 AM, "jak...@gmail.com on behalf of Jake Luciani"
wrote:
>I propose the following artifacts for release as 3.0.9.
>
>sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012
>Git:
>https://urldefense.proofpoint.com/v2/url?u=http-3A__git-2Dwip-2Dus.apache.org_repos_asf-3Fp-3Dcassandra
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 l
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 bag
+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
> Artifacts:
> https://re
+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
Ar
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 of
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:
https://repository.apache.org/content/repositories/orgapachecassandra-1124/org/apache
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 tic
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 ideas
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 if
Just another user perspective from someone who manages many clusters:
Tick-tock doesn't really make sense unless at some point you stop ticking.
You can't expect to release features constantly and have a stable product
every tock. Not unless you have really high development, code review, and
testi
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 3.
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 a
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
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 writin
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 9
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
> 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 all the filtering tests
> int
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:
32 matches
Mail list logo
