> 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 should put our > minds at ease. I can't see anything Accord related in Jenkins or Butler? But > perhaps there's a CircleCI dashboard somewhere?
The pre-commit process has been using Circle CI, this is due to limitations that have been impacting Jenkins (stability, resources, etc.). Example JIRA https://issues.apache.org/jira/browse/CASSANDRA-18154 <https://issues.apache.org/jira/browse/CASSANDRA-18154> shows the CI results https://app.circleci.com/pipelines/github/dcapwell/cassandra/1793/workflows/0d9ffabd-8046-41e4-a19d-aee8da98ac00 <https://app.circleci.com/pipelines/github/dcapwell/cassandra/1793/workflows/0d9ffabd-8046-41e4-a19d-aee8da98ac00>. There exists test failures, but those are due to python-dtest not knowing about the accord table breaking a few tests (blocker for trunk merge, it means trunk dtest must now known about accord), or flaky tests that committers tend to merge anyways (such as specific tests that fail often, known issues, OS allocating of bind address, etc.) > 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. > On Jan 30, 2023, at 3:03 PM, Henrik Ingo <henrik.i...@datastax.com> wrote: > > Ooops, I missed copy pasting this reply into my previous email: > > On Fri, Jan 27, 2023 at 11:21 PM Benedict <bened...@apache.org > <mailto:bened...@apache.org>> 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 and approach are listened to, and > addressed to the satisfaction of interested parties. It was essentially > codifying the project’s long term etiquette around pieces of work with either > competing proposals or fundamental concerns. It has historically helped to > avoid escalation to vetoes, or reverting code after commit. > > It wasn’t intended that any reason might be invoked, as seems to have been > inferred, and perhaps this should be clarified, though I had hoped it would > be captured by the word “reasonable". Minor concerns that haven’t been caught > by the initial review process can always be addressed in follow-up work, as > is very common. > > > Wouldn't you expect such concerns to at least partially now have been covered > in the CEP discussion, up front? I would expect at most at this stage > someone could validate that the implementation follows the CEP. But I > wouldn't expect a debate on competing approaches at this stage. > > henrik > -- > > Henrik Ingo > c. +358 40 569 7354 > w. www.datastax.com <http://www.datastax.com/> > <https://www.facebook.com/datastax> <https://twitter.com/datastax> > <https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
