Re: [VOTE] Release Apache Cassandra 3.0.28

[Miklosovic, Stefan]

+1


From: Mick Semb Wever 
Sent: Thursday, October 20, 2022 19:53
Cc: dev
Subject: Re: [VOTE] Release Apache Cassandra 3.0.28

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



The vote will be open for 72 hours (longer if needed). 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 and no -1's.


+1

Checked
- signing correct
- checksums are correct
- source artefact builds
- binary artefact runs
- debian package runs
- redhat* package runs

Re: [VOTE] Release Apache Cassandra 3.11.14

[Miklosovic, Stefan]

+1


From: Mick Semb Wever 
Sent: Thursday, October 20, 2022 19:53
Cc: dev
Subject: Re: [VOTE] Release Apache Cassandra 3.11.14

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



The vote will be open for 72 hours (longer if needed). 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 and no -1's.


+1

Checked
- signing correct
- checksums are correct
- source artefact builds
- binary artefact runs
- debian package runs
- redhat* package runs

Re: [VOTE] Release Apache Cassandra 4.0.7

[Miklosovic, Stefan]

+1


From: Mick Semb Wever 
Sent: Thursday, October 20, 2022 19:54
To: dev
Subject: Re: [VOTE] Release Apache Cassandra 4.0.7

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



The vote will be open for 72 hours (longer if needed). 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 and no -1's.


+1

Checked
- signing correct
- checksums are correct
- source artefact builds (JDK 8+11)
- binary artefact runs (JDK 8+11)
- debian package runs (JDK 8+11)
- redhat* package runs (JDK 8+11)

Re: [VOTE] Release Apache Cassandra 3.0.28

[Benjamin Lerer]

+1

Le ven. 21 oct. 2022 à 10:27, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> a écrit :

> +1
>
> 
> From: Mick Semb Wever 
> Sent: Thursday, October 20, 2022 19:53
> Cc: dev
> Subject: Re: [VOTE] Release Apache Cassandra 3.0.28
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>
>
> +1
>
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds
> - binary artefact runs
> - debian package runs
> - redhat* package runs
>

Re: [VOTE] Release Apache Cassandra 3.11.14

[Benjamin Lerer]

+1

Le ven. 21 oct. 2022 à 10:27, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> a écrit :

> +1
>
> 
> From: Mick Semb Wever 
> Sent: Thursday, October 20, 2022 19:53
> Cc: dev
> Subject: Re: [VOTE] Release Apache Cassandra 3.11.14
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>
>
> +1
>
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds
> - binary artefact runs
> - debian package runs
> - redhat* package runs
>
>

Re: [VOTE] Release Apache Cassandra 4.0.7

[Benjamin Lerer]

+1

Le ven. 21 oct. 2022 à 10:27, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> a écrit :

> +1
>
> 
> From: Mick Semb Wever 
> Sent: Thursday, October 20, 2022 19:54
> To: dev
> Subject: Re: [VOTE] Release Apache Cassandra 4.0.7
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>
>
> +1
>
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds (JDK 8+11)
> - binary artefact runs (JDK 8+11)
> - debian package runs (JDK 8+11)
> - redhat* package runs (JDK 8+11)
>
>
>

Re: [VOTE] Release Apache Cassandra 4.0.7

[Jacek Lewandowski]

+1

- - -- --- -  -
Jacek Lewandowski


On Fri, Oct 21, 2022 at 11:18 AM Benjamin Lerer  wrote:

> +1
>
> Le ven. 21 oct. 2022 à 10:27, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> a écrit :
>
>> +1
>>
>> 
>> From: Mick Semb Wever 
>> Sent: Thursday, October 20, 2022 19:54
>> To: dev
>> Subject: Re: [VOTE] Release Apache Cassandra 4.0.7
>>
>> NetApp Security WARNING: This is an external email. Do not click links or
>> open attachments unless you recognize the sender and know the content is
>> safe.
>>
>>
>>
>> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>>
>>
>> +1
>>
>> Checked
>> - signing correct
>> - checksums are correct
>> - source artefact builds (JDK 8+11)
>> - binary artefact runs (JDK 8+11)
>> - debian package runs (JDK 8+11)
>> - redhat* package runs (JDK 8+11)
>>
>>
>>

