> I may be wrong here, but the CEP directly calls out making this api public
> for people who wish to replace the SSTable format
I don’t think this implies API stability. For starters, it doesn’t stipulate
that these implementations will be supported out of tree (the only one I’m
aware of, so f
> My understanding is that the only interface that is expected to be stable for
> external consumers is the secondary index API
I may be wrong here, but the CEP directly calls out making this api public for
people who wish to replace the SSTable format ("Cassandra developers who want
to develop
I agree that we don’t need to block the CEP on this, and that we should have
that discussion. But it’s worth noting that the CEP should not anticipate or
depend on any specific outcome of that discussion.
Since it is somewhat relevant for this discussion, my view is that no interface
should be
> I would be happy to go through and try to put together something for that ...
> At the very least it should get its own DISCUSS thread and then be written
> up in the wiki.
+1. Thanks.
> On Nov 9, 2021, at 11:43 AM, Jeremiah D Jordan
> wrote:
>
> I would love to have this discussion and s
I would love to have this discussion and setup annotations or similar to
formalize things. I just do not think we need to hold any up CEPs to do so.
That discussion should possibly be a CEP of its own proposing how we want to
formalize interfaces? I would be happy to go through and try to put
>
> trunk -> anything goes, not trunk -> try not to change these interfaces
Have we ever clarified what "these interfaces" are? Was just talking to
David and I realized I didn't even JavaDoc CommitLogReadHandler as _being
designed_ for external usage. /sigh
I think it'd be valuable for us to go t
> We already have many interfaces similar to these for Compaction Strategy,
> Indexing, Query Handler.
Today-I-Learned QueryHandler is not allowed to be touched in a minor… good to
know…
> not trunk -> try not to change these interfaces
Outside of MBeans, I honestly do not know what interfaces
We already have many interfaces similar to these for Compaction Strategy,
Indexing, Query Handler. I would hope that commiters are already following a
policy along the lines of trunk -> anything goes, not trunk -> try not to
change these interfaces. I would expect that to be the same policy fo
I still have one outstanding comment, but this is a comment for several of the
CEPs being worked on
> And last comment, which I have also done in the other modularity thread…
> backwards compatibility and maintenance. It is not clear right now what java
> interfaces may not break and how we can
I also feel that having all the resources to get help in more or less
one place (#cassandra-dev slack / ML) probably helps newcomers on the
whole since they can ask questions and likely engage with someone who
can help. I know that I've asked a few silly questions in
#cassandra-dev and appreciated
>
> 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, and
+1 that existing channels of communication (cassandra-dev slack and mailing
lists) should ideally suffice, and I have not seen prohibitive
communication in those forums thus far that goes against newcomers. I agree
it can be intimidating, but to Bowen's point, the more traffic we see
around newcome
As a newcomer (made two commits since October) who has been watching
this mailing list since then, I don't like the idea of a separate
channel for beginner questions. The volume in this mailing list is
fairly low, I can't see any legitimate reason for diverting a portion of
that into another ch
Does anyone have any further comments or questions on the proposal, or are
we ready to move forward to a vote?
Regards,
Branimir
On Tue, Nov 2, 2021 at 7:15 PM David Capwell
wrote:
> > I apologize I did not mention those things explicitly. All the places
> where
> > sstable files are accessed
>
> The vote will be open for 24 hours. Everyone who has tested the build
> is invited to vote. Votes by PMC members are considered binding. A
> vote passes if there are at least three binding +1s.
>
The vote passes, eventually, with six +1s (four binding), and no vetos.
Artifacts have been publ
+1
On Fri, 29 Oct 2021 at 23:44, Mick Semb Wever wrote:
> Proposing the test build of in-jvm dtest API 0.0.11 for release.
>
> Repository:
>
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.11
>
> Candidate SHA:
>
> https://github.com/apache/cassa
16 matches
Mail list logo
