I find myself agreeing with Jeremiah's sentiment here.
For example, we're asking people that are on 4.0.1 to make the difficult
choice between accepting the risk of whatever prompts an urgent release vs.
accepting the risk of potentially destabilizing their GA critical
infrastructure. The 4.0
This is the Special "We need to talk" edition. :)
Something interesting changed in the past two weeks - we had our first
couple of rotations of a Build Lead (
https://cwiki.apache.org/confluence/display/CASSANDRA/Build+Lead).
And why do we need to talk? Well, Brandon and I created a lot of test
Could someone take on clearly enumerating the pros and cons of ant vs.
maven?
Without clarity this is going to keep stagnating as a war of
unsubstantiated opinions and fizzle out like it has so many times in the
past.
I'd like to see it either change or the topic be put to rest. :)
On Thu, Feb
gt;
> CEP-7
>
>
> SAI.
>
> The recorded video is available here:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/
> 2020-09-01+Apache+Cassandra+Contributor+Meeting
>
> On Tue, 1 Sep 2020 at 14:34, Jasonstack Zhao Yang <
>
> jasonstack.zhao@gmail.
>
> com
> processes are left around and a few other tests will then fail on timeouts,
> OOM, ip collision etc. You might fix this one and get the others to go away
> bc they were somehow side-effects.
>
> #collaborating
>
> Regards
> On 27/1/22 20:20, Joshua McKenzie wrote:
>
&g
Hey all. Working through our first week as Build Lead and there's a lot of
backlog to process. We had some changes to improve CPU utilization on
apache infra for ci-cassandra and infra is looking into further
optimizations; things are much more responsive from a UX perspective at
least on the
M Brandon Williams wrote:
> On Wed, Jan 26, 2022 at 2:17 PM Joshua McKenzie
> wrote:
> >>
> >> I'm unable to think of an instance where typing in python could have
> helped me,
> >
> > Discoverability, IDE integration, more primitives to describe your
> int
>
> I'm unable to think of an instance where typing in python could have
> helped me,
Discoverability, IDE integration, more primitives to describe your intent
in your code to other maintainers, and shifting a certain class of runtime
errors to being "merge-time" errors all come to mind.
There's
ture to predict that it might payoff with lower
> development overhead, as we can run our tests much more quickly, and debug
> failures much more easily.
>
>
>
> *From: *Joshua McKenzie
> *Date: *Wednesday, 26 January 2022 at 13:40
> *To: *dev
> *Subject: *Re: Have we consid
he same
> test.
>
>
>
>
>
> *From: *Joshua McKenzie
> *Date: *Wednesday, 26 January 2022 at 12:59
> *To: *dev
> *Subject: *Have we considered static type checking for our python libs?
>
> Relevant links:
>
> 1) Optional static typing for python:
>
Relevant links:
1) Optional static typing for python:
https://docs.python.org/3/library/typing.html
2) Mypy static type checker for python: https://github.com/python/mypy
So the question - has anyone given any serious thought to introducing type
hints and a static type checker in ccm and python
I consider removal of dead code and refactoring to be in the same category:
critical to the longevity of the project, and not adding stability value to
GA releases which is our only priority for them.
So improvement, and thus trunk / unreleased only.
~Josh
On Mon, Jan 24, 2022 at 8:08 PM
Three weeks to cover so not strictly biweekly this time. Apologies for the
miss last week; US holiday combined with pandemic related interruptions
meant pushing a week.
Just gives us more to talk about!
[For new Contributors]
First off, check out the official site for details on getting started
Lazy consensus seems like a safe path here.
https://community.apache.org/committers/lazyConsensus.html
On Sat, Jan 22, 2022 at 4:24 PM Ekaterina Dimitrova
wrote:
>
> Hi everyone,
>
> Thank you for responding to my email.
>
> Looking at the responses, I guess I should directly open tickets -
I took a stab at codifying a lot of what we've talked about in terms of
"what code goes where" that's tribal knowledge thus far undocumented on our
project; I've had another long-timer review it and I think it's ready for
broader community input. Roughly 1 page, quick reading, should all be stuff
Cwiki article:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199527692
The previous ML thread about this got derailed by the ever exciting topic
of our merge strategy. Let's not do that here. :)
Simply calling for volunteers to help take on this role starting the
week of Jan
I was particularly influenced by this mental model of thinking about open
source contributions in the past:
https://d33wubrfki0l68.cloudfront.net/dfb15f354706fa763ff385e5eea61520bcdcf8bb/1b0fc/assets/media/community-engagement-oss-image.png
Related article:
+1 to deprecate, drop, add hooks.
On Wed, Jan 19, 2022 at 2:22 PM Brandon Williams wrote:
> Yes, just javascript.
>
> On Wed, Jan 19, 2022 at 1:20 PM Yifan Cai wrote:
> >>
> >> I think we should deprecate scripted UDFs now and drop them from the
> next major, but possibly provide hooks for
72 hours has passed. With some tweaking and Joey's amendment, we have 12
binding +1 and 4 non-binding +1.
I've updated the wiki to reflect that this process is now ratified:
https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+CI+Process
Thanks everyone!
~Josh
On Thu, Jan 13, 2022
I'd say an amendment with a directional poll would be fine. I don't think
this is controversial.
That's me taking "the spirit of the law" rather than the letter though. I'm
good either way.
~Josh
On Wed, Jan 12, 2022 at 11:51 AM Joseph Lynch wrote:
> On Wed, Jan 12, 2022 at 11
I fully concede your point and concern Joey but I propose we phrase that
differently to emphasize the importance of clean tests.
"All releases by default are expected to have a green test run on
ci-cassandra Jenkins. In exceptional circumstances (security incidents,
data loss, etc requiring
ll we'd have to
> do to get out of a sticky situation is cut jira tickets ... Or if this
> is just a "valid reason" that a PMC could be -1 then that's fine too.
>
> -Joey
>
>
> On Mon, Jan 10, 2022 at 11:00 AM Joshua McKenzie
> wrote:
> >
> > Wiki draft a
Wever wrote:
>
>
> On Mon, 10 Jan 2022 at 20:00, Joshua McKenzie
> wrote:
>
>> Wiki draft article here:
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280
>>
>
>
> +1
>
> small nits:
> - none of the other confluence pages use the
+1
On Mon, Jan 10, 2022 at 3:32 PM Michael Shuler
wrote:
> +1
>
> Michael
>
> On 1/10/22 13:00, Joshua McKenzie wrote:
> > Wiki draft article here:
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280
> > <
> https://cwiki.a
Wiki draft article here:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280
The vote will be open for 72 hours (it's short + early indication on
discussion was consensus).
Committer / pmc votes binding.
Simple majority passes.
References:
Background: original ML thread
>
> If you see a merge commit in the history, isn't it normal to presume that
> it will contain the additional change for that branch for the parent commit
> getting merged in?
I've been noodling on this a bit; I think it's a question of degree. When I
see a merge commit my intuitive expectation
aterina
>
> On Tue, 4 Jan 2022 at 14:51, Joshua McKenzie wrote:
>
>> Here's a link to a draft article for the confluence wiki covering what we
>> discussed on this thread:
>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=199530280=7c72c252-9
ntId=14102901=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14102901
On Wed, Jan 5, 2022 at 9:52 AM Joshua McKenzie wrote:
> A wise man once said "Simple is a feature" ;)
>
> Our current process (commit oldest, merge up or merge -s ours w/ --amend):
> - is confusing for new contributors to
>
>
>
>
>
> *From: *bened...@apache.org
> *Date: *Tuesday, 4 January 2022 at 23:52
> *To: *David Capwell , Joshua McKenzie <
> jmcken...@apache.org>
> *Cc: *Henrik Ingo , dev <
> dev@cassandra.apache.org>
> *Subject: *Re: [DISCUSS] Releasable
ork on them to close them.
>
> henrik
>
> On Tue, Dec 14, 2021 at 8:53 PM Joshua McKenzie
> wrote:
>
>> >
>> > I like a change originating from just one commit, and having tracking
>> > visible across the branches. This gives you immediate information
as
outstanding work, I'll get it published and integrated with the confluence
wiki and get the remainder of the work into a JIRA epic to be tracked.
On Fri, Dec 17, 2021 at 4:41 PM Joshua McKenzie
wrote:
> I'll get this into a draft article on the wiki so we can collab on those 3
> outstanding
ris
> T drafts? He uses your recaps as a basis.
>
> Shared on the #cassandra-website channel. Example:
> https://cassandra.apache.org/_/blog/Apache-Cassandra-Changelog-10-October-2021.html
>
> On Tue, Jan 4, 2022 at 7:21 AM Joshua McKenzie
> wrote:
>
>> Could we post
>
> Could we post these on the blog as well
I always wanted to be a blogger. Sounds like now's my chance. ;)
In all seriousness I think this is a great idea. I'll find out what I need
to know to make this happen and make it so.
On Mon, Jan 3, 2022 at 7:38 PM Patrick McFadin wrote:
> What
lp clarify?
~Josh
On Mon, Jan 3, 2022 at 2:57 PM Manish G
wrote:
> There is already a list of tickets with mentors associated. Do these
> 'lhfs' also fall in same category?
>
> On Mon, Jan 3, 2022, 8:51 PM Joshua McKenzie wrote:
>
>> /wave Happy 2022 everyone!
>>
/wave Happy 2022 everyone!
[New contributors getting started]
There are two curated options for getting started if you're new to the
project and looking to get oriented: Failing tests, or starter tickets we
label "lhf" (low hanging fruit). Don't let either fool you - it's almost
always
+1 to 4.1 in May.
On Mon, Jan 3, 2022 at 12:58 PM David Capwell wrote:
> 4.1 target of may works for me, we may want to remove a few things in
> Config.java if not wrapped up on time (thinking track warnings and
> guardrails, though that should be handled by then)
>
> > On Dec 14, 2021, at
A{1,2},C{3,2,1},B{3,2,1}
I'm very strongly in favor of some permutation of A or the 3rd on B and C
due to the release at a .0 version.
I've never heard of a project versioning otherwise (happy to have examples
pointed out). I'm a big fan of prior art / settled law / following idioms.
I find
ere we discuss required test suites to be run pre-commit. If not
> - then I guess we should add those things here too?
>
> On Fri, 17 Dec 2021 at 11:36, Joshua McKenzie
> wrote:
>
> > Good call; thanks for the reminder.
> >
> > So maybe add a
> >
> > 3.a:
wrote:
> Could we also add something about running new tests through the
> multiplexer?
>
> On Fri, Dec 17, 2021 at 10:23 AM Joshua McKenzie
> wrote:
> >
> > So to clarify it all in one place, the proposed new CI process we should
> > test for consensus is:
>
So to clarify it all in one place, the proposed new CI process we should
test for consensus is:
1. Canonical CI for a release is ci-cassandra. We can optionally, and in
practice will, run circle as well but don't codify blocking on that.
2. (NEW) We don't release unless we get a fully green run.
What if we tried the following:
1. Canonical CI for a release is ci-cassandra. We can optionally, and in
practice will, run circle as well but don't codify blocking on that.
2. (NEW) We don't release unless we get a fully green run.
3. Before any merge, you need either a non-regressing (i.e. no
>
> ci-cassandra.a.o needs to be our canonical CI
it's the only one fully usable by a volunteer based
only green in both counts as green
I think today might just be my day to annoy you Mick. :D Sorry!
I think this is contradictory. We can't require circle to be green for a
release if the free
>
> it breaks the code and drivers.
b) accepting that the code and drivers is fragile with versions and we need
> to keep it simple.
Oh yeah, that's a dealbreaker then. Wasn't aware.
we agreed to do periodic snapshot publishing
I poked around a tiny bit - Spark and Flink both interpret
>
> general feedback seems to be that users don't care so long as version
> numbers are going up
Curious to hear more about this. It doesn't match my intuition or
experience running systems but I'm also n=1 and there's a lot of opinions
in the world.
Leap-frogged by Benedict's response here, but
In tracking down the leak that led to
https://issues.apache.org/jira/browse/CASSANDRA-17174, it came to my
attention that debugging ref counts is a -D property rather than a JMX
flippable hot property in Ref.java:
public static final boolean DEBUG_ENABLED =
>
What CI criteria are we using to gate minor and major releases? For
example: All tests from all suites on all configurations? A subset?
All the test suite columns on the following page?
https://ci-cassandra.apache.org/job/Cassandra-trunk/
All the test suites in all combinations on all JDKs on
>
> I like a change originating from just one commit, and having tracking
> visible across the branches. This gives you immediate information about
> where and how the change was applied without having to go to the jira
> ticket (and relying on it being accurate)
I have the exact opposite
Happy Tuesday Morning and Afternoon, which is almost Monday!
Benjamin took the time to put together a roadmap (Awesome!) for the next
Cassandra release - check that out here:
https://cwiki.apache.org/confluence/display/CASSANDRA/Roadmap
[New contributors getting started]
We have a seasonally
>
> Merge commits aren’t that useful
>
I keep coming back to this. Arguably the only benefit they offer now is
procedurally forcing us to not miss a bugfix on a branch, but given how
much we amend many things presently anyway that dilutes that benefit.
Having 1/3rd of your commit history be
>
> limiting this feature to trunk _only_ patches? If so, that seems rather
> weak.
It's definitely a weaker guarantee. On the plus side, if we're doing bugfix
only to all released branches and limiting improvements and new features to
trunk, in theory those will be the more disruptive patches
Good with all the above (reasonable arguments) except I don't understand:
>
> I find it cleaner that work is found associated to one sha on the hardest
> branch, and we treat (or should be) CI holistically across branches.
If we -s ours and amend merge commits on things that straddle stuff like
Williams wrote:
> On Tue, Dec 7, 2021 at 8:18 AM Joshua McKenzie
> wrote:
> > So let me pose the question here to the list: is there anyone who would
> > like to advocate for the current merge strategy (apply to oldest LTS,
> merge
> > up, often -s ours w/new pat
run. This doesn’t
> fully resolve flakiness, but it does provide 95%+ of the necessary pressure
> to maintain test quality, and a consistent way of determining that.
>
> This is how a lot of other projects maintain correctness, and I think how
> many forks of Cassandra are maintained outs
ttently? - Open a ticket. During
> > investigation - Use the CircleCI jobs for running tests in a loop to find
> > when it fails or to verify the test was fixed. (This is already in my
> draft
> > CircleCI document, not yet released as it was pending on the documents
> >
. Goal
is to make it easy to do the right thing and hard to do the wrong thing,
and to have these things written down rather than have it be tribal
knowledge that varies a lot across the project.
~Josh
On Sat, Dec 4, 2021 at 9:04 AM Joshua McKenzie wrote:
> After some offline collab, here's wh
* Test boards for supported branches are green
Phase 2:
* Add Harry to recurring run against trunk
* Add Harry to release pipeline
* Suite of perf tests against trunk recurring
On Wed, Nov 17, 2021 at 1:42 PM Joshua McKenzie
wrote:
> Sorry for not catching that Benedict, you're absolutel
Sorry for the miss last week; it being a holiday in the US meant I was on
the road managing tiny humans and a puppy with my partner and I failed to
hand off update email responsibility to someone else. Which means we have
three weeks to cover!
[New contributor Getting Started]
As a new
esting our time into documenting how to do full
disk encryption in a variety of scenarios + explaining why that is our
recommended approach instead of taking the time and energy to design,
implement, debug, and then maintain an inferior solution.
On Fri, Nov 19, 2021 at 7:49 AM Joshua McKenzie
wrote:
> Are
endent merge commits and want to merge
> them atomically. So far as I know these tools don’t work fantastically in
> this scenario, but if I’m wrong that’s fantastic. If not, given how
> important these things are, should we consider revisiting our merge
> strategy?
>
> From: Joshua M
benchmark results: https://github.com/datastax-labs/hunter Just like
> with correctness testing it's my experience that catching regressions the
> day they happened is much better than trying to do it at beta or rc time.
>
> Piotr also blogged about Hunter when it was released:
>
> http
+1
On Tue, Nov 16, 2021 at 10:14 AM Andrés de la Peña
wrote:
> +1
>
> On Tue, 16 Nov 2021 at 08:39, Sam Tunnicliffe wrote:
>
> > +1
> >
> > > On 15 Nov 2021, at 19:42, Branimir Lambov wrote:
> > >
> > > Hi everyone,
> > >
> > > I would like to start a vote on this CEP.
> > >
> > > Proposal:
>
Sign me up.
On Fri, Nov 12, 2021 at 4:38 PM David Capwell
wrote:
> I am cool helping.
>
> > On Nov 12, 2021, at 10:29 AM, Ekaterina Dimitrova
> wrote:
> >
> > I am in too
> >
> > On Fri, 12 Nov 2021 at 13:23, wrote:
> >
> >> I am interested as well.
> >>
> >> Sent from my iPhone
> >>
> >>>
+1
On Thu, Nov 11, 2021 at 12:06 PM David Capwell
wrote:
> +1
>
> > On Nov 11, 2021, at 7:10 AM, Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
> >
> > +1
> >
> > On Thu, Nov 11, 2021 at 6:10 AM Gary Dusbabek
> wrote:
> >
> >> +1
> >>
> >> On Thu, Nov 11, 2021 at 5:30 AM Andrés
Kind of a nit, but I advocate for us having a guardrails.yaml and updating
this line:
>
> *cassandra.yaml:* allows configuring individual guardrails at startup,
> being globally disabled by default. These guardrails will also be
> dynamically configurable through JMX and/or virtual tables.
The
>
> not because there's 600 pair of eyes watching
> this (TBH, if you didn't mention it, I wouldn't have noticed it)
oof; that wasn't my intent at all! :)
I think a clearly written and easy to find community
> guideline highlighting that this mailing list is suitable for beginner
> questions,
First off - Congrats again to Sumanth Pasupuleti on becoming a committer on
the project! Well deserved; looking forward to working with you further.
It looks like ponymail got an upgrade; I didn't even realize that was
possible at this point. :) So caveat emptor: the links I put in here to
Asking questions in front of 600 people (even virtually) can be
prohibitively hard for a lot of people. I'm with Ekaterina; flagging
certain people in the channel as "available to mentor" so new contributors
would know who they could reach out to 1:1 to get situated and potentially
build some
>
> we noticed CI going from a
> steady 3-ish failures to many and it's getting fixed. So we're moving in
> the right direction imo.
>
An observation about this: there's tooling and technology widely in use to
help prevent ever getting into this state (to Benedict's point: blocking
merge on CI
erent CIs. Not an easy topic, indeed. I support
> running
> > all tests, just having in mind all the related issues/complications.
> >
> > I would say in my mind upgrade tests are particularly important to be
> green
> > before a release, too.
> >
>
gt; > >> I think the costs are quite low, perhaps even negative. Hidden work
> > >> produced by merges that break things can be much more costly than
> > getting
> > >> the work right first time, as attribution is much more challenging.
> > >>
> > >> One c
We as a project have gone back and forth on the topic of quality and the
notion of a releasable trunk for quite a few years. If people are
interested, I'd like to rekindle this discussion a bit and see if we're
happy with where we are as a project or if we think there's steps we should
take to
+1
On Fri, Oct 29, 2021 at 11:19 AM Jacek Lewandowski <
lewandowski.ja...@gmail.com> wrote:
> +1
>
> - - -- --- - -
> Jacek Lewandowski
>
>
> On Fri, Oct 29, 2021 at 4:48 PM Brandon Williams wrote:
>
> > +1
> >
> > On Fri, Oct 29, 2021 at 7:45 AM Mick Semb Wever wrote:
+1 to Benedict's perspective here. Supporting both sstable ID paradigms
should be relatively trivial and low cost to maintain going forward.
On Tue, Oct 26, 2021 at 7:54 AM bened...@apache.org
wrote:
> I think it is probably acceptable to prevent downgrades once a new feature
> is enabled, as
>
> To me having some defined interfaces for interacting with different
> sections of the code is a huge boon for improving developer productivity
> going forward in the project. Every place where we can reduce the amount
> of code reaching inside another module to get at a random internal class
I can't believe it's been two weeks already.
[New contributors getting started]
As a new contributor we recommend starting in one of two places: Failing
tests, or what we call "lhf" (low hanging fruit).
Query for failing tests:
>
> The major reason is that there is not a clear path from the simple CAS
> operations supported by Accord to full SQL support
>
We have not discussed full SQL support and I know of no existing consensus
on the topic of the evolution of our developer APIs. It may be worth
opening up a ML DISCUSS
Back to Mondays. We'll be covering about a week and a half here to get
ourselves back to a biweekly cadence.
[New contributors getting started]
As a new contributor you have a couple great options for getting started:
Failing tests, and what we call "lhf" (low hanging fruit).
Query for failing
+1
On Tue, Oct 5, 2021 at 2:15 PM Brandon Williams wrote:
> +1
>
> On Tue, Oct 5, 2021 at 11:47 AM Oleksandr Petrov
> wrote:
> >
> > Proposing the test build of in-jvm dtest API 0.0.10 for release.
> >
> > Repository:
> >
>
I can't help but notice these project emails have slipped a touch later in
the week; I'll do my best to get us back on track on every other Monday in
a week and a half.
So that said, how have the past two weeks looked?
[The Discussions]
Congrats Aleksei!
On Tue, Sep 21, 2021 at 7:51 AM Jonathan Ellis wrote:
> Congratulations, Aleksei!
>
> On Tue, Sep 21, 2021 at 3:55 AM Benjamin Lerer wrote:
>
> > The PMC members are pleased to announce that Aleksei Zotov has accepted
> > last Friday the invitation to become committer.
> >
>
> ideally if feature development is expected to span more than a single
> quarter it would be best to target phased incorporation into mainline
Strong +1 here. Ariel was right. :)
On Fri, Sep 17, 2021 at 4:47 PM Ekaterina Dimitrova
wrote:
> Gmail cut what I wrote.
>
> The way I read the
We already have plenty of unit tests that have the cognitive burden of
shared static state and need for idempotency / defense against order of
execution. I think having another tool in our toolbox to profile
long-running tests and batch them and/or share a data set makes sense.
On Wed, Sep 15,
Hey there folks - just a smidge past time for our biweekly check-in.
Cassandra 4.0.1 was released on 2021-09-07 with a critical fix for
gossip in large clusters.
We had some good discussion on tidying up our test failure situation
on the project. We now have a clean filter showing the known test
ing that old after the big 4.0 push
>
> On 10/9/21 18:21, Joshua McKenzie wrote:
> > Thanks for the feedback everyone. Drafting site changes now and I'll pull
> > the trigger on JIRA probably Monday; give people the weekend to chew on
> > this.
> >
> > If I open u
r example I
> > have put in a lot of work refactoring repair coordination and I plan to
> do
> > a lot more… do I support falling back to old logic or old behavior? In
> > CASSANDRA-16909 I document a lot of places which are buggy and have shown
> > to cause production
or the site or both.
Thanks everyone for the feedback!
~Josh
On Thu, Sep 2, 2021 at 9:57 AM Joshua McKenzie wrote:
> Feature flag basically means "experimental"
>
> I'm thinking of feature flags more as giving the power to operators to
> decide what they do and don't allow
> wrote:
> >> +1, thanks for the proposal.
> >>
> >> On Thu, 9 Sept 2021 at 16:45, Brandon Williams
> wrote:
> >>
> >>> +1
> >>>
> >>> On Thu, Sep 9, 2021 at 10:39 AM Joshua McKenzie
> >>> wrote:
> &g
(Taking #cassandra-dev slack chat to here)
For context, we have a long history of an ebb and flow of flaky test
failures building up and getting burned down, but don't really have a
workflow or discipline around having a clean snapshot of where we are or
attempting to stay at some kind of steady
+1
On Wed, Sep 8, 2021 at 12:31 PM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:
> Hi everyone,
>
> I’m proposing this CEP for approval.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions
> Discussion:
>
>
fig API. :)
> I am all in for simplification and to make our users’ lives easier. But at
> this point we shouldn’t be comparing the length of the files I think as the
> comments were stripped only for the POC. I guess many of them will get back
> in the actual doc version unfortunate
Reading through the two, the grouping approach seems like it's a lot more
friendly to newcomers as well as providing context specific cues for
relationships between params you're editing. Showing and not telling, if
you will.
Opening up a 1500+ line .yaml file is very daunting, even if most of it
>
> Feature flag basically means "experimental"
I'm thinking of feature flags more as giving the power to operators to
decide what they do and don't allow users of the database access to. Even
if a feature is very stable and non-experimental, it can have negative
effects on other use-cases on a
com> wrote:
> +1. Made changes to the design document linked against the CEP to reflect
> this feedback. Specifically, the following sections have been updated
> * Operations to blacklist
> * Blacklist information store
>
> Thanks,
> Sumanth
>
>
> On Fri, Aug 27, 2021
>
> I would move "Deprecating functionality" to be under Minor version.
Good call. I'll get this into a wiki article once we hash it out on thread
here.
consensus requirements were dropped after being noted for patch releases,
> was that intentional?
Hm. With how our project works we should
standing of a stable trunk is that its success will be
> validated by how few patch versions we release, and how quiet our release
> branches end up being. This will have the benefit that our (very limited)
> reviewing capacity can focus more on trunk. And in turn, the more eyes
> that foc
+1
On Wed, Sep 1, 2021 at 11:16 AM Yifan Cai wrote:
> +1
>
>
> - Yifan
>
> > On Sep 1, 2021, at 7:57 AM, C. Scott Andreas
> wrote:
> >
> > +1nb
> >
> >> On Sep 1, 2021, at 6:54 AM, Jeff Jirsa wrote:
> >>
> >> +1
> >>
> >>
> On Wed, Sep 1, 2021 at 4:54 AM Sam Tunnicliffe
> wrote:
> >>>
Looks like it's time for an update - been a very busy couple of weeks.
[Biweekly digest]
There's quite a bit going on in the past two weeks - here's some shortcuts
if you missed things:
0. A significant issue with Gossip on large clusters surfaced leading to
the 4.0.1 test release:
+1
On Fri, Aug 27, 2021 at 7:41 PM Ekaterina Dimitrova
wrote:
> +1
>
> On Fri, 27 Aug 2021 at 19:40, David Capwell
> wrote:
>
> > +1
> >
> > > On Aug 27, 2021, at 3:26 PM, Patrick McFadin
> wrote:
> > >
> > > +1 nb
> > >
> > > On Fri, Aug 27, 2021 at 1:02 PM Jeff Jirsa wrote:
> > >
> > >> +1
h
> it, especially if we agree on the default behavior that makes the interface
> simple in most cases. Thoughts?
>
> And yes, so good to see CEP process reaping benefits in multiple ways -
> especially around collaboration and documentation.
>
>
> On Thu, Aug 26, 2021 at 8:31 AM
The discussion came up on
https://issues.apache.org/jira/browse/CASSANDRA-16873 concerning where
we land different diff types and it was clear the conversation should
come to the ML and the outcome be codified for the future.
Some useful pre-reading on the Release Lifecycle on our wiki:
1 - 100 of 386 matches
Mail list logo
