If you donate Thread per core to C*, I am sure someone can help you review
it and get it committed.
On Thu, Apr 19, 2018 at 11:15 AM, Ben Bromhead wrote:
> Re #3:
>
> Yup I was thinking each shard/port would appear as a discrete server to the
> client.
>
> If the per port suggestion is unaccepta
Is one of the “abuse” of Apache license is ScyllaDB which is using Cassandra
but not contributing back?
Happy to be proved wrong as I am not a lawyer and don’t understand various
licenses ..
> On Apr 23, 2018, at 16:55, Dor Laor wrote:
>
>> On Mon, Apr 23, 2018 at 4:13 PM, Jonathan Haddad wro
effort to the C* server
>
> But it's reasonable that a major portion of Scylla's business model is
> profiting off those huge efforts other companies have made?
>
> Seems a little hypocritical to me.
>
>> On Mon, Apr 23, 2018, 8:18 PM Dor Laor wrote:
>>
>>
Hi,
The idea of combining read with prepare sounds good. Regarding reducing
the commit round trip, it is possible today by giving a lower consistency
level for commit I think.
Regarding EPaxos, it is a large change and will take longer to land. I
think we should do this as it will help lower t
I agree with Stefan that we should use incremental repair and use patches
from Marcus to drop tombstones only from repaired data.
Regarding deep repair, you can bump the read repair and run the repair. The
issue will be that you will stream lot of data and also your blocking read
repair will go up
ourse important. This isn't meant to discourage
development – only to enable us to focus on testing and hardening 4.0 to
deliver Cassandra's most stable major release. We would like to see
adoption of 4.0 happen much more quickly than its predecessor.
Thanks for considering this proposal,
Sankalp Kohli
&e=
> >
> > >
> > > Jon
> > >
> > >
> > > On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie
> > > wrote:
> > >
> > > > Why not just branch a 4.0-rel and bugfix there and merge up while
> > still
> > >
Hi Kurt,
Thank you for your feedback. I am reading your comment as +1 on
the idea of working on making a solid release but +0 on branching model. Is
that correct?
Thanks,
Sankalp
On Tue, Jul 3, 2018 at 10:09 PM kurt greaves wrote:
> >
> > but by committing to reserving trunk for stabi
>
> So long as either/both are communicated to the contributors, the only
> difference is in where new feature work gets accumulated: will stay a bit
> longer in personal branches in the latter way.
>
> —
> AY
>
> On 4 July 2018 at 01:30:40, sankalp kohli (kohlisank...
uot;keep doing things the way we did but message strongly
> that we won't be reviewing new things until 4.0 is stable".
>
> On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli
> wrote:
>
> > Does anyone has any more feedback on this?
> >
> > > On Jul 4, 2018,
on changing the branching strategy in a way that prevents
> people from working and collaborating on an Apache project.
>
> On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli
> wrote:
> >
> > I did not see a -1 but all +0s and a few +1s.
> >
> > On Mon, Jul 9, 2018 at
t be banned from new bringing in new
> features if that's what they want to do.
>
> You're essentially giving a blanket -1 to all new features for a 3-6
> month period.
> On Mon, Jul 9, 2018 at 10:44 AM sankalp kohli
> wrote:
> >
> > How is this preventing some
oject’s process
> (making trunk stable at all times going forward), then I don’t think
> there’s a reason why branching would detract from these efforts. In other
> words if we’re just trying to say that we want to focus on stabilization
> for the alpha/beta/rc of 4.0, then I would prefer b
p
> > in the right direction. In the early days of the project I tried to do
> > this in a small way by testing the Hadoop support for every release
> (major
> > and minor) since it wasn’t on everyone’s radar but was important to me.
> > Then I would vote with a non-binding
Hi,
As discussed in the thread[1], we are proposing that we will not branch
on 1st September but will only allow following merges into trunk.
a. Bug and Perf fixes to 4.0.
b. Critical bugs in any version of C*.
c. Testing changes to help test 4.0
If someone has a change which does not fall un
We will be in this state till beta is reached.
On Wed, Jul 11, 2018 at 2:46 PM sankalp kohli
wrote:
> Hi,
> As discussed in the thread[1], we are proposing that we will not
> branch on 1st September but will only allow following merges into trunk.
>
> a. Bug and Perf fi
merging non code will be allowed correct
On Thu, Jul 12, 2018 at 9:41 AM Stefan Podkowinski wrote:
> +1
>
> (assuming merging patches on documentation will always be possible, as
> it's not effecting the code base)
>
>
> On 11.07.18 23:46, sankalp kohli wrote:
>
tia.jayd...@gmail.com>
> > wrote:
> >
> >> +1
> >>
> >> On Wed, Jul 11, 2018 at 2:46 PM sankalp kohli
> >> wrote:
> >>
> >>> Hi,
> >>>As discussed in the thread[1], we are proposing that we will not
> >> branc
Hi,
We are 7 weeks away from 4.0 freeze and there are ~150 JIRAs waiting
for review. It is hard to know which ones should be prioritized as some of
them could be not valid(fixes 2.0 bug), some of them will have the assignee
who no longer is active, etc.
If anyone is *not* getting traction on t
Hi,
Apache Cassandra Blog is now live. Check out the first blog post.
http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html
Thanks,
Sankalp
I am bumping this thread because patch has landed for this with repair
functionality.
I have a following proposal for this which I can put in the JIRA or doc
1. We should see if we can keep this in a separate repo like Dtest.
2. It should have its own release process.
3. It should have integr
The thread for side car is months old and no one has opposed to it and hence
someone developed it. I am not sure how else you get consensus.
Regarding separate repo, how do we get consensus?
> On Aug 18, 2018, at 05:19, Stefan Podkowinski wrote:
>
> I don't see that we have reached sufficien
imply that it's also going to
> become the de facto official side-car solution, which doesn't feel right
> to me, given that the proposed patch isn't even reviewed and hasn't
> received much feedback yet.
>
>
>> On 18.08.18 17:44, Sankalp Kohli wrote:
>
wrote:
>
> On Fri, 17 Aug 2018, at 14:27, Sankalp Kohli wrote:
> > I am bumping this thread because patch has landed for this with repair
> > functionality.
>
>
> We are looking to contribute Reaper to the Cassandra project.
>
> Looking at the patch it's very s
Hi,
I am starting a new thread to get consensus on where the side car
should be contributed.
Please send your responses with pro/cons of each approach or any other
approach. Please be clear which approach you will pick while still giving
pros/cons of both approaches.
Thanks.
Sankalp
out
> >> of reach within a single repo (indeed the current patch already creates
> a
> >> separate jar, and we could create a separate .deb reasonably easily).
> >> Personally I think having a separate .deb/.rpm is premature at this
> point
> >> (for comp
nly separated things when
> coupling is avoidable. As such I would prefer the sidecar to live in a
> separate new repo, while still being part of the C* project.
> > >
> > > —
> > > AY
> > >
> > > On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank..
8 at 3:01 PM sankalp kohli wrote:
>>
>> Separate repo is in a majority so far. Please reply to this thread with
>> your responses.
>
> I think it makes sense for the code, project, and workflows to be
> (de|loosely)-coupled, so the repo should be as well.
>
> +1 for a s
We can wait for a week post Freeze so everyone can participate however we need
to decide after that so we can make progress.
I am leaning towards piecemeal approach so we can review the code and pick best
of all 3 options
> On Aug 29, 2018, at 00:26, kurt greaves wrote:
>
> 2c: There's a lot
A good time for NGCC will be closer to 4.0 release where we can plan what
we can put it on 4.0-next. I am not sure doing it now is going to help when
we are months away from 4.0 release.
On Fri, Aug 31, 2018 at 7:42 AM Jay Zhuang wrote:
> Are we going to have a dev event next month? Or anything
; > next release. Let's focus on one thing at a time.
> >
> > On Wed, Sep 5, 2018 at 12:29 PM sankalp kohli
> > wrote:
> >
> > > A good time for NGCC will be closer to 4.0 release where we can plan
> what
> > > we can put it on 4.0-next. I am not
Thanks for starting this Jon.
Instead of saying "I tested streaming", we should define what all was
tested like was all data transferred, what happened when stream failed,
etc.
Based on talking to a few users, looks like most testing is done by doing
an operation or running a load and seeing if it
Most of the discussions have been around whether we take some side car or
do a cherry pick approach where we add a feature at a time to side car and
use the best implementation.
We have been discussing this first in April and now for several days. I
think we all want some progress here. We will sta
I agree with Jon and I think folks who are talking about tech debts in
Reaper should elaborate with examples about these tech debts. Can we be
more precise and list them down? I see it spread out over this long email
thread!!
On Sun, Sep 9, 2018 at 6:29 AM Elliott Sims wrote:
> A big one to add
Hi Nate,
Looks like we had a lot of discussion here and everyone seems
to be in favor. What is the next step? A vote?
Thanks,
Sankalp
On Fri, Aug 31, 2018 at 10:48 PM Alex Lourie wrote:
> Same here. I've been working on this project for a bit now, and I'm
> planning to continue and c
Hi,
Community has been discussing about Apache Cassandra Management process
since April and we had lot of discussion about which approach to take to
get started. Several contributors have been interested in doing this and we
need to make a decision of which approach to take.
The current approa
Great..please start the vote to get consensus.
On Wed, Sep 12, 2018 at 8:06 AM Nate McCall wrote:
> Yep - that sounds like the best next step to me.
>
> (apologies for spotty comms folks - been/still on vacation).
> On Wed, Sep 12, 2018 at 8:03 AM sankalp kohli
> wrote:
+1
On Wed, Sep 12, 2018 at 8:12 AM Nate McCall wrote:
> This will be the same process used for dtest. We will need to walk
> this through the incubator per the process outlined here:
>
> https://incubator.apache.org/guides/ip_clearance.html
>
> Pending the outcome of this vote, we will create th
Hi Sylvain,
I would appreciate if we can give feedback on the
discussion threads and not wait for vote threads. I made it clear in the
discussion thread that we will start a vote!!
Thanks,
Sankalp
On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa wrote:
> On Wed, Sep 12, 2018 at 12:41
ink it'll somehow produce a perfect codebase?
>
>
>
>
>
> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli
> wrote:
>
> > Hi Sylvain,
> > I would appreciate if we can give feedback on the
> > discussion threads and not wait for vote thr
Also my vote is same as Jeff. d but would slightly prefer b. It is
important we make progress as we have been discussing this since April!!
On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli
wrote:
> The last email on the thread was 3 days ago and I made it clear days back
> that we should v
PM Joshua McKenzie
wrote:
> >
> > It is important we make progress as we have been discussing this since
> > April!!
>
>
> The discussion was making progress. Just because you want things to happen
> faster is no reason to force an early vote.
>
> On Wed, S
d I have a newborn at home. Not a lot of time for
> people to respond that have other things going on in life. :)
>
> On Wed, Sep 12, 2018 at 5:13 PM sankalp kohli
> wrote:
>
> > If you think vote is being forced, why not reply to my email on another
> > thread when I sa
Hi Joey,
The intention of this vote is to do what you are saying. We
want to see movement on this and not drag it for months. I am happy to drag
it for few more weeks if thats is what we agree on.
Regarding evaluating different options, if we decide on option a, we can
always do that
un, Sep 9, 2018 at 9:13 AM sankalp kohli wrote:
> I agree with Jon and I think folks who are talking about tech debts in
> Reaper should elaborate with examples about these tech debts. Can we be
> more precise and list them down? I see it spread out over this long email
> thread!!
>
I am hoping all the folks who are saying we should not vote will drive the
other thread. Also note that there is consensus about doing a side car but
no consensus on which approach to take. I hope not deciding which approach
is not a poison pill for side car!!
On Wed, Sep 12, 2018 at 4:11 PM Mi
The link to the document is available in the other thread. Comparisons are
available in other thread as well.
> On Sep 12, 2018, at 16:29, Mick Semb Wever wrote:
>
>
>> I am hoping all the folks who are saying we should not vote will drive the
>> other thread. Also note that there is consens
ssandra.
On Wed, Sep 12, 2018 at 3:49 PM sankalp kohli
wrote:
> (Using this thread and not the vote thread intentionally)
> For folks talking about vote being rushed. I would use the email from
> Joseph to show this is not rushed. There was no email on this thread for 4
> months until
questions that Jon and others have raised, when I +1, my
> > intention is to fully contribute and stay with this community. That said,
> > things feel rushed for some but for me it feels like analysis paralysis.
> > We're looking for actionable feedback and to discuss the manage
+1 to lowering it.
Thanks Jon for starting this.We should create a JIRA to find what other
defaults we need revisit. (Please keep this discussion for "default token"
only. )
On Fri, Sep 21, 2018 at 8:26 PM Jeff Jirsa wrote:
> Also agree it should be lowered, but definitely not to 1, and probabl
gt;
> Next week I can try to put together something a little more convincing.
> Weekend time.
>
> Jon
>
>
> On Fri, Sep 21, 2018 at 8:45 PM sankalp kohli
> wrote:
>
>> +1 to lowering it.
>> Thanks Jon for starting this.We should create a JIRA to find what o
s suggestion is already part of the doc. If there
>> aren't further objections could we move this discussion over to the jira
>> (CASSANDRA-14395)?
>>
>> Dinesh
>>
>>> On Sep 18, 2018, at 10:31 AM, sankalp kohli
>> wrote:
>>>
>>>
Thanks Dinesh for looking at the tools and thanks Mick for listing them
down.
Based on Dinesh response, is it accurate to say that for bulk
functionality, we have evaluated the tools listed by the community? If
anything is missed we should discuss it as we want to make sure we looked
at all aspects
Anant Corporation
> 1010 Wisconsin Ave NW, Suite 250
> Washington, D.C. 20007
>
> We build and manage digital business technology platforms.
>> On Sep 29, 2018, 5:29 PM -0400, sankalp kohli ,
>> wrote:
>> Thanks Dinesh for looking at the tools and thanks Mick for listin
Hi Mick,
Any other feedback?
Thanks,
Sankalp
On Sun, Sep 30, 2018 at 8:54 AM Sankalp Kohli
wrote:
> Thank you for the feedback. There are lot of advantages of doing this in
> Apache and you can read the thread to find more. The main one is to not
> divide the energ
Will GossipingPropertyFileSnitch not be vulnerable to Gossip bugs where we
lose hostId or some other fields when we restart C* for large
clusters(~1000 instances)?
On Tue, Oct 16, 2018 at 7:59 AM Jeff Jirsa wrote:
> We should, but the 4.0 features that log/reject verbs to invalid replicas
> solv
Hi Mick,
Can you share the link to cwiki if you have started it ?
Thanks
Sankalp
> On Oct 4, 2018, at 5:20 PM, Mick Semb Wever wrote:
>
> Dinesh / Sankalp,
>
> My suggestion was to document the landscape in hope and an attempt to better
> understand the requirements possible to
information
> from gossip yet, it should not be a problem. (As far as I know GPFS does
> this, but I have not done extensive code diving or testing to make sure all
> edge cases are covered there)
>
> -Jeremiah
>
> > On Oct 16, 2018, at 11:56 AM, sankalp kohli
> wrote:
>
(We should definitely harden the definition for freeze in a separate thread)
My thinking is that this is the best time to do this change as we have not even
cut alpha or beta. All the people involved in the test will definitely be
testing it again when we have these releases.
> On Oct 19, 2018
Gossip snitch
:)
> On Oct 19, 2018, at 2:41 PM, Jeremy Hanna wrote:
>
> Do you mean to say that during host replacement there may be a time when the
> old->new host isn’t fully propagated and therefore wouldn’t yet be in all
> system tables?
>
>> On Oct 17, 2018
ropertyFileSnitch as the token(s) for this
> host will be missing from gossip/system.peers?
>
> Em sáb, 20 de out de 2018 às 00:34, Sankalp Kohli
> escreveu:
>
> > Say you restarted all instances in the cluster and status for some host
> > goes missing. Now when y
ile, but reading
> only the dc/rack info about the local node.
>
> Em seg, 22 de out de 2018 às 16:58, sankalp kohli
> escreveu:
>
> > Yes it will happen. I am worried that same way DC or rack info can go
> > missing.
> >
> > On Mon, Oct 22, 2018 at 12:52 PM
now we have not seen
> any “lost” rack/DC information during such testing.
>
> -Jeremiah
>
>> On Oct 22, 2018, at 5:46 PM, sankalp kohli wrote:
>>
>> We will have similar issues with Gossip but this will create more issues as
>> more things will be relied o
n you start a host replacement, the new host won’t
learn about the host whose status is missing and the view of this host will
be wrong."
- CASSANDRA-10366
On Mon, Oct 22, 2018 at 7:22 PM Sankalp Kohli
wrote:
> I will send the JIRAs of the bug which we thought we have fixed but it
&
+1 to fallback and like I said before removing PFS is a good idea as long it is
safe
> On Oct 22, 2018, at 7:41 PM, Jeff Jirsa wrote:
>
> On Mon, Oct 22, 2018 at 7:09 PM J. D. Jordan
> wrote:
>
>> Do you have a specific gossip bug that you have seen recently which caused
>> a problem that wo
in to make sure, and this is the first email I have with one.
>
> -Jeremiah
>
>> On Oct 22, 2018, at 9:37 PM, sankalp kohli wrote:
>>
>> Here are some of the JIRAs which are fixed but actually did not fix the
>> issue. We have tried fixing this by several pa
This is good start and we should use this approach each component. Once we
have volunteers for each area, it will be important to also publish a
confluence page per component by the volunteer so we can know/discuss how
it was tested.
On Wed, Nov 7, 2018 at 12:14 PM Joseph Lynch wrote:
> Followin
Should we use confluence page to sign them up for this testing?
https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+QA+Signup
On Thu, Nov 8, 2018 at 2:07 PM Nate McCall wrote:
> [- cassandra-users]
> Hi Yuji,
> Thanks so much for working on this! Any fault injection testing is
> certainly
Hi Mick,
Any feedback?
Also pinging this thread after a week for others to give feedback
> On Nov 6, 2018, at 1:40 AM, Dinesh Joshi
> wrote:
>
> Hi all,
>
> Joey, Vinay & I have fleshed out the Management process proposal as the very
> first CIP document (with Jason’s inputs).
We already should be taking correctness and perf changes and I am +1 on taking
operational tickets. Agree with Josh that the only exception will be if it
causes disruption in testing.
I think as a project we should be more open to operational issues as having a
fork is not ideal.
Regarding ti
Inter-node messaging is rewritten using Netty in 4.0. It will be better to
test it using that as potential changes will mostly land on top of that.
On Mon, Nov 26, 2018 at 7:39 AM Yuji Ito wrote:
> Hi,
>
> I'm investigating LWT performance with C* 3.11.3.
> It looks that the performance is bound
I have following initial comments on the proposal.
1. Creating a JIRA should have few fields mandatory like platform, version,
etc. We want to put less burden on someone creating a ticket but I feel these
are required for opening bugs.
2. What is the flow when a non committer does the first pa
If no one has more feedback, we should create JIRAs for all the subtasks
discussed in the proposal. I can see JIRA for Bulk command but not others.
On Mon, Nov 19, 2018 at 2:12 AM dinesh.jo...@yahoo.com.INVALID
wrote:
> Thanks, Mick & Stefan for your inputs. What should we do as next steps to
>
+1
On Tue, Dec 18, 2018 at 9:16 PM Ariel Weisberg wrote:
> +1
>
> On Mon, Dec 17, 2018, at 10:19 AM, Benedict Elliott Smith wrote:
> > I propose these changes
> > <
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals>*
>
> > to the Jira Workflow for the project. The
If we want to put a warning, we should list in a doc all the open issues it
has along with explanation of how it can impact. We have a few in the first
email of this thread but we should put it in a doc for people to know what
are the issues and if they want to take that risk.
On Wed, Jan 16, 20
this doc, we can maybe amend the
>> warning to include a link to the doc.
>>
>> Now that the number of experimental feature flags is growing we should
>> perhaps unify all flags in a "experimental features" section on
>> cassandra.yaml to allow easily loc
I think we should wait for testing doc on confluence to come up and discuss
what all needs to be added there to gain confidence.
If the work is more to split the patch into smaller parts and delays 4.0 even
more, can we use time in adding more test coverage, documentation and design
docs to th
Hi,
Is there a page where it is written what is expected from an alpha,
beta, rc and a 4.0 release?
Also how are we coming up with Q4 2019 timeline. Is this for alpha, beta,
rc or 4.0 release?
Thanks,
Sankalp
On Thu, May 23, 2019 at 11:27 AM Attila Wind wrote:
> +1+1+1 I read a blog post wa
>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
> > > >
> > > > I think we need to define the various release types and the exit
> > criteria
> > > > for each type of release. Anybody
Hi All,
There are projects (like k8s[1]) which do regular meetings using
video conferencing tools. We want to propose such a meeting for Apache
Cassandra once a quarter. Here are some of the initial details.
1. A two hour meeting once a quarter starting at 9am Pacific. We can later
move t
t;
> > > > Thanks for initiating this conversation Sankalp. On the ASF front, I
> > > think
> > > > we need to ensure that non-Pacific time participants can also
> > participate
> > > > in the discussions. So posting the notes and opening up discuss
> > > > we need to ensure that non-Pacific time participants can also
> > participate
> > > > in the discussions. So posting the notes and opening up discussions
> > after
> > > > the meet up to dev@ would be a great way of making sure everyone can
>
assuming shape of this meeting will keeping changing over
time based on feedback.
On Mon, Aug 12, 2019 at 4:33 PM sankalp kohli
wrote:
> Thanks Patrick for helping with logistics. We can certainly use your
> resources unless someone objects
>
> On Mon, Aug 12, 2019 at 10:42 AM Pat
A different repo will be better
> On Aug 22, 2019, at 6:16 AM, Per Otterström
> wrote:
>
> Very powerful tool indeed, thanks for sharing!
>
> I believe it is best to keep tools like this in different repos since
> different tools will probably have different life cycles and tool chains.
>
Will we cut alpha1 and later alpha releases from trunk or create a new
branch?
On Friday, August 30, 2019, Nate McCall wrote:
> >
> >
> > I think the next decision is should we just cut 4.0-alpha1 now given
> > that Michael has some cycles regardless of the known issues and start
> > using th
I do not think we should branch and is -1 on it. The reason we have trunk
frozen was for our focus to be on 4.0. I think we still need that focus till a
few more releases like these.
> On Aug 30, 2019, at 12:24 AM, Nate McCall wrote:
>
> On Fri, Aug 30, 2019 at 10:11 AM Benedict Elliott Smit
Can we have a vote once the tests pass? I know we all are including me are
excited about cutting this alpha but we cannot cut a release with test failing
or not being run due to some Java home issue.
If people have already started using the alpha artifacts, then I suggest we
make test passing
Another thing which it should solve is someone proposing an alternate very
late into development which could be provided sooner. If someone has a good
feedback which could not have been given at the time of CEP then that is
good. We don't want situations where contributors have done the CEP and
the
;>>> another
> >>>>>> pass through. There has been a lot of progress here, but I’ve
> >>> let
> >>>>> perfect
> >>>>>> be the enemy of the good in getting updates out. I’ll complete
> >>> that
> >>&
Please email to user list as I do not think this question is for dev list.
On Wed, Sep 18, 2019 at 10:17 AM Bhavesh Prajapati
wrote:
> Hi,
>
> I am looking for Cassandra GUI that supports cqlsh connection to Cassandra
> node through bastion/jump host using ssh key.
>
> Thanks,
> Bhavesh
>
Can we put it on vote(if required) if no one has more comments?
On Wed, Sep 18, 2019 at 5:44 PM Jonathan Koppenhofer
wrote:
> Nice work... I like this and have no additions/comments at this time
>
> On Wed, Sep 18, 2019, 4:18 PM sankalp kohli
> wrote:
>
> > We added and ch
Let’s put this to vote next week unless someone thinks it is not required
> On Sep 25, 2019, at 10:56 AM, sankalp kohli wrote:
>
>
> Can we put it on vote(if required) if no one has more comments?
>
>> On Wed, Sep 18, 2019 at 5:44 PM Jonathan Koppenhofer
>> wr
Hi,
We have discussed in the email thread[1] about Apache Cassandra Release
Lifecycle. We came up with a doc[2] for it. Please vote on it if you agree
with the content of the doc[2].
Thanks,
Sankalp
[1]
https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91
ject need to figure out how to help
> > them do this.
> >
> >
> > On 30/09/2019, 14:57, "Joshua McKenzie" wrote:
> >
> > For what it's worth, lazy consensus is a very important concept in
> the
> > Apache Way <
> https://communit
Vote will be open for 72 hours.
On Mon, Sep 30, 2019 at 12:09 PM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:
> +1
>
> On Mon, Sep 30, 2019 at 12:00 PM Nate McCall wrote:
>
> > +1
> >
> > On Tue, Oct 1, 2019 at 7:52 AM sankalp kohli
> &
lear what was voted on.
>
>
> On 30/09/2019, 20:10, "Sumanth Pasupuleti" <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> +1
>
> On Mon, Sep 30, 2019 at 12:00 PM Nate McCall
> wrote:
>
> > +1
> >
> >
Hi,
We have discussed in the email thread[1] about Apache Cassandra Release
Lifecycle. We came up with a doc[2] for it. We have finalized the doc
here[3] Please vote on it if you agree with the content of the doc [3].
We did not proceed with the previous vote as we want to use confluence for
i
v@cassandra.apache.org
> > > Subject: Re: [VOTE] Apache Cassandra Release Lifecycle
> > >
> > > What exactly will be the implication of the outcome of this vote, in
> > > case the content is agreed upon? What's the proposal of the voting?
> > >
> &
xt bug fix version will be 4.1? There will be no minor
>> feature
>>>releases like we did with 3.x.0/2.x.0?
>>>
>>>Deprecated:
>>>"Through a dev community voting process, EOL date is determined for
>>> this
>>> rele
Vote passes with 11 +1 and no -1
On Thu, Oct 10, 2019 at 2:41 PM Jordan West wrote:
> +1 nb
>
> On Wed, Oct 9, 2019 at 11:00 PM Per Otterström
> wrote:
>
> > +1 nb
> >
> > -Original Message-
> > From: Mick Semb Wever
> > Sent: den 10 oktober 2019 07:08
> > To: dev@cassandra.apache.org
1 - 100 of 181 matches
Mail list logo
