--
Jeff Jirsa
On Apr 10, 2018, at 5:24 PM, Josh McKenzie wrote:
>>
>> 50'ish days is too short to draw a line in the sand,
>> especially as people balance work obligations with Cassandra feature
>> development.
>
> What's a reasonable alternative / compromise for this? And what
> non-disru
Also in this time we should try to see who can do 3 things I mentioned in my
earlier email
> On Apr 10, 2018, at 17:50, Sankalp Kohli wrote:
>
> I think moving it to August/Sept will be better
>
> On Apr 10, 2018, at 17:24, Josh McKenzie wrote:
>
>>>
>>> 50'ish days is too short to draw a
I think moving it to August/Sept will be better
On Apr 10, 2018, at 17:24, Josh McKenzie wrote:
>>
>> 50'ish days is too short to draw a line in the sand,
>> especially as people balance work obligations with Cassandra feature
>> development.
>
> What's a reasonable alternative / compromise f
My two cents as a (relatively small) user. I'm coming at this from the
ops/user side, so my apologies if some of these don't make sense based on a
more detailed understanding of the codebase:
Repair is definitely a major missing piece of Cassandra. Integrated would
be easier, but a sidecar might
>
> 50'ish days is too short to draw a line in the sand,
> especially as people balance work obligations with Cassandra feature
> development.
What's a reasonable alternative / compromise for this? And what
non-disruptive-but-still-large patches are in flight that we would want to
delay the line i
Seriously, what's the rush to branch? Do we all love merging so much we
want to do a few more times just for the sake of merging? If nothing
diverges, there's nothing gained from the branch, and if it did diverge, we
add work for no real gain.
Beyond that, I still don't like June 1. Validating rel
A lot of good points and everyone's input is really appreciated.
So it sounds like we are building consensus towards June 1 for 4.0
branch point/feature freeze and the goal is stability. (No one has
come with a hard NO anyway).
I want to reiterate Sylvain's point that we can do whatever we want i
Hi Hitesh,
This list is for conversations regarding Cassandra development. Can
you subscribe and post this to us...@cassandra.apache.org instead? You
will get a much wider audience when you do.
On Tue, Apr 10, 2018 at 10:45 PM, hitesh dua wrote:
> Hi,
> My Compression strategy in Production wa
Hi,
I am +1 on freezing features at some point.
Here are my thoughts
1. The reason it took 1.5 years b/w 3.0 and 4.0 is because 3.0 was
released(not cut) too early. There were so many critical bugs in it for
months after the release. Most people have just finished or about to
upgrade to 3.0. (
On Mon, Apr 9, 2018 at 3:56 PM, Jonathan Haddad wrote:
[ ... ]
> If they're not close to finished now why even consider them for
> the 4.0 release? They're so core they should be merged into trunk at the
> beginning of the cycle for the follow up release in order to get as much
> exposure as po
Hi,
My Compression strategy in Production was *LZ4 Compression. *But I modified
it to *Deflate *using alter command
For compression change, we have to use *nodetool Upgradesstables *to
forcefully upgrade the compression strategy on all sstables
But once upgradesstabloes command completed on all
On Mon, Apr 9, 2018 at 10:56 PM Jonathan Haddad wrote:
> There's always more stuff to try to shoehorn in. We've done big releases
> with all the things, it never was stable. We tried the opposite end of the
> spectrum, release every month, that really wasn't great either. Personally
> I'd be O
> I'd like to see pluggable storage and transient replica tickets land, for
> starters.
So after all the fuss and scandal about incremental repair and MV not
stable and being downgraded to experimental, I would like to suggest that
those new features are also flagged as experimental for some time
13 matches
Mail list logo