Re: [VOTE] Release Apache Cassandra 3.0.28

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, Oct 19, 2022 at 4:41 AM Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 3.0.28 for release.
>
> sha1: 96c5332ee15f45ca5410caaa787cc88d6947b3c9
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.28-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1277/org/apache/cassandra/cassandra-all/3.0.28/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.28/
>
> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.28-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.28-tentative

Re: [VOTE] Release Apache Cassandra 4.0.7

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, Oct 19, 2022 at 4:41 AM Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 4.0.7 for release.
>
> sha1: 277fa4fca4a80eb327be6559f993c91e42dd4009
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.7-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1279/org/apache/cassandra/cassandra-all/4.0.7/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.7/
>
> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.7-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.7-tentative

Re: [VOTE] Release Apache Cassandra 3.11.14

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, Oct 19, 2022 at 4:41 AM Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 3.11.14 for release.
>
> sha1: 9d3327ef1321fe1bf4e7fc73ed6111da7c994553
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.14-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1278/org/apache/cassandra/cassandra-all/3.11.14/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.14/
>
> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.14-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.14-tentative

Re: [DISCUSS] Potential circleci config and workflow changes

[Derek Chen-Becker]

Random thought (and on-topic, even!) now that I'm starting to understand
CircleCI config better: we should use conditionals and parameters so that
we can have a single, uniform config across version branches, and limit the
diffs across branches to version related flags to enable or disable sets of
tests. I would even go so far as to say we might be able to put the config
into a submodule while pulling in branch-specific config from the top level
repo.

Cheers,

Derek

On Thu, Oct 20, 2022, 3:21 PM Josh McKenzie  wrote:

> I believe it's original intention to be just about CircleCI.
>
> It was but fwiw I'm good w/us exploring adjacent things regarding CI here.
> I'm planning on deep diving on the thread tomorrow and distilling a
> snapshot of the work we have a consensus on for circle and summarizing here
> so we don't lose that. Seems like it's fairly non-controversial.
>
> On Thu, Oct 20, 2022, at 5:14 PM, Mick Semb Wever wrote:
>
>
>
> On Thu, 20 Oct 2022 at 22:07, Derek Chen-Becker 
> wrote:
>
> Would the preclusion of non-committers also prevent us from configuring
> Jenkins to auto-test on PR independent of who opens it?
>
> One of my current concerns is that we're maintaining 2x the CI for 1x the
> benefit, and I don't currently see an easy way to unify them (perhaps a
> lack of imagination?). I know there's a long history behind the choice of
> CircleCI, so I'm not trying to be hand-wavy about all of the thought that
> went into that decision, but that decision has costs beyond just a paid
> CircleCI account. My long term, probably naive, goals for CI would be to:
>
> 1. Have a CI system that is *fully* available to *any* contributor, modulo
> safeguards to prevent abuse
>
>
>
> This thread is going off-topic, as I believe it's original intention to be
> just about CircleCI.
>
> But on your point… our community CI won't be allowed (by ASF), nor have
> capacity (limited donated resources), to run pre-commit testing by anyone
> and everyone.
>
> Today, trusted contributors can be handed tokens to ci-cassandra.a.o (make
> sure to label them so they can be revoked easily), but we still face the
> issue that too many pre-commit runs impacts the throughput and quality of
> the post-commit runs (though this has improved recently).
>
> It's on my wishlist to be able to: with a single command line; spin up the
> ci-cassandra.a.o stack on any k8s cluster, run any git sha through it and
> collect results, and tear it down. Variations on this would solve
> non-committers being able to repeat, use, and work on their own (or a
> separately donated) CI system, and folk/companies with money to be able to
> run their own ci-cassandra.a.o stacks for faster pre-commit turnaround
> time. Having this reproducibility of the CI system would make testing
> changes to it easier as well, so I'd expect a positive feedback loop here.
>
> I have some rough ideas on how to get started on this, if anyone would
> like to buddy up on it.
>
>
>

Re: [VOTE] Release Apache Cassandra 3.0.28

[C. Scott Andreas]

+1nb

— Scott

