Re: Merging CEP-15 to trunk

Do you mean as part of a blocking review, or just in general?I don’t honestly understand the focus on ninja fixes or rebasing, in either context. Why would a project rebase its work until ready to merge? Why would you worry that a team well resourced with experienced contributors (30+yrs between

Re: Merging CEP-15 to trunk

Benedict, Is it an issue to ask whether flaky tests will be addressed as per our project agreement? Or about ninja fixes and why a branch was not rebased during development? What did I miss? By the way I do not ask these questions to block anyone, even suggested to help with CI…it’s a pity this

Re: Merging CEP-15 to trunk

Review should primarily ask: "is this correct?" and "could this be done differently (clearer, faster, more correct, etc)?" Blocking reviews especially, because why else would a reasonable contributor want to block progress?These questions can of course be asked of implementation details for any

Re: Merging CEP-15 to trunk

Yes, reviews can and they happen any time and anyone can do them if they have time and interest before/after merge and anyone can raise questions or concerns. It was happening before, it happens now, it will happen in the future. The beauty of open source. About this merge - I would personally

Re: Merging CEP-15 to trunk

Yes, reviews can and they happen any time and anyone can do them if they have time and interest before/after merge and anyone can raise questions or concerns. It was happening before, it happens now, it will happen in the future. The beauty of open source. About this merge - I would personally

Re: Merging CEP-15 to trunk

> But during development, did you ever run nightly tests / all tests? I strongly recommend people I work with to use my script that modifies circle ci, which ops us into running all tests; I tend to see people use this as it makes CI faster, but has this by product as well. So yes, all tests

Re: Merging CEP-15 to trunk

On Tue, Jan 31, 2023 at 1:28 AM David Capwell wrote: > If the CI coverage isn't 100%, then we should just identify the gaps, and > focus on that while preparing to merge > > > It has 100% coverage that is done normally for trunk merges; which is a > pre-commit CI run in Circle OR Jenkins. > >

Re: Merging CEP-15 to trunk

> Does this mean there have also been nightly jenkins builds running? Is there > a history of such test results visible somewhere? If yes, I think that lends > a lot of credibility to the claim the process was as rigorous as it is for > trunk, and looking at the build history for a few minutes

Re: Intra-project dependencies

I took a stab at creating a patch that I think addresses most of the comments I saw in this thread, would love feedback in https://issues.apache.org/jira/browse/CASSANDRA-18204 Given that the leading solution is git submodules I went down

Re: Merging CEP-15 to trunk

Ooops, I missed copy pasting this reply into my previous email: On Fri, Jan 27, 2023 at 11:21 PM Benedict wrote: > I'm realizing in retrospect this leaves ambiguity > > > Another misreading at least of the *intent* of these clauses, is that > they were to ensure that concerns about a *design

Re: Merging CEP-15 to trunk

Hi David On Fri, Jan 27, 2023 at 10:11 PM David Capwell wrote: > I've learned that when I have defended the need (or right, if appealing to > the Governance texts...) for contributors to be able to review a feature > branch at the time it is merged to trunk - which for Accord is now - that a >

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

This is really game-changing and an important change for the Cassandra community. I would like to think that creating a governance structure like this will help get more ecosystem projects under the umbrella of Apache Cassandra. Thank you PMC, for spending the time to create this very needed

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

Usually requires an offer to donate from the current owner, an acceptance of that offer (PMC vote), and then the work to ensure that contributions are acceptable from a legal standpoint (e.g. like the incubator - https://incubator.apache.org/guides/transitioning_asf.html - "For contributions

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

Great news indeed. I am wondering what it would take to include projects everyone is using like medusa, reaper, cassandra-ldap, etc. as a subproject. Thanks, German From: Francisco Guerrero Sent: Friday, January 27, 2023 9:46 AM To: dev@cassandra.apache.org

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

> I *think* this is arguably true for a vtable / CQL-based solution as well > from the "you don't know how people are using your API" perspective. Very fair point and think that justifies a different thread to talk about backwards compatibility for our tables (virtual and not); maybe we can

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

First of all, I'd like to thank you all for the comments. It's crucial for me to get the feedback considering the fact I'm limited in discussing such details with anyone else :-) We should start a new thread about the JMX deprecation for sure, but let me make a few comments here as well. In my

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

Actually, Maxim's proposal does not depend on JMX being present or not. What the proposal does is make it easier to create/sync multiple presentations of the same internal data: Virtual Tables, JMX, Metrics, next year's greatest data presentation strategy. Removing JMX from the mix just reduces

Re: Internal Documentation Contribution Guidance

Apologies, I think it should be opened up for comments now.On 30 Jan 2023, at 11:29, Ekaterina Dimitrova wrote:Thank you Benedict! Can you, please, give us comment access to the doc?On Mon, 30 Jan 2023 at 6:14, Benedict wrote:During public and private discussions around

Re: Internal Documentation Contribution Guidance

Thank you Benedict! Can you, please, give us comment access to the doc? On Mon, 30 Jan 2023 at 6:14, Benedict wrote: > During public and private discussions around CEP-15, it became apparent > that we lack any guidance on internal documentation and commenting in the > “style guide” - which I

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

+1 on starting that discussion, thank you for volunteering Benjamin! On Mon, 30 Jan 2023 at 4:59, Benjamin Lerer wrote: > It seems to me that the question that we need to answer, before Maxim puts > more effort into this work, is: what is the future of JMX? > I agree that we have never been

Internal Documentation Contribution Guidance

During public and private discussions around CEP-15, it became apparent that we lack any guidance on internal documentation and commenting in the “style guide” - which I also propose we rename to “Contribution Guide” or “Contribution and Style Guide" to better describe the broader role it has

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

It seems to me that the question that we need to answer, before Maxim puts more effort into this work, is: what is the future of JMX? I agree that we have never been clear about that decision up to now. At least now we have a reason to clarify that point. I can start a discussion about that if