+1 to all
On Thu, Oct 14, 2021 at 11:57 AM C. Scott Andreas
wrote:
> 1. +1nb
> 2. +1nb
> 3. +1nb
>
> It’s been encouraging to follow discussion advancing potential
> enhancements to this proposal on the other threads.
>
> I disagree that it is a good outcome for the project and the Apache
> Cass
Congratulations Yifan.
On Mon, Dec 21, 2020 at 9:10 AM Benjamin Lerer
wrote:
> The PMC's members are pleased to announce that Yifan Cai has accepted the
> invitation to become committer last Friday.
>
> Thanks a lot, Yifan, for everything you have done!
>
> Congratulations and welcome
>
> The
Congratulations everyone.
On Wed, Dec 16, 2020 at 11:53 AM Lorina Poland wrote:
> I'm really excited to see these four folks become committers!
> Congratulations!
>
> Lorina Poland
>
>
>
> On Wed, Dec 16, 2020 at 11:16 AM Paulo Motta
> wrote:
>
> > Great news, congratulations to the new committ
s,
Sankalp
On Thu, Sep 24, 2020 at 10:50 AM Brandon Williams wrote:
> On Thu, Sep 24, 2020 at 12:22 PM sankalp kohli
> wrote:
> >
> > Hi Brandon,
> > In all respect, we need to discuss and vote before we
> > create a new branch. So it i
Hi Brandon,
In all respect, we need to discuss and vote before we
create a new branch. So it is best if we do that instead of creating
branches. Freeze is a symptom not a cause so if we dont like the symptom,
we should see how to fix the cause. Are we fine having a database releas
+1
On Wed, Sep 16, 2020 at 10:07 AM Ekaterina Dimitrova
wrote:
> +1 (non-binding)
>
> On Wed, 16 Sep 2020 at 12:52, Dinesh Joshi wrote:
>
> > +1
> >
> >
> >
> > Dinesh
> >
> >
> >
> > > On Sep 16, 2020, at 9:30 AM, Joshua McKenzie
> > wrote:
> >
> > >
> >
> > > +1
> >
> > >
> >
> > >
> >
> >
+1 to the blog post
On Thu, Aug 27, 2020 at 10:53 AM Jeff Jirsa wrote:
> I don't have any questions, but datastax folks: thanks for funding stuff
> like this.
>
> (I'd love to see it as a blog post, I'd also love to see people internalize
> the negative feedback and assumed features and determin
+1
On Mon, Jul 20, 2020 at 10:58 AM Blake Eggleston
wrote:
> +1
>
> > On Jul 20, 2020, at 9:56 AM, Jon Haddad wrote:
> >
> > +1, thanks Mick for rerolling.
> >
> > On Mon, Jul 20, 2020 at 6:42 AM Joshua McKenzie
> > wrote:
> >
> >> +1
> >>
> >> On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani wro
Can you please allow comments on the doc so we can leave feedback.
On Mon, Jul 13, 2020 at 2:16 PM Joshua McKenzie
wrote:
> Link:
>
> https://docs.google.com/document/d/1ktuBWpD2NLurB9PUvmbwGgrXsgnyU58koOseZAfaFBQ/edit#
>
>
> Myself and a few other contributors are working with this point of vie
I see this discussion as several decisions which can be made in small
increments.
1. In release cycles, when can we propose a feature to be deprecated or
marked experimental. Ideally a new feature should come out experimental if
required but we have several who are candidates now. We can work on
i
Hi,
I think we should revisit all features which require a lot more work to
make them work. Here is how I think we should do for each one of them
1. Identify such features and some details of why they are deprecation
candidates.
2. Ask the dev list if anyone is willing to work on improving the
+1
On Wed, Jun 24, 2020 at 8:37 AM Jake Luciani wrote:
> +1 (b)
>
> On Wed, Jun 24, 2020 at 9:59 AM Joshua McKenzie
> wrote:
>
> > A reminder: this vote will close at midnight PST today in roughly 17
> hours.
> >
> >
> > On Mon, Jun 22, 2020 at 2:20 PM J. D. Jordan
> > wrote:
> >
> > > +1 non-
Hi,
I want to share some of the serious issues that were found and fixed in
3.0.x. I have created this list from JIRA to help us identify areas for
validating 4.0. This will also give an insight to the dev community.
Let us know if anyone has suggestions on how to better use this data in
vali
+1
On Thu, Apr 23, 2020 at 6:07 AM Andrés de la Peña
wrote:
> +1 (nb)
>
> On Thu, 23 Apr 2020 at 13:09, Aleksey Yeshchenko >
> wrote:
>
> > +1
> >
> > > On 23 Apr 2020, at 12:58, Benjamin Lerer
> > wrote:
> > >
> > > +1 for both
> > >
> > >
> > >
> > > On Thu, Apr 23, 2020 at 3:49 AM Jordan We
Thanks
On Wed, Apr 15, 2020 at 10:32 AM Mick Semb Wever wrote:
> > Can we vote(if required) on this as it looks largely everyone is in
> > agreement?
>
>
> I knew I forgot to post a reply here, thanks for the nudge sankalp, my bad.
>
> I took the above thread as consensus and last Friday committ
Can we vote(if required) on this as it looks largely everyone is in
agreement?
Also we can pile on documentation changes in the vote unless anyone
objects.
On Fri, Apr 10, 2020 at 2:52 PM Erick Ramirez
wrote:
> >
> > In a conversation with Mick we discussed keeping doc changes out as well.
> > A
What are the next steps? Do we hold a vote as I see few initial emails
which dont seem to agree and have not replied based on future discussions.
On Fri, Apr 10, 2020 at 12:50 PM Dinesh Joshi wrote:
> +1 let's keep moving forward.
>
> Dinesh
>
> > On Apr 9, 2020, at 4:07 PM, Nate McCall wrote:
+1
On Wed, Apr 15, 2020 at 8:32 AM Yifan Cai wrote:
> +1
>
>
> From: Sam Tunnicliffe
> Sent: Wednesday, April 15, 2020 7:49:50 AM
> To: dev@cassandra.apache.org
> Subject: Re: Simplify voting rules for in-jvm-dtest-api releases
>
> +1
>
> > On 15 Apr 2020, at 1
Whether a feature is fully done and whether it validates or invalidate
testing is not the point here. The point is that it is a feature and
violates feature freeze. If someone brings in a feature which is almost
done and does not invalidate testing then will we merge all of them to 4.0?
Lot of feat
+1 on holding off and focus on shipping 4.0
On Wed, Apr 1, 2020 at 12:25 PM Joshua McKenzie
wrote:
> This looks like a feature that'd potentially invalidate some testing that's
> been done and we've been feature frozen for over a year and a half. Also:
> scope creep.
>
> My PoV is we hold off. I
#x27;s still not clear, there's no point flogging a dead horse.
>
>
> On 11/01/2020, 17:50, "Sankalp Kohli" wrote:
>
>The Agenda is public and everyone will contribute to it. Anyone can attend
> the meeting. Anyone can propose an alternate time. How is
proposal will be endorsed. But
> you have to do it, because that's how the decision is made. I'm not sure why
> this is controversial - you all know this is true, I'm certain of it.
>
> People keep forgetting. I'm just going to sit here and keep reminding you,
> s
Here is the mail thread where we discussed this. It also has agreement that
we will discuss things on mailing list and no decision till it happens on
mailing list. Hope this clears things up when you read the thread.
https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61
We discussed about the video call on the dev list and everyone agreed to it.
I also welcome Josh in helping with the project. Like Josh and Dinesh
mentioned, let’s encourage contributions by allowing non-committers to do first
round of review as I don’t see a downside of doing this. These video
+1
On Fri, Nov 1, 2019 at 11:56 AM Scott Andreas wrote:
> Hi Michael,
>
> Unfortunately not; ASF recorded the keynotes but video/streaming
> facilities weren't available for the individual tracks.
>
> A copy of the slides are uploaded here:
>
> https://github.com/ngcc/ngcc2019/blob/master/Commit
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
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
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?
> > >
> &
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
> >
> >
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
> &
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
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
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
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
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
>
;>>> 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
> >>&
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
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
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
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
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.
>
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
> > > > 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
>
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
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
>
> >
> 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,
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
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
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
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
+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 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
>
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
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
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
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).
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
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
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
+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
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
&
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
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
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
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
(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
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:
>
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
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,
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
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
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
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:
>>>
>>>
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
+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
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
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
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
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
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!!
>
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
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
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
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
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
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
+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
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:
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
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
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
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
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
; > 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
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
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
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
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..
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
1 - 100 of 181 matches
Mail list logo