> On Oct 21, 2022, at 4:04 AM, Brandon Williams  wrote:
> 
> +1
> 
> Kind Regards,
> Brandon
> 
>> On Wed, Oct 19, 2022 at 4:41 AM Mick Semb Wever  wrote:
>> 
>> 
>> Proposing the test build of Cassandra 3.0.28 for release.
>> 
>> sha1: 96c5332ee15f45ca5410caaa787cc88d6947b3c9
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.28-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1277/org/apache/cassandra/cassandra-all/3.0.28/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and 
>> repositories, are available here: 
>> https://dist.apache.org/repos/dist/dev/cassandra/3.0.28/
>> 
>> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>> 
>> [1]: CHANGES.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.28-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.28-tentative

Re: [VOTE] Release Apache Cassandra 3.11.14

[C. Scott Andreas]

+1nb

— Scott

> On Oct 21, 2022, at 4:05 AM, Brandon Williams  wrote:
> 
> +1
> 
> Kind Regards,
> Brandon
> 
>> On Wed, Oct 19, 2022 at 4:41 AM Mick Semb Wever  wrote:
>> 
>> 
>> Proposing the test build of Cassandra 3.11.14 for release.
>> 
>> sha1: 9d3327ef1321fe1bf4e7fc73ed6111da7c994553
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.14-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1278/org/apache/cassandra/cassandra-all/3.11.14/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and 
>> repositories, are available here: 
>> https://dist.apache.org/repos/dist/dev/cassandra/3.11.14/
>> 
>> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>> 
>> [1]: CHANGES.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.14-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.14-tentative

Re: [VOTE] Release Apache Cassandra 4.0.7

[C. Scott Andreas]

+1nb

— Scott

> On Oct 21, 2022, at 4:06 AM, Brandon Williams  wrote:
> 
> +1
> 
> Kind Regards,
> Brandon
> 
>> On Wed, Oct 19, 2022 at 4:41 AM Mick Semb Wever  wrote:
>> 
>> 
>> Proposing the test build of Cassandra 4.0.7 for release.
>> 
>> sha1: 277fa4fca4a80eb327be6559f993c91e42dd4009
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.7-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1279/org/apache/cassandra/cassandra-all/4.0.7/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and 
>> repositories, are available here: 
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.7/
>> 
>> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>> 
>> [1]: CHANGES.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.7-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.7-tentative

Re: [DISCUSS] Potential circleci config and workflow changes

[David Capwell]

I am cool with removing circle if apache CI is stable and works, we do need to 
solve the non-committer issue but would argue that partially exists in circle 
today (you can be a non-commuter with a paid account, but you can’t be a 
non-committer with a free account)



> On Oct 20, 2022, at 2:20 PM, Josh McKenzie  > wrote:
> 
>> I believe it's original intention to be just about CircleCI.
> It was but fwiw I'm good w/us exploring adjacent things regarding CI here. 
> I'm planning on deep diving on the thread tomorrow and distilling a snapshot 
> of the work we have a consensus on for circle and summarizing here so we 
> don't lose that. Seems like it's fairly non-controversial.
> 
> On Thu, Oct 20, 2022, at 5:14 PM, Mick Semb Wever wrote:
>> 
>> 
>> On Thu, 20 Oct 2022 at 22:07, Derek Chen-Becker > > wrote:
>> Would the preclusion of non-committers also prevent us from configuring 
>> Jenkins to auto-test on PR independent of who opens it?
>> 
>> One of my current concerns is that we're maintaining 2x the CI for 1x the 
>> benefit, and I don't currently see an easy way to unify them (perhaps a lack 
>> of imagination?). I know there's a long history behind the choice of 
>> CircleCI, so I'm not trying to be hand-wavy about all of the thought that 
>> went into that decision, but that decision has costs beyond just a paid 
>> CircleCI account. My long term, probably naive, goals for CI would be to:
>> 
>> 1. Have a CI system that is *fully* available to *any* contributor, modulo 
>> safeguards to prevent abuse
>> 
>> 
>> This thread is going off-topic, as I believe it's original intention to be 
>> just about CircleCI.
>> 
>> But on your point… our community CI won't be allowed (by ASF), nor have 
>> capacity (limited donated resources), to run pre-commit testing by anyone 
>> and everyone.
>> 
>> Today, trusted contributors can be handed tokens to ci-cassandra.a.o (make 
>> sure to label them so they can be revoked easily), but we still face the 
>> issue that too many pre-commit runs impacts the throughput and quality of 
>> the post-commit runs (though this has improved recently).
>> 
>> It's on my wishlist to be able to: with a single command line; spin up the 
>> ci-cassandra.a.o stack on any k8s cluster, run any git sha through it and 
>> collect results, and tear it down. Variations on this would solve 
>> non-committers being able to repeat, use, and work on their own (or a 
>> separately donated) CI system, and folk/companies with money to be able to 
>> run their own ci-cassandra.a.o stacks for faster pre-commit turnaround time. 
>> Having this reproducibility of the CI system would make testing changes to 
>> it easier as well, so I'd expect a positive feedback loop here. 
>> 
>> I have some rough ideas on how to get started on this, if anyone would like 
>> to buddy up on it.

