1) That is not the current state of the code;
2) We should anyway not be codifying something just because a handful of people
have been doing it.
C-10241 does not accord with this view either - it makes clear the debug log
output should be for "where we can log things that might help if somethin
I disagree with all of this. Debug logging can be enabled for production
clusters, but it should not be on by default.
DEBUG should not be taken to mean “background activities” and we should stamp
this out wherever this has been occurring. DEBUG means verbose logging for use
debugging system be
I think I have already proposed a simple solution to this problem on the
thread: if anyone says it’s a hot path (and cannot be persuaded otherwise), it
should be treated as such. Saves argument, but permits an easy escape hatch if
everyone agrees with minimal discussion.
I think this is a good
Syntactically, if we’re updating settings like compaction throughput, I would
prefer to simply update a virtual settings table
e.g. UPDATE system.settings SET compaction_throughput = 128
Some operations will no doubt require a stored procedure syntax, but perhaps it
would be a good idea to spli
I think we need to briefly step back and think about what the syntax means and how it fits into existing syntax.It seems that the dimensionality verbiage assumes we’re logically introducing N vector fields, so that each row adopts a value for all of the vector fields or none. But in practice we ar
Closing the loop on seeking consensus for UX/UI/API changes, I see a few
options. Can we rank choice vote please?
A - Jira suffices
B - Post a DISCUSS API thread prior to making changes
C - Periodically publish a list of API changes for retrospective consideration
by the community
Points raise
My only slight concern with this approach is the additional memory pressure.
Since 64yrs should be plenty at any moment in time, I wonder if it wouldn’t be
better to represent these times as deltas from the nowInSec being used to
process the query. So, long math would only be used to normalise
x those two items, would we be in agreement on this being
> both the core of the syntax we want and compatible w/ the wish list for
> future items?
>
>
> On Sun, Aug 14, 2022 at 12:25 PM Benedict Elliott Smith
> wrote:
>>
>>
>>>
>>> Verbose v
ke.
>
> Deconstructed:
> LET x = SELECT x FROM ...
> LET y = SELECT y FROM ...
>
> Nested:
> LET (x, y) = ((SELECT x FROM…), (SELECT y FROM))
>
> I'm trying to summate but let me know if I missed something. I apologize in
> advance to Monday morning Caleb, who wil
gt;
Yep, this was already agreed way back with the earlier proposal.
> On 14 Aug 2022, at 16:30, Avi Kivity wrote:
>
>
>
> On 14/08/2022 17.50, Benedict Elliott Smith wrote:
>>
>> > SELECT and LET incompatible once comparisons become valid selectors
>>
FROM..
IF a > 1 AND d > 1…
> On 14 Aug 2022, at 13:55, Avi Kivity via dev wrote:
>
>
>
> On 14/08/2022 01.29, Benedict Elliott Smith wrote:
>>
>> I’ll do my best to express with my thinking, as well as how I would explain
>> the feature to a user.
I’ll do my best to express with my thinking, as well as how I would explain the
feature to a user.
My mental model for LET statements is that they are simply SELECT statements
where the columns that are selected become variables accessible anywhere in the
scope of the transaction. That is to
Perhaps we just restrict “trivial” patches to trunk? If it requires several
PRs/branches then a Jira is perhaps warranted, and perhaps if it is trivial and
unimportant it’s better not to waste the project’s time managing the overhead.
This would also be simplified with a modified merge strateg
> We can start by putting the bar at a lower level and raise the level over time
+1
> One simple approach that has been mentioned several time is to run the new
> tests added by a given patch in a loop using one of the CircleCI tasks
I think if we want to do this, it should be extremely easy
I think a change like this could be dangerous for a lot of existing automation
built atop nodetool.
I’m not sure this change is worthwhile. I think it would be better to introduce
e.g. -ste and -ete for “start token exclusive” and “end token exclusive” so
that users can opt-in to whichever sc
e Eggleston wrote:
> Yeah I'd say NULL is fine for condition evaluation. Reference assignment is a
> little trickier. Assigning null to a column seems ok, but we should raise an
> exception if they're doing math or something that expects a non-null value
>
> > On Jun
AFAICT that standard addresses server-side cursors, not the assignment of a
query result to a variable. Could you point to where it addresses variable
assignment?
Postgres has a similar concept, SELECT INTO[1], and it explicitly returns NULL
if there are no result rows, unless STRICT is specifi
For a minor/major? I can imagine doing this for a patch version, but this is of
much less importance to downstream users.
Do you have any examples of projects that do this for major/minor development
branches, as you propose?
I'm just a bit confused about the proposition to decouple from releas
> Vendors are also free to support and provide hot-fixes and back ports on
> these unreleased versions, outside of the community's efforts or concerns
This seems to me like we're endorsing the release of these versions by
downstream maintainers? Even if we decide to modify this proposal and say
Well the other problem I see is that this could create a lot of confusion for
our users, if more versions start popping up (and/or versions are skipped).
It's hard to row back from unwanted versions in the wild, and we may end up
having to either support them or disappoint our users.
Do we have
Hmm, ok. I see some possible issues with this. You mention one possibility,
i.e. that downstream may end up releasing these versions for us? Which
potentially complicates our lives, whether we want it or not.
Would this apply to only trunk, or to all existing major/minor releases?
I wonder if
Sorry, I may be being dense, but it's not that I didn't parse your
justification for it, but that I literally don't understand what the proposal
is.
On 03/05/2021, 08:30, "Mick Semb Wever" wrote:
> I didn't really understand the unreleased versions proposal though.
Benedict, two bri
+1 to semver, shippable trunk, feature flags, and better documentation about
feature support and compatibility edges - we should have a single page with a
table of version x feature, with a summary and links to detailed explanations
of everything important a user should be aware of.
I didn't re
Thanks Aleksei,
Some of these are great points, but to respond specifically to the checkstyle
suggestion: I hope to kick off some (minor) discussion around codestyle soon to
modernise our guide, however I would personally prefer that code style
enforcement remains relatively light touch. Some o
board to help to track newcomers contributions:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463&quickFilter=2088
Apparently Brandon is cheating to appear as a newcomer but we will solve
that. He should be at the Nightmare level ;-)
Le mer. 28 avr. 2021 à
I think there are two main hurdles, one is restoring contributor interest in
mentoring, and the other is finding newcomers that actually want to stick
around. These are perhaps two sides of the same coin, though. An ugly truth is
that it isn't very enjoyable or rewarding to help newcomers when t
atrick
>
> On Tue, Apr 27, 2021 at 10:16 AM Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
>
> > Quake has it like
> >
> > - I Can Win
> > - Bring It On
> > - Hurt Me Plenty
> > - Hardcore
> &g
ormal.
- Ultra-Violence - Hard.
- Nightmare - Very Hard.
-
On Tue, Apr 27, 2021 at 9:50 AM Benedict Elliott Smith
wrote:
> Perhaps we could replace both Complexity and Difficulty with e.g.
> Experience?
>
> Newcomer
> Learner
bring it on its own thread later so
we don't go too far away from the original, and more important, topic which
is how to attract and retain new contributors to the project.
Em ter., 27 de abr. de 2021 às 13:08, Benedict Elliott Smith <
bened...@apache.org> escreveu:
al)
- Hard (current Challenging)
- Very Hard (current Byzantine)
Please let me know what you think.
Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott Smith <
bened...@apache.org> escreveu:
> If you're wondering, they're documented:
>
https://cw
;
> > > > > I believe Paolo started with the project through a contributor
boot
> > > camp.
> > > > > Also if I remember correctly some of the ones that were done were
> > > > internal
> > > > > at DataStax and it helped
t;problem" to have enough
committers to look at it over a (preferably) shorter period of time
and make that feedback loop shorter. That's it. You might have the
best guides and whatever but if a dust settles at it no guide will
make it happen.
On Tue, 27 Apr 20
I think that all of the bootcamps we ran in the past produced precisely zero
new contributors.
I wonder if it would be more impactful to produce slightly more permanent
content, such as step-by-step guides to producing a simple patch for some
subsystem. Perhaps if people want to, a recording co
I think my earlier response vanished into the moderator queue. Just a few
comments:
1) The Paxos latency (and correctness) improvements I think should land in
4.0.x, as we have introduced a fairly significant regression and this work
mostly resolves outstanding issues with LWTs today.
2) If we
> it would make sense to put that information on a *Roadmap* page
That makes sense to me, and I'm looking forward to agreeing a roadmap. I think
it will be nice for the project to start properly looking to the future again.
On 01/04/2021, 14:06, "Benjamin Lerer" wrote:
Thanks everybody.
There is no legal reason; this was disavowed on LEGAL-288. The ostensible
reason is that Roy Fielding, who filed the papers of incorporation, interprets
the charter to require this. I don't think, however, anybody has challenged
this interpretation of the charter. I certainly do not interpret it
As I'm sure you're aware, only a couple of people in the community are able to
follow or participate in board discussions without being expressly included.
On 30/03/2021, 09:51, "Justin Mclean" wrote:
Hi,
JFYI I've started a discussion about this on the board list [1]. Note that
that
> I think the situation is a little more seriously that you may realise, I
> suggest you look at what actions the board has taken in similar situations in
> the past
I thought you had already indicated the likely remedy: the removal of
non-compliant releases?
I’m puzzled by your desire f
+1
On 29/03/2021, 21:16, "Ben Bromhead" wrote:
+1 good sensible suggestion.
On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova
wrote:
> I also like the latest suggestion, +1, thank you
>
> On Mon, 29 Mar 2021 at 14:16, Yifan Cai wrote:
>
> > +1
> >
>
> This is not a retrospective change just a clarification on what should be
> self evident.
This is a non-sequitur surely? Can something that is self-evident need
clarifying? Or do you suppose it is self-evident to all besides the feeble
intellects of this community?
I think a self-evident pol
I thought you had indicated you were anyway raising this with the board?
Either way, I don't personally see any issue with delaying the vote by a week
or so if it will bring some official clarity to this issue, now it has been
raised. How quickly can we expect to see changes reflected in the off
> I guess you are asking for something official from VP Legal Affairs or the
> ASF board? If so I can make that happen.
I would prefer the official policy pages to be updated to have a clear
statement on this, so this problem can be solved in perpetuity.
> IMO it does, the project can choose to
Hi Justin,
You are probably right, but as far as I am aware you are not an official source
of ASF policy on this matter. The official policy pages do not stipulate this,
so I would appreciate if you could get them updated to accord more clearly your
beliefs before the project makes the necessar
> Including Category B binaries in a source release is mentioned in ASF policy
> here [1].
Sorry to keep banging the same drum, but I read this before our earlier emails,
and if this is the intended meaning it needs to be rewritten. I also doubt this
was the intended meaning of the original aut
> Because a source release could not contain compiled code
Again, I don't see this stated explicitly. Perhaps the guidance should be
clarified if this is the intention?
On 27/03/2021, 01:59, "Justin Mclean" wrote:
Hi,
> Could you clarify why you think this is incompatible with ASF po
> I suggest you read the whole thread. The outcome was that it's OK to put jars
> in version control but not in a source release.
There was no outcome AFAICT? There was a suggestion that was explicitly
caveated as only a suggestion that required formal approval by VP Legal, which
does not seem
> When I did download the the 3.11.10 release [2], I can see that it contained
> compiled binary files (jars), which I don't think is in line with ASF release
> policy.
Could you clarify why you think this is incompatible with ASF policy? AFAICT
the policy only stipulates that binary releases _
focus on first.
What do you think?
Le mar. 2 mars 2021 à 06:29, Berenguer Blasi a
écrit :
> +1000 on some form of roadmap for visibility and planning
>
> On 1/3/21 18:35, Benedict Elliott Smith wrote:
> > I completely agree we should consider any roadmap
w we
plan to use CEPs moving forward.
.
Le lun. 1 mars 2021 à 13:21, Benedict Elliott Smith a
écrit :
> I guess I meant that I don't foresee roadmap discussions having a hard
> requirement of CEP for all goals we might discuss, though it would
probably
> be
a strongly held position on
either (but think it's probably better they're not intrinsically tied in either
direction).
On 01/03/2021, 12:13, "Benedict Elliott Smith" wrote:
I guess I meant that I don't foresee roadmap discussions having a hard
requirement of
I guess I meant that I don't foresee roadmap discussions having a hard
requirement of CEP for all goals we might discuss, though it would probably be
expected that many of the biggest proposals would already at least have a
minimal CEP to be filed, you're right.
Certainly if an advanced CEP ex
rk" is not restricted to items in the project
roadmap and developers can still make contributions to work unlisted in the
project roadmap, I think having a project roadmap is certainly a step in
the right direction.
Thanks,
Sumanth
On Mon, Mar 1, 2021 at 1:18 A
A while back somebody privately raised the idea of a project roadmap to me, and
I’d like to propose we formally consider it as a project now that 4.0 is
approaching completion.
I think there are two major benefits to agreeing a roadmap:
1) It helps us to coordinate finite project resource
Fair enough.
On 26/02/2021, 20:45, "Mick Semb Wever" wrote:
Should we wait for e.g. five clean CI runs in a row? Historically flaky
> tests have been a real issue for the project, and CI success probably
> shouldn't be taken instantaneously for releases.
There are tickets fo
Very nice.
On 26/02/2021, 21:36, "Melissa Logan" wrote:
Hi all,
We are excited to share the almost-complete Cassandra website design
(CASSANDRA-16115). Huge thanks to Lorina Poland, Anthony Grosso, Mick Semb
Weaver, Josh Levy, Chris Thornett, Diogenese Topper, and a few others
Should we wait for e.g. five clean CI runs in a row? Historically flaky tests
have been a real issue for the project, and CI success probably shouldn't be
taken instantaneously for releases.
On 26/02/2021, 19:38, "Michael Semb Wever" wrote:
> * We’re within line-of-sight to closing out
for some deprecated feature, trunk gets
> > bumped to 5.0.0. More releases happen from trunk 5.0.0, 5.1.0, 5.2.0,
> 5.2.1
> > development on trunk continues on. Time for a new maintenance branch
> with
> > 5.3.0 so cassandra-5.3 gets cut...
> >
>
But, as discussed, we previously agreed limit features in a minor version, as
per the release lifecycle (and I continue to endorse this decision)
On 28/01/2021, 16:04, "Mick Semb Wever" wrote:
> if there's no such features, or anything breaking compatibility
>
> What do you envisag
> if there's no such features, or anything breaking compatibility
What do you envisage being delivered in such a release, besides bug fixes? Do
we have the capacity as a project for releases dedicated to whatever falls
between those two gaps?
I'd like to see us have three branches: life suppor
We have had a very problematic history with release versioning, such that our
users probably think the numbers are meaningless.
However, in the new release lifecycle document (and in follow-up discussions
around qualifying releases) we curtail _features_ once a release is GA, and
also stipulate
eaking change has been introduced,
does it make sense to release a major?
On Wed, Jan 27, 2021 at 11:21 AM Benedict Elliott Smith
wrote:
> Perhaps we could also consider quarterly "develop" releases, so that we
> have pressure to maintain a shippable trunk? Thi
d-cycle RC, that a user wanting
shiny features can grab, providing feedback throughout the development cycle.
On 26/01/2021, 14:11, "Benedict Elliott Smith" wrote:
My preference is for a simple annual major release cadence, with minors as
necessary. This is simple for the user com
My preference is for a simple annual major release cadence, with minors as
necessary. This is simple for the user community and developer community:
support = x versions = x years.
I'd like to pair this with stricter merge criteria, so that we maintain a
~shippable trunk, and we cut a release a
Joshua McKenzie
> wrote:
>
> > Reasonable categories. We haven't discussed what qualifies where for 4.0
> > have we? (new lacking | changed modest | old lacking)
> >
> > On Fri, Dec 11, 2020 at 9:14 AM Benedict Elliott Smith <
> &
In my opinion...
- Expected to find serious bugs (e.g. new poorly tested features): Block beta
- Anticipated to possibly find serious bugs (e.g. extensively changed features
with modest testing): Block RC
- Anticipated not to find serious bugs (e.g. old unchanged but poorly tested
features): Blo
Perhaps we should skip v5, and move to v6 for the new protocol to avoid this
issue?
On 08/12/2020, 10:53, "Sam Tunnicliffe" wrote:
CASSANDRA-15299 has revised the wire format of CQL native protocol to add a
framing layer around the existing CQL messages. This is targetted at protocol
v5,
m ter., 24 de nov. de 2020 às 07:26, Benedict Elliott Smith <
bened...@apache.org> escreveu:
> In my parlance the config property would be a breaking change, whereas the
> LWT behaviour would be a performance regression. This latter might cause
> partial outages or
legacy_mode:
false" and move on with their upgrades, but people wanting to keep the
previous performance will become aware of the breaking change and set it to
true.
Em seg., 23 de nov. de 2020 às 21:07, Benedict Elliott Smith <
bened...@apache.org> escreveu:
> W
(need to update yaml) rather than implicit (by
upgrading you agree with the change), since the latter can go unnoticed by
those who don't pay attention to NEWS.txt
Em seg., 23 de nov. de 2020 às 20:03, Benedict Elliott Smith <
bened...@apache.org> escreveu:
> What
gt; >> somebody has to make a call and live with it. It seems to me that being
> >> blamed for choosing correctness is easier to live with ;-)
> >>
> >> Benjamin
> >>
> >> PS: I tried to push the choice on Sylvain but he dodged the bu
I think I meant #4 __♂️
On 20/11/2020, 21:11, "Blake Eggleston" wrote:
I’d also prefer #3 over #4
> On Nov 20, 2020, at 10:03 AM, Benedict Elliott Smith
wrote:
>
> Well, I expressed a preference for #3 over #4, particularly for the 3.x
series. Howev
with a plan to opt-in by default "eventually".
>
> On Wed, Nov 18, 2020 at 11:10 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > Perhaps there might be broader appetite to weigh in on which major
> > rele
to correct).
On Wed, Nov 18, 2020 at 4:54 AM Benedict Elliott Smith
wrote:
> It doesn't seem like there's much enthusiasm for any of the options
> available here...
>
> On 12/11/2020, 14:37, "Benedict Elliott Smith"
> wrote:
&g
It doesn't seem like there's much enthusiasm for any of the options available
here...
On 12/11/2020, 14:37, "Benedict Elliott Smith" wrote:
> Is the new implementation a separate, distinctly modularized new body of
work
It’s primarily a distinct, modularis
> Is the new implementation a separate, distinctly modularized new body of work
It’s primarily a distinct, modularised and new body of work, however there is
some shared code that has been modified - namely PaxosState, in which legacy
code is maintained but modified for compatibility, and the sy
In my opinion, a similar calculus should be applied to 3.0 and 3.11. This is
a(n arguably quite serious) bug, so whatever is not overly onerous to backport
should be considered while they are supported. The work under discussion has
two components: a replacement to the core consensus algorithm,
It's been there since the beginning.
If we were to consider the alternative proposal for 4.0, it would not have to
be blocking for release. I had planned to come forward after 4.0, primarily
because I did not want to create further political complexities for the project
at this time, but also b
es w/whatever is supported at that time. That way users will be able
to have a single source of truth on what the project recommends and vets
for going from wherever they are to the latest.
On Fri, Oct 09, 2020 at 12:05 PM, Benedict Elliott Smith <
bened...@apache.org> wrote:
t of contributors could take on the 3.0 → 4.0 path Benedict, that'd be a
great help. I also assume we could all collaborate on the tooling / infra /
approaches we use for this validation so it wouldn't be a complete re-work.
On Fri, Oct 09, 2020 at 11:02 AM, Benedict Elliott
o focus on 3.0->4.0 while they focus on the paths
I would be happy to deprecate.
On 09/10/2020, 15:49, "Benedict Elliott Smith" wrote:
Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
I think there's anyway a big difference between supported and encour
Yeah, and perhaps even drop 2.1 (2.2) -> 3.11 when 4.0 appears.
I think there's anyway a big difference between supported and encouraged. I
think we should encourage 2.1->3.0->4.0, while maintaining support for 2.2->3.0
and 3.0->3.11 for critical bugs only, and 3.11->4.0 in the normal way given
> Would it be necessary to go from 3.0 to 3.11 on the way to 4.0? I didn't
> think that was required.
That's what's being discussed, and Mick is proposing requiring it officially,
to reduce support burden.
> What has been fixed in 3.0 that hasn't been merged into 3.11 ?
Nothing that I'm aware o
I would personally prefer the community to officially recommend skipping 3.11
to users that have not yet upgraded, as 3.0 and 4.0 have each had much more
attention given to them over the past several years. This would naturally lead
to fewer issues filed for 3.0->3.11 and 3.11->4.0, as fewer us
+1
On 25/09/2020, 15:45, "Oleksandr Petrov" wrote:
Proposing the test build of in-jvm dtest API 0.0.5 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.5
Candidate SHA:
https://github.com/apache/cassan
w about we just have a Vote on branching cassandra-4.0 and the issue
will be decided?
Jake
On Thu, Sep 24, 2020 at 11:53 AM Benedict Elliott Smith
wrote:
> I'm not sure what you are referring to here, that vote said nothing about
> branching at beta.
&g
simply pointing out the branching of 4.0 post beta was the plan of last
record.
Jake
On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith
wrote:
> The community does everything through discussion and consensus. Does that
> include branching, or not?
>
>
not sacrosanct anymore?
On 24/09/2020, 16:22, "Jake Luciani" wrote:
I'm sorry I see no issue with branching 4.0 as it was the thing we voted on
back in 2018. If you wish to extend the freeze you should call a new vote.
On Thu, Sep 24, 2020 at 11:15 AM Benedic
:05, "Brandon Williams" wrote:
On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith
wrote:
>
> You do not have the authority to unilaterally overrule the community
process. This is a serious breach of your responsibilities as a member of the
PMC.
Feel free
enough to know I wouldn't overtly lie to try and shift an Overton
Window,
> > we should probably go ahead and agree to disagree on this conversation
and
> > let committers go forward and do what they think best for the project.
> >
> >
> >
FWIW, I personally look forward to receiving that contribution when the time is
right.
On 23/09/2020, 18:45, "Josh McKenzie" wrote:
talking about that would involve some bits of information DataStax might
not be ready to share?
At the risk of derailing, I've been poking and proddi
hat pretty much everything being discussed in this
thread has been discussed at length during the SIG meetings. I think it is
worth noting because we are pretty much still have the same conversation.
On Wed, Sep 23, 2020 at 12:03 PM Benedict Elliott Smith
wrote:
> I d
y has made a clear case as to a more compelling
> place to start in terms of an operator donation the project then
> collaborates on. There's no mass adoption evidence nor feature enumeration
> that I know of for any of the approaches anyone's taken, so the
discus
I think there's significant value to the community in trying to coalesce on a
single approach, earlier than later. This is an opportunity to expand the
number of active organisations involved directly in the Apache Cassandra
project, as well as to more quickly expand the project's functionality
+1
On 16/09/2020, 10:45, "Mick Semb Wever" wrote:
This vote is about officially accepting the Harry donation from Alex Petrov
and Benedict Elliott Smith, that was worked on in CASSANDRA-15348.
The Incubator IP Clearance has been filled out at
http://incubator.apa
> I know. I recognise that is a frustrating aspect of this discussion. It
> is something hard to move on.
So how about we wait until there's a concrete example we can discuss as a
community? If we don't have one, it doesn't seem pressing.
On 16/09/2020, 08:23, "Mick Semb Wever" wrote:
> But I would suggest that we are more productive when
> raising and discussing concrete examples and specific patches
You make a good point. Can you provide some concrete examples of your own?
Ironically, this entire proposal so far rests on hypothetical lost
contributions by hypothetical comp
a very real
challenge.
[1]: http://community.apache.org/committers/lazyConsensus.html
[2]: https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma
p.s. - sorry for being long-winded. Lots of complex stuff to cover here.
On Sat, Sep 12, 2020 at 5:46 PM Benedict Elliott Smith
y different
>
> than
>
> the one we had on the same topic 11 weeks ago:
> https://lists.apache.org/thread.html/
> raf3592f2297abfb120563d216eeea26bfb3a6e048b246492815954ff%40%3Cdev.
> cassandra.apache.org%3E
> .
>
> Jordan
> if we do these contributions in secret
Are you aware of any work happening (or expected to happen) in this way? This
seems a very different problem than the one the thread was opened with.
> it will be even harder for folk to put in late reviews
It is always harder to revert and revisit comm
m concerned a new branch will not change my main goal which is
to have 4.0 out of the door.
On Fri, Sep 11, 2020 at 11:03 AM Benedict Elliott Smith
wrote:
> This is a social enterprise, and we are all able to enter into a social
> contract/convention. This doesn't
1 - 100 of 397 matches
Mail list logo
