> > - parallelise dtests (because 12 hours is wild)
>
> That's one word for it. :)
>
> We used to ad hoc take a crack at sorting the individual test times by
> longest and taking top-N and seeing if there was LHF to shave off that.
> Being on a flight atm, not having that data handy right now
I've previously created
https://issues.apache.org/jira/browse/CASSANDRA-14902 for updating the
compaction_throughput_in_mb default. I created
https://issues.apache.org/jira/browse/CASSANDRA-15521 for updating the
num_tokens default, https://issues.apache.org/jira/browse/CASSANDRA-15522
for updatin
100% agree
François and team wrote a doc on testing and gating commits
Blake wrote a doc on testing and gating commits
Every release there’s a thread on testing and gating commits
People are the common factor every time. Nobody wants to avoid merging their
patch because someone broke a test else
Yes. please do. We should also update our JVM defaults.
On Thu, Jan 23, 2020, 9:28 PM Jeremy Hanna
wrote:
> To summarize this thread, I think people are generally okay with updating
> certain defaults for 4.0 provided we make sure it doesn't unpleasantly
> surprise cluster operators. I think wi
To summarize this thread, I think people are generally okay with updating
certain defaults for 4.0 provided we make sure it doesn't unpleasantly
surprise cluster operators. I think with the num_tokens and
compaction_throughput_in_mb we could go with a release note for the reasons
in my last email.
>
> I am reacting to what I currently see
> happening in the project; tests fail as the norm and this is kinda seen as
> expected, even though it goes against the policies as I understand it.
After over half a decade seeing us all continue to struggle with this
problem, I've come around to the sch
>
> - parallelise dtests (because 12 hours is wild)
That's one word for it. :)
We used to ad hoc take a crack at sorting the individual test times by
longest and taking top-N and seeing if there was LHF to shave off that.
Being on a flight atm, not having that data handy right now, and that not
On 1/23/20 3:53 PM, David Capwell wrote:
2) Nightly build email to dev@?
Nope. builds@c.a.o is where these go.
https://lists.apache.org/list.html?bui...@cassandra.apache.org
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@
Thanks for the link. I have reached out to infra and will update this
thread as I hear back.
Looking around other Apache projects, there are work arounds so I don't
actually see this as a blocker, more limiting possible implementations.
So assuming we have a solution which enables CI builds on PR
On 1/23/20 2:13 PM, Mick Semb Wever wrote:
ASF policy is that patches from contributors that haven't a ICLA
filed can not have their patches automatically run through any ASF CI
system. It's up to a committer (or someone who has filed a ICLA) to
trigger the test run on the patch.
I couldn't f
> > ASF policy is that patches from contributors that haven't a ICLA
> > filed can not have their patches automatically run through any ASF CI
> > system. It's up to a committer (or someone who has filed a ICLA) to
> > trigger the test run on the patch.
>
> I couldn't find this CI+ICLA policy in
On 1/23/20 12:44 PM, mck wrote:
ASF policy is that patches from contributors that haven't a ICLA
filed can not have their patches automatically run through any ASF CI
system. It's up to a committer (or someone who has filed a ICLA) to
trigger the test run on the patch.
I couldn't find this CI+
On Thu, Jan 23, 2020 at 9:09 AM Jeff Jirsa wrote:
> On Thu, Jan 23, 2020 at 6:18 AM Jeremiah Jordan
> wrote:
>
> > It is the reviewer and authors job to make sure CI ran and didn’t
> > introduce new failing tests, it doesn’t matter how they were ran. It is
> > just as easy to let something throu
> I am fine with Jenkins or CircleCI; though I feel CircleCI is more effort
> for each member.
ASF policy is that patches from contributors that haven't a ICLA filed can not
have their patches automatically run through any ASF CI system. It's up to a
committer (or someone who has filed a ICLA
>
> CircleCI can build github forked branches.
Yes it can, but we currently require each member of the community to set up
their own CircleCI in order to test Cassandra (and non-paid account will
have many tests failing). I looked into CircleCI JIRA integration and it
seems that we would need ev
On Thu, Jan 23, 2020 at 6:18 AM Jeremiah Jordan
wrote:
> Can’t you currently open a PR with the right commit message, have do
> review there with all comments posted back to JIRA, run CI on it and then
> merge it closing the PR? This is the basic workflow you are proposing yes?
>
>
Yes you can.
> > If I don't hear any objection, I'll commit this. Off this, as it
> > aggregates test reports, it's now possible to start test posting emails
> > with the test report summary, as well as bringing in the dtest builds
> > into the pipeline.
>
>
> Based on the pipeline approach I've gotten
Can’t you currently open a PR with the right commit message, have do review
there with all comments posted back to JIRA, run CI on it and then merge it
closing the PR? This is the basic workflow you are proposing yes?
It is the reviewer and authors job to make sure CI ran and didn’t introduce n
> My mind set is that by switching to PRs (even if all the conversations are
> in JIRA) we can setup automation which helps detect issues before merging.
CircleCI can build github forked branches. AFAIK there's no reason to open a PR.
The finer granularity of code review comments can also be o
19 matches
Mail list logo