Re: [DISCUSS] Potential circleci config and workflow changes

[David Capwell]

> 1. Tune parallelism levels per job (David and Ekaterina have insight on this) 
> Question for David, do you tune only parallelism and use only xlarge? If yes, 
> we need to talk :D 

Yes, and this is 100% because I am lazy.  Too high parallel jobs are a problem 
for circle as 100% of resources need to be free to start a job; so if you ask 
for 100 resources and 99 are free, everyone is blocked until 1 resource frees 
up for that job… :sadpanda:.  

Now, do we need xlarge?  Nope, but I don’t change as that doesn’t impact me… I 
am 100% cool getting rid of LOW/MID/HIGH and tuning our jobs to what actually 
is needed… I hate that we all do something different (MID, HIGH, and custom 
HIGH)


> On Oct 21, 2022, at 10:39 AM, David Capwell  wrote:
> 
> I am cool with removing circle if apache CI is stable and works, we do need 
> to solve the non-committer issue but would argue that partially exists in 
> circle today (you can be a non-commuter with a paid account, but you can’t be 
> a non-committer with a free account)
> 
> 
> 
>> On Oct 20, 2022, at 2:20 PM, Josh McKenzie > > wrote:
>> 
>>> I believe it's original intention to be just about CircleCI.
>> It was but fwiw I'm good w/us exploring adjacent things regarding CI here. 
>> I'm planning on deep diving on the thread tomorrow and distilling a snapshot 
>> of the work we have a consensus on for circle and summarizing here so we 
>> don't lose that. Seems like it's fairly non-controversial.
>> 
>> On Thu, Oct 20, 2022, at 5:14 PM, Mick Semb Wever wrote:
>>> 
>>> 
>>> On Thu, 20 Oct 2022 at 22:07, Derek Chen-Becker >> > wrote:
>>> Would the preclusion of non-committers also prevent us from configuring 
>>> Jenkins to auto-test on PR independent of who opens it?
>>> 
>>> One of my current concerns is that we're maintaining 2x the CI for 1x the 
>>> benefit, and I don't currently see an easy way to unify them (perhaps a 
>>> lack of imagination?). I know there's a long history behind the choice of 
>>> CircleCI, so I'm not trying to be hand-wavy about all of the thought that 
>>> went into that decision, but that decision has costs beyond just a paid 
>>> CircleCI account. My long term, probably naive, goals for CI would be to:
>>> 
>>> 1. Have a CI system that is *fully* available to *any* contributor, modulo 
>>> safeguards to prevent abuse
>>> 
>>> 
>>> This thread is going off-topic, as I believe it's original intention to be 
>>> just about CircleCI.
>>> 
>>> But on your point… our community CI won't be allowed (by ASF), nor have 
>>> capacity (limited donated resources), to run pre-commit testing by anyone 
>>> and everyone.
>>> 
>>> Today, trusted contributors can be handed tokens to ci-cassandra.a.o (make 
>>> sure to label them so they can be revoked easily), but we still face the 
>>> issue that too many pre-commit runs impacts the throughput and quality of 
>>> the post-commit runs (though this has improved recently).
>>> 
>>> It's on my wishlist to be able to: with a single command line; spin up the 
>>> ci-cassandra.a.o stack on any k8s cluster, run any git sha through it and 
>>> collect results, and tear it down. Variations on this would solve 
>>> non-committers being able to repeat, use, and work on their own (or a 
>>> separately donated) CI system, and folk/companies with money to be able to 
>>> run their own ci-cassandra.a.o stacks for faster pre-commit turnaround 
>>> time. Having this reproducibility of the CI system would make testing 
>>> changes to it easier as well, so I'd expect a positive feedback loop here. 
>>> 
>>> I have some rough ideas on how to get started on this, if anyone would like 
>>> to buddy up on it.
> 

