rt and a bunch of folks from the community
have volunteered. We're actively working with the GSoD team. We also have
responded to everyone who has reached out. Nobody was ignored.
Dinesh
> On Jul 23, 2019, at 1:13 PM, Benedict Elliott Smith
wrote:
>
> S
means.
Nate & I were simultaneously busy with ACNA 2019 CfP and coordinating with
ASF to organize it. We have a lot of interest in Cassandra Track at ACNA 2019 :)
Thanks,
Dinesh
> On Jul 23, 2019, at 1:46 PM, Benedict Elliott Smith
wrote:
&
Seems to make sense to branch, right?
On Thu, Aug 29, 2019 at 11:10 PM +0100, "sankalp kohli"
wrote:
Will we cut alpha1 and later alpha releases from trunk or create a new
branch?
On Friday, August 30, 2019, Nate McCall
+1
These should be sent to commits@, not dev@
On 05/09/2019, 09:19, "Stefan Miklosovic"
wrote:
Hi,
maybe I am missing here something but how can I get rid of these
emails which are polluting my inbox?
"[GitHub] [cassandra-builds] michaelsembwever commented on issue #
I think anybody can run these tests locally. It's just possible to pay to
offload them.
And when I say anybody, I don't mean me, because I always fail to get dtests to
run due to environmental problems. But I'm reliably informed that others
manage.
On 06/09/2019, 11:48, "Mick Semb Wever"
I think we need to have a meta discussion about the goal for introducing a new
process. Your email mentions two reasons that I can see:
1) Clarity of the outcome? "For example they have been written up in jira
tickets, in a way that becomes quite difficult to unpack afterwards the
difference
Can we modify the document to make this really explicit then? Right now, the
language suggests the process is mandated, rather than encouraged and
beneficial.
It would be nice to frame it as a positive and incentivised undertaking by
authors, and to list the intended advantages, as well as the
1.During ApacheCon, Laxmikant approached me to discuss CASSANDRA-14227. It
was also raised on the list back in January.
Taking a closer look, it probably is not very difficult for us to fix this –
either by treating the int as unsigned, or by widening it to a long value.
Since this can
e, Sep 17, 2019 at 3:44 AM Benedict Elliott Smith
wrote:
> Can we modify the document to make this really explicit then? Right now,
> the language suggests the process is mandated, rather than encouraged and
> beneficial.
>
> It would be nice to frame it
Lazy consensus still requires a formal vote, just one that is declared to be
governed by lazy consensus.
I think we need to spend some time formalising our governance, so that we can
employ it confidently. At the very least, we should try to codify where we are
comfortable employing lazy conse
with what you've stated here bes: "participation in decision-making is
costly, and that proposers should understand that they need to work to
lower the cost of decision-making on their proposal, and that we as a
project need to figure out how to help them do this.&quo
Perhaps we should move the proposed document to the cwiki for purposes of
voting? That way it's in a place owned by the project, with a permanent
history. Otherwise it's not entirely clear what was voted on.
On 30/09/2019, 20:10, "Sumanth Pasupuleti"
wrote:
+1
On Mon, Sep 30,
As a brief side-step on the topic only of versioning (which no doubt will cause
enough consternation), I personally endorse streamlining it. We have not had a
consistently meaningful convention on this, at any point, and we made it even
worse in the 3.x line. There's no real difference between
>> This has definitely been a confusing topic in the past, I completely
agree
>> Benedict. Glad you brought this up.
>>
>> I'm 100% on board with 5.0 after 4.0.
>>
>> On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith
>>
+1
On 09/10/2019, 17:50, "Oleksandr Petrov" wrote:
Hi,
During NGCC/ACNA19 we've had quite a few conversations around the 4.0
release. Many (minor) features and changes suggested during that time are
possible to implement in 4.next without any problem. However, some changes
+1
We need to do something about this, and I don't mind what. It would be better
if we cut fix releases immediately after a critical fix lands, much as we used
to. We've got fairly lazy about producing releases, perhaps because many of
the full-time contributors now work for organisations tha
+1
On 25/10/2019, 13:58, "Joshua McKenzie" wrote:
+1
On Thu, Oct 24, 2019 at 4:39 PM Nate McCall wrote:
> +1
>
>
> On Fri, Oct 25, 2019 at 6:31 AM Michael Shuler
> wrote:
>
> > I propose the following artifacts for release as 3.0.19.
> >
>
+1
On 25/10/2019, 13:59, "Joshua McKenzie" wrote:
+1
On Thu, Oct 24, 2019 at 4:39 PM Nate McCall wrote:
> +1
>
>
> On Fri, Oct 25, 2019 at 6:25 AM Michael Shuler
> wrote:
>
> > I propose the following artifacts for release as 2.2.15.
> >
>
+1
On 01/11/2019, 12:33, "Mick Semb Wever" wrote:
Please vote on accepting the Cassandra Enhancement Proposal (CEP) document
as a starting point and guide towards improving collaboration on, and success
of, new features and significant improvements. In combination with the recently
accep
I personally welcome your increased participation in any role, and more focus
on project delivery is certainly a great thing. But developer time from your
employer would probably be more impactful, as the main active contributors
right now have their own project management infrastructure, and a
they are and add what value I can
and work with the project to help keep momentum high and remove blockers or
stalls from people's workflows.
Does the above make sense?
On Fri, Jan 10, 2020 at 8:30 AM Benedict Elliott Smith
wrote:
> I persona
> Isn’t this the point of project management; to avoid this issue?
Is the point of project management to avoid the problems caused by project
management? That feels like a Dilbert cartoon.
To be clear, I'm simply responding to the apparent suggestion that we assign
every 4.0 ticket to somebod
Yes, I also miss those fortnightly (or monthly) summaries that Jeff used to
do. They were very useful "glue" in the community. I imagine they'd also make
writing the board report easier.
+1, those were great
-
To uns
ge.
Patrick
On Fri, Jan 10, 2020 at 3:21 PM Jeff Jirsa wrote:
> On Fri, Jan 10, 2020 at 3:19 PM Jeff Jirsa wrote:
>
> >
> >
> > On Fri, Jan 10, 2020 at 2:35 PM Benedict Elliott Smith <
> > bened...@apache.org> wro
s allowed
to use his time to try and get some people together to discuss contributing?
-Jeremiah Jordan
Person with no formal role in the Apache Cassandra project.
> On Jan 10, 2020, at 7:44 PM, Benedict Elliott Smith
wrote:
>
> This is also great. But i
ting to the dev list.
Hugs and kisses friends,
- Jeff
> On Jan 10, 2020, at 6:05 PM, Benedict Elliott Smith
wrote:
>
> To be clear, as it seems like I'm being very negative here, I'm really
pleased to see DataStax suddenly increase their
thread.
https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E
On Sat, Jan 11, 2020 at 3:16 AM Benedict Elliott Smith
wrote:
> I recall this being discussed at ApacheCon, and I recall the ide
nyone can propose an alternate time. How is it private ?
What else do you suggest ?
> On Jan 11, 2020, at 9:31 AM, Benedict Elliott Smith
wrote:
>
> I think everyone is missing my point, and the reason for it. I am super
focused on not repeating the situati
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 it private ?
>
>What else do you suggest ?
>
>> On Jan 11, 2020, at 9:31 AM, Benedict
> I think as long as we all believe we're all good faith actors, truly believe
> we all want what's best for the project (even if we don't necessarily all
> agree on what that is all the time), and internalize that nobody wants to see
> a monoculture on the project, we'll be fine.
I realised re
I think there's always been a distinction in the way we treat alphas/betas
versus patch releases, because they have a staged delivery (landing for dev and
users in different releases). I don't know we've ever been totally consistent
about it across major versions though.
I think we can view 4.
t was
delivered.
On 15/01/2020, 13:34, "Benedict Elliott Smith" wrote:
I think there's always been a distinction in the way we treat alphas/betas
versus patch releases, because they have a staged delivery (landing for dev and
users in different releases). I don't kno
This is brought up roughly once per year. If anything, you're a bit behind
schedule
https://lists.apache.org/thread.html/0750a01682eb36374e490385d6776669ac86ebc02efa27a87b2dbf9f%40%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/c21ccedc7fbda18558997dee8f86c074514b67387858ec12
The common factor is flaky tests, not people. You get a clean run, you commit.
Turns out, a test was flaky. This reduces trust in CI, so people commit
without looking as closely at results. Gating on clean tests doesn't help, as
you run until you're clean. Rinse and repeat. Breakages accum
nt wouldn't be made in Jira, it probably shouldn't be
made.
On 24/01/2020, 08:56, "Benedict Elliott Smith" wrote:
The common factor is flaky tests, not people. You get a clean run, you
commit. Turns out, a test was flaky. This reduces trust in CI, so people
commi
PRs on clean runs won’t
> achieve anything other than dealing with folks who straight up ignore the
> spirit of the policy and knowingly commit code with test breakage that can
> be attributed to their change. I’m not aware of such committers in this
> community, however
Behaviours don't have to be switched only with a new protocol version; it's
possible to support optional feature/modifier flags, the support for which is
negotiated with a client on connection.
A protocol version change seems reasonable to limit to major releases, but a
protocol feature seems p
You could push to the repository that triggers CI less frequently? I don't
think it cares about commits, but pushes.
I think some people like to see feedback promptly, without having to go in
manually until a dtest run is needed closer to patch completion. Unfortunately
this is a situation wh
ose that work on a variety of machines over
time, this does represent a sub-optimal arrangement.
On Tue, Mar 24, 2020 at 4:38 PM Benedict Elliott Smith
wrote:
> You could push to the repository that triggers CI less frequently? I
> don't thi
I would personally prefer we simply bump tickets from the milestone
periodically. The point of a milestone is to collect tickets we expect to land
there, and since we want to release ASAP we should have at most a handful of
optional items there sponsored by some community members, so the burden
Sorry if this is a repeat message; I messed up my mail client settings (I don't
see it today, but it might just be stuck in an unmonitored moderator queue):
I think it is unfair to label this scope creep; it would have to be newly
considered for 4.0 for it to fall under that umbrella, surely?
I
There it is. I knew it would show up eventually.
On 04/04/2020, 06:26, "bened...@apache.org" wrote:
> scope creep.
I think it is unfair to label this scope creep; it would have to be newly
considered for 4.0 for it to fall under that umbrella.
I don't personally mind if
+1
On 08/04/2020, 16:53, "Mick Semb Wever" wrote:
Can we agree on keeping such test changes out of CHANGES.txt ?
We already don't put entries into CHANGES.txt if it is not a change
from any previous release.
There was some discussion before¹ about this, and the problem
> become much easier to agree on which tickets we put in 4.0.
>
>
>
>
>
>
>
>
> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith >
> wrote:
>
> > There it is. I knew it would show up eventually.
This is a silly pet peeve. In this context it was unambiguous what was meant,
and to snipe at people who do not have English as their first language in such
an irrelevant context is a waste of everyone's time and energy.
Please update your approach to the community.
On 16/04/2020, 10:35, "Gr
such and do not assume
negative intent.
On Thu, Apr 16, 2020 at 9:18 AM Benedict Elliott Smith
wrote:
>
> This is a silly pet peeve. In this context it was unambiguous what was
meant, and to snipe at people who do not have English as their first language
in such an ir
+1. This might also serve to produce specific points of discussion around the
topic as the CEP progresses.
Maybe put it high up the list, e.g. after Description of Approach?
On 22/04/2020, 17:40, "Joshua McKenzie" wrote:
Link to CEP guide:
https://cwiki.apache.org/confluence/pages/
I welcome the donation, and hope we are able to accept all of the drivers.
This is really great news IMO.
I do however wonder if the project may be accumulating too many sub-projects?
I wonder if it's time to think about splitting, and perhaps incubating a
project for the drivers?
On 22/0
above.
On 22/04/2020, 21:25, "Nate McCall" wrote:
On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith
wrote:
> I welcome the donation, and hope we are able to accept all of the
> drivers. This is really great news IMO.
>
> I do however won
pache fundation, and maybe I'm just stating the obvious here.
[1] fwiw, I say this as someone that at some points in time was
simultaneously
somewhat actively involved in both Cassandra and the DataStax Java driver.
--
Sylvain
On Fri, Apr 24, 2020 at 12:54 AM Ben
I vote to nuke it post-4.0, when we have time to put together a working group
to discuss its replacement.
On 30/04/2020, 19:21, "Mick Semb Wever" wrote:
The C* codebase contains the cassandra-stress tool that is seeing less
maintenance and is getting replaced in popularity by other too
I think our "pre-beta" criteria should also be our "not in a major" criteria.
If work is prohibited because it invalidates our pre-release verification, then
it should not land until we next perform pre-release verification, which only
currently happens once per major.
This could mean either l
d important places but the important thing is
> to see how exactly it touches, I think
> - Considering it for alpha before the major testing in beta sounds
> reasonable to me but I guess it also depends on people availability to
> review it in detail and the exact
ow]" because it
invalidates "4.0 Verification Work" must also be prohibited until "5.0 Dev"
because the next equivalent work that can now validate it occurs only at "5.0
Verification Work"
On 27/05/2020, 19:05, "Benedict Elliott Smith" wrote:
I
> It seems all rules on voting are predicated on the question being binary
ASF votes are meant to be - as far as possible - a formality confirming
consensus, or something to resolve irreconcilable disagreements. The
discussion section describes how to build consensus when there are multiple
o
I think the doc is a great place to reach agreement on things that are easily
agreed - the final form will be moved to the wiki anyway, and voted on here.
Anything that isn't readily agreed should be moved here for further discussion,
in my opinion, to widen participation.
On 04/06/2020, 22:4
I think the 24 hours point that was raised was pointed to being too short was
just for the roll-call; I personally that think for closing down a discussion,
24 hours is acceptable in order to assist progress, since it should only be
called when it's clear the discussion has halted or consensus h
rote:
Oh, interesting. I checked the doc and didn't see a time frame on the roll
call but maybe I just missed it.
I'll open it up for comments either way.
On Thu, Jun 4, 2020 at 5:51 PM Benedict Elliott Smith
wrote:
> I think the 24 hours point that was raised was
So, if it helps matters: I am explicitly -1 the prior version of this work due
to the technical concerns expressed here and on the ticket. So we either need
to revert that patch or incorporate 15299.
On 16/06/2020, 21:48, "Mick Semb Wever" wrote:
>
> 2) Alternatively, it's been 3 yea
+1
On 16/06/2020, 22:23, "Nate McCall" wrote:
+1 (binding)
On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie
wrote:
> Added unratified draft to the wiki here:
>
>
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> I pr
ave a alpha release)?
This has been confusing me since beta has a lot of work pending… sorry for
not bring this up in a dedicated dev@ thread
>
> On Tue, Jun 16, 2020 at 4:58 PM Benedict Elliott Smith
> wrote:
>
>> So, if it helps matters: I am explicit
ts surfaced by a diverse
collection of users and I'd like to see us move in that direction again for
the long-term health of the project. Hence my attempts to move us towards
beta and take on an awareness campaign and call to action for the community
to engage in testing.)
O
Sorry, I've been busy so not paid as close attention as I would like after
initial contributions to the formulation. On the document I raised this as an
issue, and proposed lowering the "low watermark" to a simple majority of the
electorate - since if you have both a simple majority of the "act
ou're concerned about, or just musing over?
On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith
wrote:
> Sorry, I've been busy so not paid as close attention as I would like after
> initial contributions to the formulation. On the document I raised this
as
&g
> >
> > Yeah, I didn't think you were serious about it being a problem, just
> wanted
> > to check.
> >
> > I'm changing my vote to a -1, in favor of a simple majority as the low
> > watermark in vote participation (not appr
at 12:30 PM Jon Haddad
wrote:
>>> > >
>>> > > > I'm not concerned today, no, just musing and pointing out that
>>> there
>>> > are
>>> > > easy ways to improve progress if we find there's an impedi
thing that would be a non-issue assuming positive intent and
> > alignment
> > > between response to roll call and participation.
> > >
> > >
> > > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai wrote:
> > >
> > >> +1 nb
> > &g
but not so much that I think we'll end up backed into
a corner. I didn't do a good job of explaining that though.
Might be useful to take a roll call now just to get a feel for what we're
voting for.
On Thu, Jun 18, 2020 at 11:21 AM Benedict Elliott Smith
wr
If you read the clauses literally there's no conflict - not all committers that
+1 the change need to review the work. It just means that two committers have
indicated they are comfortable with the patch being merged. One of the +1s
could be based on another pre-existing review and trust in bo
Also, +1
On 22/06/2020, 11:23, "Benedict Elliott Smith" wrote:
If you read the clauses literally there's no conflict - not all committers
that +1 the change need to review the work. It just means that two committers
have indicated they are comfortable with the patch bei
The purpose of this document is to define only how the project makes decisions,
and it lists "tenets" of conduct only as a preamble for interpreting the rules
on decision-making. The authors' intent was to lean on this to minimise the
rigidity and prescriptiveness in the formulation of the rule
--> Branching anytime before we 4.0.0 adds extra burden to the folks trying to
get 4.0.0
This. This is all that matters IMO. Some have been saying 4.0.0 is very
delayed, and that this harms the project - and they're right. So I'm surprised
to see those same voices advocating we prioritise th
Ok, I'm sorry for reaching the opposite conclusion before reading this email -
the implication here instead appears to be that, you believe, people are
advocating to integrate work that should be deferred - is that correct?
Perhaps we should have a direct conversation about the tickets you cons
> Nothing is stopping us for discussing CEPs now, and nothing prevents folks
> from making their own feature branches.
I disagree. CEPs are just as - if not more - of a distraction than branching.
Work doesn't happen in a vacuum. Those who are today focusing what resources
they can on shippin
ests, or you pay money to be able to
run the tests... If the intent is to make it easier for new people to
contribute to the project, shouldn't the focus be on fixing their pain
points such as testing?
On Fri, Jun 26, 2020 at 3:38 PM Jordan West wrote:
> On Fri, Jun 26
> Just a heads up - this comes across as passive aggressive sniping. I'm sure
> you didn't mean it as such
I think indirect criticism is a normal part of discourse, particularly in
public fora where it can be more polite and less disruptive than direct
criticism. Ironically, this snippet of yo
On Sun, Jun 28, 2020 at 12:07 AM Benedict Elliott Smith
wrote:
> > Just a heads up - this comes across as passive aggressive sniping. I'm
> sure you didn't mean it as such
>
> I think indirect criticism is a normal part of discourse, particula
need both new features/improvements and stability.
It is natural that some people push a bit more towards new
features\improvements and others towards stability.
I would be worried if everybody wanted to go in the same direction.
On Mon, Jun 29, 2020 at 12:22 PM Benedict Elliott Smi
and it does
not push me in a direction or another.
Of course, our opinions are somehow tainted by our organizations but that
does not mean that individuals can be reduced to their organization.>
On Mon, Jun 29, 2020 at 2:33 PM Benedict Elliott Smith
wrote:
> I bel
I think, just as importantly, we also need to grapple with what went wrong when
features landed this way, since these were not isolated occurrences -
suggesting structural issues were at play.
I'm not sure if a retrospective is viable with this organisational structure,
but we can perhaps engag
I don't think we can realistically expect majors, with the deprecation cycle
they entail, to come every six months. If nothing else, we would have too many
versions to maintain at once. I personally think all the project needs on that
front is clearer roadmapping at the start of a release cycl
ere are no plans to stop working on it going forward.
On Tue, Jun 30, 2020 at 5:45 PM Benedict Elliott Smith
wrote:
> I don't think we can realistically expect majors, with the deprecation
> cycle they entail, to come every six months. If nothing else, we would
I humbly suggest these are the wrong questions to ask. Instead, two sides of
just one question matter: how did we miss these problems, and what would we
have needed to do procedurally to have not missed it. Whatever it is, we need
to do it now to have confidence other things were not missed, a
Yep, agreed this is definitely the best route forwards.
On 02/07/2020, 01:10, "Joshua McKenzie" wrote:
Plays pretty cleanly into the "have a test plan" we modded in last month. +1
On Wed, Jul 1, 2020 at 6:43 PM Nate McCall wrote:
> >
> >
> >
> > If so, I propose we se
+1
On 03/07/2020, 10:57, "Oleksandr Petrov" wrote:
Proposing the test build of in-jvm dtest API 0.0.3 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.3
Candidate SHA:
https://github.com/apache/cassan
It does raise the bar to critiquing the document though, but perhaps that's
also a feature.
Perhaps we can first discuss the purpose of the document? It seems to be a mix
of mission statement for the project, as well as your own near term roadmap?
Should we interpret it only as an advertisemen
that's table stakes. But agreeing on how we
> get
> > there, my personal take is we'd all be well served to spend our energy
> > Doing the Work and expressing these complementary positions rather than
> > trying to bend everyone to one consistent poin
gagement with the project outside a
small subset of the population with resources to dedicate to this type of
testing which I think we don't want.
On Wed, Jul 15, 2020 at 11:53 AM Benedict Elliott Smith
wrote:
> Perhaps you could clarify what you personally hope w
-1
Sorry, I dropped the ball on
https://issues.apache.org/jira/browse/CASSANDRA-15375
It's ready to commit, if somebody can give it a quick +1, and would be
prohibited after first beta.
On 16/07/2020, 21:16, "Sumanth Pasupuleti"
wrote:
+1 nb
Ran following CircleCI tests
j8_uni
etc) with marketing material and the ASF blog post that's lined up for the
project.
On Fri, Jul 17, 2020 at 5:14 AM Benedict Elliott Smith
wrote:
> -1
>
> Sorry, I dropped the ball on
> https://issues.apache.org/jira/browse/CASSANDRA-15375
&
t of diminishing returns and we're
fine just being a bit more laissez-faire about things and applying our
collective judgement through our votes on each instance. My own bias
though, definitely receptive to other points of view on that.
On Fri, Jul 17, 2020 at 11:21 AM B
Thanks Sally, really appreciate your insight.
To respond to the community discourse around this:
> Keep your announcement plans ... private: limit discussions to the PMC
This is all that I was asking and expecting: if somebody is making commitments
on behalf of the community (such as that a rel
ause of the action you took;
Actually, in this case and many others it's because of people's unfounded
assumptions about motives, incentives, and actions taken and has little to
do with reality. Which is the definition of not assuming positive intent.
On Mon, Jul 20,
not
taking this discussion further. Just want to call it out here so you or
others aren't left waiting for a reply.
We can agree to disagree.
On Mon, Jul 20, 2020 at 11:59 AM Benedict Elliott Smith
wrote:
> Firstly, that is a very strong claim that in this particul
Impacts -> Docs
It's not mandatory, but we could perhaps consider making it so somewhere in the
workflow. Do you have a good suggestion for where?
There's also "Test and Documentation Plan" which is already mandatory.
On 31/07/2020, 20:28, "Lorina Poland" wrote:
This morning, Caleb Rac
nt, I can look at the code and
figure out what it does. A topic like audit logging is likely to use many
classes and touch on many items that I'm not familiar with nor be the most
readable code.
Lorina Poland
On Fri, Jul 31, 2020 at 12:35 PM Benedict Elliott Smith
w
when
Impacts = Docs.
Thanks for the info, Benedict!
Lorina Poland
On Fri, Jul 31, 2020 at 1:10 PM Benedict Elliott Smith
wrote:
> > It is mandatory to move a ticket to "In Progress"
>
> I think you are mistaken; I have triple-checked, a
+1
On 06/08/2020, 10:07, "Michael Semb Wever" wrote:
> I think the pragmatic thing to do is fix it now, and I'd strongly
> prefer to do that but wanted to check if there are any objections or
> things I hadn't considered?
+1
Thanks for giving this visibility and demonstr
Have we considered first asking the user list if there's anyone willing to
donate resources to maintain compatibility?
I know I have in the (distant) past handled Jira filed by (production) Windows
users. I don’t know how prevalent they are, but perhaps we should offer them a
chance to step up
ail-archive.com/user@cassandra.apache.org/msg60234.html
Jordan
On Mon, Aug 10, 2020 at 4:16 AM Benedict Elliott Smith
wrote:
> Have we considered first asking the user list if there's anyone willing to
> donate resources to maintain compatibility?
>
>
101 - 200 of 399 matches
Mail list logo
