>From where I stand it looks like you've got only two options for any
feature that involves updating the protocol:
1. Don't built the feature
2. Built it in Cassanda & scylladb, update the drivers accordingly
I don't think you have a third option, which is built it only in ScyllaDB,
because that
DataStax invested millions of dollars into Cassandra, tens of thousands of
man hours, hosted hundreds of events and has been a major factor in the
success of the project.
ScyllaDB wants us to change the C* protocol in order to improve features in
a competing database which contributes nothing back
Personally I don’t mind dropping support for previsous java versions.
On Fri, May 25, 2018 at 6:33 AM J. D. Jordan
wrote:
> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code
> wise, and leaves people’s options open.
>
> -Jeremiah
>
> > On May 25, 2018, at 6:31 AM, Robert S
Supporting both as a next step is logical, removing support for 2 in the
next year or two seems reasonable enough. Gotta rip the band aid off at
some point.
On Fri, Jun 1, 2018 at 2:34 AM Michael Burman wrote:
> Hi,
>
> Deprecating in this context does not mean removing it or it being
> replaced
ing to change. I
> think it will be more than 2 years before people begin asking what
> Python 2 was.
>
>
> On 06/01/2018 10:10 AM, Jonathan Haddad wrote:
> > Supporting both as a next step is logical, removing support for 2 in the
> > next year or two seems reas
to be following the lead of the OS vendors that people will be deploying
> Cassandra on top of. And those will not be dropping Python 2 at the end of
> the year.
>
> -Jeremiah
>
> > On Jun 1, 2018, at 12:37 PM, Jonathan Haddad wrote:
> >
> > Both can work. I did a
I agree with Josh. I don’t see how changing the convention around trunk
will improve the process, seems like it’ll only introduce a handful of
rollback commits when people forget.
Other than that, it all makes sense to me.
I’ve been working on a workload centric stress tool on and off for a littl
pen.
> > > >>>
> > > >>> This is more of a call to action and announcement of intent than an
> > > >>> attempt to enforce policy; we can and probably will branch off 4.0,
> > > and
> > > >>> keep trunk technically active.
assing, how will these
> features be used?
>
> On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad wrote:
>
> > I don't see how changing the process and banning feature commits is
> > going to be any help to the project. There may be a couple committers
> > who are int
see how we can improve things here. So if you are -1 on this, please help
> us propose something else to get these tests pass?
>
> And thanks for giving your feedback.
>
> On Mon, Jul 9, 2018 at 10:50 AM Jonathan Haddad wrote:
>
> > Not everyone wants to work and collaborat
; > On Jul 9, 2018, at 12:43 PM, sankalp kohli
> > wrote:
> > >
> > > How is this preventing someone from working and collaborating on an
> > Apache
> > > Project? You can still collaborate on making 4.0 more stable.
> > >
> > >
I guess I look at the initial voting in of committers as the process
by which people are trusted to merge things in. This proposed process
revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily
picked) wants to merge a new feature into trunk during the freeze, now
they're not allowed?
It’s an embodiment of trust that you will follow the community's prevailing
> rules around commit, and that you’re competent to do so.
>
> If the community wants to change those rules you’re trusted to follow, how
> does this modify your right, or the trust emplaced in you?
&
e a situation to need it - besides
> discouraging a new contributor who, let’s be honest, was going to have their
> patch languish for a few months while somebody found time to review it
> anyway. At least this way we can give them a decent excuse!
>
>
>
> > On 10 Jul 2018, a
>
> Deferring huge amount of commits gives rebase/redo hell. That's the
> biggest impact and the order in which these deferred commits are then
> actually committed can make it more painful or less painful depending on
> the commit. And that in turn will have to then wait for each contributor
> to
+1,
I've come around on this, I think the long and short term benefits
will be worth it.
On Fri, Jul 13, 2018 at 11:17 AM Vinay Chella
wrote:
>
> +1 nb
>
> Regards,
> Vinay Chella
>
>
> On Fri, Jul 13, 2018 at 11:15 AM Michael Shuler
> wrote:
>
> > +0
> >
> > There are pros and cons. I do hope t
+1
On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote:
> +1
>
> On Wed, Jul 25, 2018 at 12:16 AM, Michael Shuler
> wrote:
>
> > I propose the following artifacts for release as 3.11.3.
> >
> > sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=ca
+1
On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote:
> +1
>
> On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler
> wrote:
>
> > I propose the following artifacts for release as 3.0.17.
> >
> > sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=ca
+1
On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote:
> +1
>
> On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler
> wrote:
>
> > I propose the following artifacts for release as 2.2.13.
> >
> > sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=ca
My interpretation of Nate's statement was that since there would be a bunch
of us at Lynn's event, we might as well do NGCC at the same time.
On Thu, Jul 26, 2018 at 9:03 PM Ben Bromhead wrote:
> It sounds like there may be an appetite for something, but the NGCC in its
> current format is likel
+1 to worklog
On Mon, Aug 6, 2018 at 9:44 AM Ariel Weisberg wrote:
> Hi,
>
> Great idea. +1 to moving it to the work log.
>
> Thanks,
> Ariel
>
> On Mon, Aug 6, 2018, at 12:40 PM, Aleksey Yeshchenko wrote:
> > Nice indeed. I assume it also doesn’t spam commits@ when done this way,
> > in which c
I fired up trunk to check something, and noticed this:
INFO [Service Thread] 2018-08-08 15:01:36,723 GCInspector.java:290 - G1
Young Generation GC in 339ms. G1 Eden Space: 4634705920 -> 0; G1 Old Gen:
1190138352 -> 1435504616; G1 Survivor Space: 406847488 -> 301989888;
which I thought was a bit
Pushing it back means it’s a bigger risk later on. I’m +.5 on upgrading now
On Wed, Aug 15, 2018 at 11:46 PM dinesh.jo...@yahoo.com.INVALID
wrote:
> Jason,
> Given that we're so close to the 9/1 date, I would err on the side of
> caution especially given the low value prop. If someone does run i
Speaking from experience (Reaper), I can say that developing a sidecar
admin / repair tool out of tree that's compatible with multiple versions
really isn't that big of a problem. We've been doing it for a while now.
https://github.com/thelastpickle/cassandra-reaper/blob/master/.travis.yml
On Fr
Strongly agree with Blake. In my mind supporting multiple versions is
mandatory. As I've stated before, we already do it with Reaper, I'd
consider it a major misstep if we couldn't support multiple with the
project - provided admin tool. It's the same reason dtests are separate -
they work with
Hey folks,
Mick brought this up in the sidecar thread, but I wanted to have a clear /
separate discussion about what we're thinking with regard to contributing
Reaper to the C* project. In my mind, starting with Reaper is a great way
of having an admin right now, that we know works well at the ki
and we're
finishing up the rework of the code to run it as a sidecar.
On Mon, Aug 27, 2018 at 6:02 PM Jeff Jirsa wrote:
> Can you get all of the contributors cleared?
> What’s the architecture? Is it centralized? Is there a sidecar?
>
>
> > On Aug 27, 2018, at 5:36 PM, Jonathan
I'm also very interested.
On Tue, Aug 28, 2018 at 8:47 AM Dinesh Joshi
wrote:
> > On Aug 28, 2018, at 6:33 AM, Marcus Olsson
> wrote:
> >
> > Hi,
> >
> > With the risk of stirring the repair/side-car topic even further I'd
> just like to mention that we have recently gotten approval to contri
Advertised, yes, but so far I haven't found it to be any better than
ParNew + CMS or G1 in the performance tests I did when writing
http://thelastpickle.com/blog/2018/08/16/java11.html.
That said, I didn't try it with a huge heap (i think it was 16 or 24GB), so
maybe it'll do better if I throw 50
Definitely does not belong in the same repo.
I’m all for folding drivers in / writing our own, just needs active
committers.
On Fri, Aug 31, 2018 at 7:45 AM Michael Shuler
wrote:
> On 08/31/2018 09:34 AM, Jay Zhuang wrote:
> > That's great. Could that be in the same repo as Cassandra or a
> > s
ng this year? We
> may
> > also be able to provide space in bay area and help to organize it.
> (Please
> > let us know, so we could get final approval for that).
> >
> > On Fri, Jul 27, 2018 at 10:05 AM Jonathan Haddad
> > wrote:
> >
> > > My interp
For 4.0, I'm thinking it would be a good idea to put together a list of the
things that need testing and see if people are willing to help test / break
those things. My goal here is to get as much coverage as possible, and let
folks focus on really hammering on specific things rather than just fir
ab9c298e80ad8e76f11a563b4d250c1ae38@%3Cdev.cassandra.apache.org%3E
On Thu, Sep 6, 2018 at 10:35 AM Jordan West wrote:
> Thanks for staring this thread Jon!
>
> On Thu, Sep 6, 2018 at 5:51 AM Jonathan Haddad wrote:
>
> > For 4.0, I'm thinking it would be a good idea to put together a list of
> t
ers, looks like most testing is done by doing
> an operation or running a load and seeing if it "worked" and no errors in
> logs.
>
> Another important thing will be to fix bugs asap ahead of testing, as
> fixes can lead to more bugs :)
>
> On Thu, Sep 6, 2018 at 7:5
Test plans and results could be posted to said
> JIRAs, to be closed once a given test passes. Any bugs found can also then
> be related back to such a ticket for tracking them as well.
>
> -Jeremiah
>
> > On Sep 6, 2018, at 12:27 PM, Jonathan Haddad wrote:
> >
> &g
We haven’t even defined any requirements for an admin tool. It’s hard to
make a case for anything without agreement on what we’re trying to build.
On Fri, Sep 7, 2018 at 7:17 PM Jeff Jirsa wrote:
> How can we continue moving this forward?
>
> Mick/Jon/TLP folks, is there a path here where we com
It's interesting to me that someone would consider features of Reaper as
"technical debt"... an odd way to word it. When we had proposed donating
Reaper to the project, I had made the assumption people would realize the
benefit of folding in a successful project. A working codebase with a
large u
I'm +0, and I share the same concerns as Sylvain.
For those of you that have +1'ed, are you planning on contributing to the
driver? Docs, code, QA? It's easy to throw a +1 down to make the driver
the responsibility of the project if you're asking others to do the work.
I vote this way because I
This voting process feels a bit rushed and frankly not well thought out.
In addition to Sylvain's valid points, which you (Sankalp) didn't address
at all, the discussion in the other threads seemed to be ongoing. The last
email you wrote on one of them was asking for additional feedback, that
indi
cussion.
>
> From Sylvain
> 2. About the voting process...I think that was addressed by Jeff Jirsa and
> deserves a separate thread as it is not directly related to this thread.
> 3. Does the project need a side car.
>
> From Jonathan Haddad
> 4. Are people doing +1 willin
It seems to me that improving / simplifying the process of building the
packages might solve this problem better. For example, in the tests you
linked to, they were using a custom build that hadn't been rolled into
trunk. I expect we're going to see a lot of that.
If we make building a deb packa
Sure - I'm not disagreeing with you that pre-built packages would be nice
to have. That said, if someone's gone through the trouble of building an
entire testing infrastructure and has hundreds of machines available,
running `docker-compose up build-deb` is likely not a major issue. If I'm
trying
One thing that's really, really bothered me for a while is how we default
to 256 tokens still. There's no experienced operator that leaves it as is
at this point, meaning the only people using 256 are the poor folks that
just got started using C*. I've worked with over a hundred clusters in the
l
--
> > Jeff Jirsa
> >
> >
> > > On Sep 21, 2018, at 8:24 PM, Jeremy Hanna
> > wrote:
> > >
> > > I agree that it should be lowered. What I’ve seen debated a bit in the
> > past is the number but I don’t think anyone thinks that it should remain
>
sh Joshi wrote:
> > > Jon, thanks for starting this thread!
> > >
> > > I have created CASSANDRA-14784 to track this.
> > >
> > > Dinesh
> > >
> > >> On Sep 21, 2018, at 9:18 PM, Sankalp Kohli
> > wrote:
> > >>
&g
Thanks for bringing this up, it definitely needs to be discussed.
Last surprise is difficult here, since all major databases have their own
way of doing things and people will just assume that their way is the right
way. On that note, some people will be surprised no matter what we do.
I'd rathe
Recently I reached an inflection point where my annoyance of launching
clusters finally overcame my laziness. I wanted something similar to CCM,
so I wrote it.
The tool was designed for our usage at TLP, which usually means quickly
firing up clusters for running tests. It started out as some scr
I think we should try to do the right thing for the most people that we
can. The number of folks impacted by 64KB is huge. I've worked on a lot
of clusters created by a lot of different teams, going from brand new to
pretty damn knowledgeable. I can't think of a single time over the last 2
years
d
and we never were really explicit that those sort of optimizations would be
excluded after our feature freeze. I don't think they should necessarily
be excluded at this time, but it depends on the size and risk of the patch.
On Sat, Oct 20, 2018 at 8:38 AM Jonathan Haddad wrote:
> I th
is point
> >
> > -0:
> > Sylvaine Lebresne
> >
> > -.5:
> > Jeff Jirsa
> >
> > This
> > (
> https://github.com/aweisberg/cassandra/commit/a9ae85daa3ede092b9a1cf84879fb1a9f25b9dce)
>
> > is a rough cut of the change for the representa
Sounds good to me.
On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith
wrote:
> So, this thread somewhat petered out.
>
> There are still a number of unresolved issues, but to make progress I
> wonder if it would first be helpful to have a vote on ensuring we are ANSI
> SQL 92 compliant for o
Correct.
On Mon, Nov 19, 2018 at 1:02 PM Steinmaurer, Thomas <
thomas.steinmau...@dynatrace.com> wrote:
> Hello,
>
> am I right that Java 11 support will only be in Cassandra 4.0 and not in
> future releases of the 3.11.x series? Just want to be sure.
>
> Thanks,
> Thomas
>
> The contents of this
If nobody has any objections to CASSANDRA-14303 (default RF) being merged
in I can take care of it. It's a significant usability improvement, looks
well tested and will prevent a number of headaches.
I'll try to get to it tomorrow.
Thanks for bringing these up, Vinay.
Jon
On Tue, Nov 20, 2018
they are.
> >
> > --
> > Sylvain
> >
> >
> >> I will make this more explicit for the vote, but just to clarify the
> >> intention so that we are all discussing the same thing.
> >>
> >>
> >>> On 20 Nov 2018, at 14:18, Ariel
My personal preference is to remove labels, but I don't see it as a huge
issue if they stay.
1. A
2. prefer to remove (I suppose I'm a -.1?)
3. +1
4. +1
5. No preference
6. +1
On Wed, Dec 5, 2018 at 11:43 AM jay.zhu...@yahoo.com.INVALID
wrote:
> 1: Component. (A) Multi-select
> 2: Labels: le
+1
On Mon, Dec 17, 2018 at 9:50 AM Blake Eggleston
wrote:
> +1
>
> > On Dec 17, 2018, at 9:31 AM, jay.zhu...@yahoo.com.INVALID wrote:
> >
> > +1
> >
> >On Monday, December 17, 2018, 9:10:55 AM PST, Jason Brown <
> jasedbr...@gmail.com> wrote:
> >
> > +1.
> >
> > On Mon, Dec 17, 2018 at 7:36
+1
On Fri, Jan 4, 2019 at 8:13 AM Ariel Weisberg wrote:
> +1
>
> On Fri, Jan 4, 2019, at 5:49 AM, Sam Tunnicliffe wrote:
> > As per the announcement on 7th December 2018[1], ASF infra are planning
> > to shutdown the service behind git-wip-us.apache.org and migrate all
> > existing repos to gitb
Silence can be interpreted either as non-awareness or implicit approval.
I interpreted (and meant) +1 as "go for it now".
On Fri, Jan 4, 2019 at 8:48 AM Sam Tunnicliffe wrote:
> Yeah, I wasn’t really proposing a vote as like you said, it’s happening
> anyway. I was just going to give a few days
fter the above cassandra-builds commit.
> - https://builds.apache.org/job/Cassandra-Job-DSL/
>
> The only other consideration I can think of after migration is checking
> the git.a.o bare and github mirror post-commit hooks work as expected.
> - http://git.apache.org/cassandra.git/
>
I agree with Stefan, if someone isn't a release manager there's no reason
to add them, and it just increases the surface area for potential attack or
issue.
On Mon, Jan 7, 2019 at 11:35 AM Stefan Podkowinski wrote:
> I don't see any reason to have any keys in there, except from release
> manager
That's a good point. Looking at the ASF docs I had assumed the release
manager was per-project, but on closer inspection it appears to be
per-release. You're right, it does say that it can be any committer.
http://www.apache.org/dev/release-publishing.html#release_manager
We definitely need mor
rust
> database. When gpg key signer changes, users need to modify their trust
> on every node, importing new key(s), in order for packages to
> install/upgrade with apt or yum.
>
> I don't understand how adding keys changes release frequency. Did
> someone request a release to
It's been 5 months and 30+ bug fixes to each branch.
Here's the two changelogs:
https://github.com/apache/cassandra/blob/cassandra-3.0/CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt
How's everyone feel about getting a release out this week / early next
week? Som
I'm very much in favor of a warning, and I lean towards disabling them (and
MVs, while we're at it) by default as well.
I've seen both features be the death of clusters, and are a major risk for
teams that are brand new to Cassandra.
On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña
wrote:
>
Ping on this.
On Mon, Jan 7, 2019 at 5:58 PM Michael Shuler
wrote:
> No problem, thanks for asking :)
>
> Michael
>
> On 1/7/19 6:20 PM, Jonathan Haddad wrote:
> > It's been 5 months and 30+ bug fixes to each branch.
> >
> > Here's the two changelogs:
I'm +1 on the warning for two reasons.
> A cqlsh warning only applies to those that create the sasi via cqlsh.
1. When people are creating their schemas in development, this is usually
the first step. You use the REPL to figure out what you need, then you
copy your schema somewhere else. The wa
In addition to what Jeff mentioned, there was an optimization in 3.4 that
can significantly reduce the number of sstables accessed when a LIMIT
clause was used. This can be a pretty big win with TWCS.
http://thelastpickle.com/blog/2017/03/07/The-limit-clause-in-cassandra-might-not-work-as-you-thi
+1
On Sun, Feb 3, 2019 at 9:44 AM Nate McCall wrote:
> On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler
> wrote:
> >
> > I propose the following artifacts for release as 3.0.18.
> >
> > sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.gi
+1
On Sun, Feb 3, 2019 at 9:35 AM Nate McCall wrote:
> On Sat, Feb 2, 2019 at 4:38 PM Michael Shuler
> wrote:
> >
> > I propose the following artifacts for release as 3.11.4.
> >
> > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.gi
I think having the discussion around EOL is pretty important, in order to
set the right expectations for the community.
Looking at the commits for 2.1, there's hardly any activity going on,
meaning it's effectively been EOL'ed for a long time now. I think it's
better that we be honest with folks
Seems low risk, potentially high reward.
I can run some tests next week to get a rough idea of how compression
ratios differ as well as if there's a difference in performance.
I won't be testing correctness, just looking at the performance profile.
Jon
On Fri, Feb 15, 2019 at 9:56 AM Michael
Agreed with Dinesh and Josh. I would *never* put the audit log back in
Cassandra.
This is extendable, Sagar, so you're free to do as you want, but I'm very
opposed to putting a ticking time bomb in Cassandra proper.
Jon
On Thu, Feb 28, 2019 at 8:38 AM Dinesh Joshi
wrote:
> I strongly echo Jo
, side-channel file storage
> > >> format for transient things like this (hints, batches, audit logs,
> etc)
> > >> could be useful as a first class citizen in the codebase? i.e. a world
> > in
> > >> which we refactored some of the hints-specific reader/
Hey all,
I finally got around to doing some testing. Nothing too crazy, I had it
run on my laptop while I did other things around the house.
Test 1: Inserting Random Data in a K/V table, 10 million inserts
LZ4 compression rate: 0.909857609644112
ZStd: 0.6136099401596449
Test 2: Inserting fairl
; of Zstd compression levels.
>
> Dinesh
>
> > On Mar 1, 2019, at 6:41 PM, Jonathan Haddad wrote:
> >
> > Hey all,
> >
> > I finally got around to doing some testing. Nothing too crazy, I had it
> > run on my laptop while I did other things around the
/CASSANDRA-7622
> >
> > Any insights would be helpful.
> >
> > Thanks!
> > Sagar.
> >
> > On Sat, Mar 2, 2019 at 7:23 AM Jonathan Haddad
> wrote:
> >
> > > Instead of logging to tables, putting a virtual table around the audit
> /
> &
o have a separate
> memtable/sstable for static columns?
>
> Begin forwarded message:
>
> *From: *Jonathan Haddad
> *Subject: **Re: DateTieredCompactionStrategy and static columns*
> *Date: *April 30, 2015 at 3:55:46 PM CDT
> *To: *u...@cassandra.apache.org
> *Reply-To:
> > separate them, since it's easier to reason about and improve their
> distinct
> > characteristics.
> >
> >
> > On Fri, May 1, 2015 at 1:24 AM, graham sanderson
> wrote:
> >
> >> Well you lose the atomicity and isolation, but in this
I'm not sure if the complications surrounding the versioning of the drivers
should be factored into the releases of Cassandra. I think that 3.0
signals a massive change and calling the release containing 8099 a .1 would
be drastically underplaying how big of a release it is - from the
perspective
+1
On Mon, Dec 28, 2015 at 7:04 AM Dave Brosius
wrote:
> +1 now
>
> On 12/28/2015 09:26 AM, Jonathan Ellis wrote:
> > Thrift has been officially frozen for almost two years and unofficially
> for
> > longer. [1] Meanwhile, maintaining Thrift support through changes like
> > 8099 has been a subs
Use local quorum, don't talk to remote dcs.
On Fri, Jan 8, 2016 at 1:41 PM Dominic Chevalier
wrote:
> Hello,
>
> tldr;
>
> It looks like StorageProxy.fetchRows blocking for read responses can get
> pretty bad during quorum reads involving many geographically distant data
> centers. If this is tru
I've been discouraged from contributing to the codebase due to it's lack of
comments, so I +1 this big time.
Some people argue against comments by saying "the code should be self
describing", but that misses the point. The comments should describe the
*intent* of the code, the problem it's mean t
Maybe some brave soul will document the 3.0 on disk format as part of
https://issues.apache.org/jira/browse/CASSANDRA-8700.
On Wed, Jun 15, 2016 at 7:02 AM Christopher Bradford
wrote:
> Consider taking a look at Aaron Morton's dive into the C* 3.0 storage
> engine.
>
>
> http://thelastpickle.com
ded to me yesterday... a helpful first step
> https://github.com/apache/cassandra/blob/cassandra-3.0.0/guide_8099.md
>
> > On Jun 15, 2016, at 9:54 AM, Jonathan Haddad wrote:
> >
> > Maybe some brave soul will document the 3.0 on disk format as part of
> > htt
the wiki for contributors.
> >> On Jun 15, 2016 7:04 PM, "Jonathan Haddad" wrote:
> >>
> >> Definitely required reading for anyone getting into it, plus Aaron's
> post.
> >> I think ideally one day something like this should live in the docs:
(non binding) +1
On Mon, Aug 15, 2016 at 7:23 AM Jonathan Ellis wrote:
> A long time ago, I was a proponent of keeping most development discussions
> on Jira, where tickets can be self contained and the threadless nature
> helps keep discussions from getting sidetracked.
>
> But Cassandra was a
I don't know about everyone else, but a big deterrent in contributing code
to Cassandra for me (over the last 4 years or so) is the massive amount of
ramp up that needs to happen in order to get started working on something
meaningful. This comes in a variety of forms - understanding how test
fail
+1 to officially supporting GitHub PRs.
On Fri, Aug 26, 2016 at 11:07 AM Jason Brown wrote:
> It seems to me we might get more contributions if we can lower the barrier
> to participation. (see Jeff Beck's statement above)
>
> +1 to Aleksey's sentiment about the Docs contributions.
>
> On Fri, A
A daily digest of new issues would be incredible. A non-binding +1 from
this guy.
On Mon, Aug 29, 2016 at 8:58 AM Jeremy Hanna
wrote:
> Currently we have a mailing list (commits@) that includes commit messages
> as well as all updates to Jira tickets. However for the purpose of staying
> up t
gt;= -24h ORDER BY createdDate DESC
>
> When viewing your filter, go to Details > New Subscription and set it up to
> run once a day and you're set!
>
> Hope it helps,
>
> Russ
>
> On Mon, Aug 29, 2016 at 10:45 AM, Jonathan Haddad
> wrote:
>
> > A dai
Unfortunately CASSANDRA-11618 was fixed in 3.6 but was not back ported to
3.5 as well, and it makes Cassandra effectively unusable if someone is
using any of the 4 types affected in any of their schema.
I have cherry picked & merged the patch back to here and will put it in a
JIRA as well tonight,
supplied - that bug is a ticking time bomb for anyone that
installs it.
On Wed, Sep 14, 2016 at 8:12 PM Michael Shuler
wrote:
> What's preventing the use of the 3.6 or 3.7 releases where this bug is
> already fixed? This is also fixed in the 3.0.6/7/8 releases.
>
> Michael
hough, this highlights the fact that tick/tock may not be the
> best option long term. We’ve tried it for a year, perhaps we should instead
> discuss whether or not it should continue, or if there’s another process
> that gives us a better way to get useful patches into versions people are
>
ople.
The follow up to 3.4 (3.5) should have been 3.4.1, following semver, so
people know it's bug fixes only to 3.4.
Jon
On Wed, Sep 14, 2016 at 10:37 PM Jonathan Haddad wrote:
> In this particular case, I'd say adding a bug fix release for every
> version that's affected
of dealing with feature creep
> > and
> > > testing, or we need to better define what gets backported, because the
> > > community needs a stable version to run, and running latest odd release
> > of
> > > tick/tock isn’t it.
> > >
> > > - Jeff
> &g
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
>
I've worked on a few projects where we've had a branch that new stuff went
in before merging to master / trunk. What you've described reminds me a
lot of git-flow (http://nvie.com/posts/a-successful-git-branching-model/)
although not quite the same. I'll be verbose in this email to minimize the
r
Sorry, in my TL;DR I forgot release frequent alphas (nightly / weekly /
whatever schedule you want)
On Fri, Sep 16, 2016 at 8:18 AM Jonathan Haddad wrote:
> I've worked on a few projects where we've had a branch that new stuff went
> in before merging to master / trunk. What
elocity of the project will increase - which was the original goal of
Tick Tock.
Jon
On Fri, Sep 16, 2016 at 9:04 AM Sylvain Lebresne
wrote:
> On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad
> wrote:
>
> >
> > This is a different mentality from having a "features&quo
08 AM Jonathan Ellis wrote:
> On Fri, Sep 16, 2016 at 11:36 AM, Jonathan Haddad
> wrote:
>
> > What I was trying to suggest is that the *goal* of trunk should always be
> > releasable, and the alpha releases would be the means of testing that.
> If
> > the goal is to al
1 - 100 of 167 matches
Mail list logo