Re: [DISCUSS] Potential circleci config and workflow changes

[Ekaterina Dimitrova]

I agree with David with one caveat - last time I checked only some Python
tests lack enough resources with the free tier. The rest run slower than
with a paid account, but they do fine. In fact I use the free tier if I
want to test only unit or in-jvm tests sometimes. I guess that is what he
meant by partially but even being able to run the non-Python tests is a win
IMHO. If we find a solution for all tests though… even better.
@Derek your idea sounds interesting, I will be happy to see a proposal.
Thank you

On Fri, 21 Oct 2022 at 13:39, David Capwell  wrote:

> I am cool with removing circle if apache CI is stable and works, we do
> need to solve the non-committer issue but would argue that partially exists
> in circle today (you can be a non-commuter with a paid account, but you
> can’t be a non-committer with a free account)
>
>
>
> On Oct 20, 2022, at 2:20 PM, Josh McKenzie  wrote:
>
> I believe it's original intention to be just about CircleCI.
>
> It was but fwiw I'm good w/us exploring adjacent things regarding CI here.
> I'm planning on deep diving on the thread tomorrow and distilling a
> snapshot of the work we have a consensus on for circle and summarizing here
> so we don't lose that. Seems like it's fairly non-controversial.
>
> On Thu, Oct 20, 2022, at 5:14 PM, Mick Semb Wever wrote:
>
>
>
> On Thu, 20 Oct 2022 at 22:07, Derek Chen-Becker 
> wrote:
>
> Would the preclusion of non-committers also prevent us from configuring
> Jenkins to auto-test on PR independent of who opens it?
>
> One of my current concerns is that we're maintaining 2x the CI for 1x the
> benefit, and I don't currently see an easy way to unify them (perhaps a
> lack of imagination?). I know there's a long history behind the choice of
> CircleCI, so I'm not trying to be hand-wavy about all of the thought that
> went into that decision, but that decision has costs beyond just a paid
> CircleCI account. My long term, probably naive, goals for CI would be to:
>
> 1. Have a CI system that is *fully* available to *any* contributor, modulo
> safeguards to prevent abuse
>
>
>
> This thread is going off-topic, as I believe it's original intention to be
> just about CircleCI.
>
> But on your point… our community CI won't be allowed (by ASF), nor have
> capacity (limited donated resources), to run pre-commit testing by anyone
> and everyone.
>
> Today, trusted contributors can be handed tokens to ci-cassandra.a.o (make
> sure to label them so they can be revoked easily), but we still face the
> issue that too many pre-commit runs impacts the throughput and quality of
> the post-commit runs (though this has improved recently).
>
> It's on my wishlist to be able to: with a single command line; spin up the
> ci-cassandra.a.o stack on any k8s cluster, run any git sha through it and
> collect results, and tear it down. Variations on this would solve
> non-committers being able to repeat, use, and work on their own (or a
> separately donated) CI system, and folk/companies with money to be able to
> run their own ci-cassandra.a.o stacks for faster pre-commit turnaround
> time. Having this reproducibility of the CI system would make testing
> changes to it easier as well, so I'd expect a positive feedback loop here.
>
> I have some rough ideas on how to get started on this, if anyone would
> like to buddy up on it.
>
>
>

Re: [DISCUSS] Potential circleci config and workflow changes

[Josh McKenzie]

> I am cool with removing circle if apache CI is stable and works, we do need 
> to solve the non-committer issue but would argue that partially exists in 
> circle today (you can be a non-commuter with a paid account, but you can’t be 
> a non-committer with a free account)
There's a few threads here:
1. non-committers should be able to run ci
2. People that have resources and want to run ci faster should be able to do so 
(assuming the ci of record could serve to be faster)
3. ci should be stable

Thus far we haven't landed on 1 system that satisfies all 3. There's some 
background discussions brainstorming how to get there; when / if things come 
from that they'll as always be brought to the list for discussion.

On Fri, Oct 21, 2022, at 1:44 PM, Ekaterina Dimitrova wrote:
> I agree with David with one caveat - last time I checked only some Python 
> tests lack enough resources with the free tier. The rest run slower than with 
> a paid account, but they do fine. In fact I use the free tier if I want to 
> test only unit or in-jvm tests sometimes. I guess that is what he meant by 
> partially but even being able to run the non-Python tests is a win IMHO. If 
> we find a solution for all tests though… even better.
> @Derek your idea sounds interesting, I will be happy to see a proposal. Thank 
> you
> 
> On Fri, 21 Oct 2022 at 13:39, David Capwell  wrote:
>> I am cool with removing circle if apache CI is stable and works, we do need 
>> to solve the non-committer issue but would argue that partially exists in 
>> circle today (you can be a non-commuter with a paid account, but you can’t 
>> be a non-committer with a free account)
>> 
>> 
>> 
>>> On Oct 20, 2022, at 2:20 PM, Josh McKenzie  wrote:
>>> 
 I believe it's original intention to be just about CircleCI.
>>> It was but fwiw I'm good w/us exploring adjacent things regarding CI here. 
>>> I'm planning on deep diving on the thread tomorrow and distilling a 
>>> snapshot of the work we have a consensus on for circle and summarizing here 
>>> so we don't lose that. Seems like it's fairly non-controversial.
>>> 
>>> On Thu, Oct 20, 2022, at 5:14 PM, Mick Semb Wever wrote:
 
 
 On Thu, 20 Oct 2022 at 22:07, Derek Chen-Becker  
 wrote:
> Would the preclusion of non-committers also prevent us from configuring 
> Jenkins to auto-test on PR independent of who opens it?
> 
> One of my current concerns is that we're maintaining 2x the CI for 1x the 
> benefit, and I don't currently see an easy way to unify them (perhaps a 
> lack of imagination?). I know there's a long history behind the choice of 
> CircleCI, so I'm not trying to be hand-wavy about all of the thought that 
> went into that decision, but that decision has costs beyond just a paid 
> CircleCI account. My long term, probably naive, goals for CI would be to:
> 
> 1. Have a CI system that is *fully* available to *any* contributor, 
> modulo safeguards to prevent abuse
 
 
 This thread is going off-topic, as I believe it's original intention to be 
 just about CircleCI.
 
 But on your point… our community CI won't be allowed (by ASF), nor have 
 capacity (limited donated resources), to run pre-commit testing by anyone 
 and everyone.
 
 Today, trusted contributors can be handed tokens to ci-cassandra.a.o (make 
 sure to label them so they can be revoked easily), but we still face the 
 issue that too many pre-commit runs impacts the throughput and quality of 
 the post-commit runs (though this has improved recently).
 
 It's on my wishlist to be able to: with a single command line; spin up the 
 ci-cassandra.a.o stack on any k8s cluster, run any git sha through it and 
 collect results, and tear it down. Variations on this would solve 
 non-committers being able to repeat, use, and work on their own (or a 
 separately donated) CI system, and folk/companies with money to be able to 
 run their own ci-cassandra.a.o stacks for faster pre-commit turnaround 
 time. Having this reproducibility of the CI system would make testing 
 changes to it easier as well, so I'd expect a positive feedback loop here. 
 
 I have some rough ideas on how to get started on this, if anyone would 
 like to buddy up on it.

unsubscribe

[Han]

unsubscribe

Re: unsubscribe

[Erick Ramirez]

Sorry to see you go. If you'd like to unsubscribe from the dev ML, please
email dev-unsubscr...@cassandra.apache.org. Cheers!

Re: Website fixes PR

[Erick Ramirez]

Thanks for doing this, Derek. We prefer to have an accompanying ticket for
all PRs for trackability.

Also, don't worry about the broken links in the headers/footers -- it's a
known issue. Cheers!

On Fri, 21 Oct 2022 at 04:08, Derek Chen-Becker 
wrote:

> I put together some minor fixes for the website dev documentation:
>
> https://github.com/apache/cassandra-website/pull/179
>
> I've tested these locally using the docker scripts, although antora seems
> to create broken links and navigation (confirmed this behavior even without
> my commit). I was told that this didn't need a JIRA ticket but I'm happy to
> create one to track if that's more appropriate.
>
> Thanks,
>
> Derek
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>
>