Re: [VOTE] Formalizing our CI process

[Berenguer Blasi]

Hi Joseph

jenkins CI was at 2/3 flakies consistently post 4.0 release. Then things
broke and we've been working hard to get back to the 2/3 flakies. Most
current failures imo are timeuuid C17133 or early termination of process
C17140 related afaik. So getting back to the 2/3 'impossible' flakies
should be doable and a reasonable target (famous last words...). My 2cts.

Regards

On 12/1/22 7:21, Joseph Lynch wrote:
> On Wed, Jan 12, 2022 at 12:47 AM Berenguer Blasi
>  wrote:
>> We shouldn't be at 15-20 failures but at 2 or 3. The problem is that those 2 
>> or 3 have already been hammered for over a year by 2 or 3 different 
>> committers and they didn't crack.
>>
> Last I checked circleci was almost fully green on trunk only, and the
> asf builds all had around 15-20 failures. For example, as of the last
> build I checked, trunk had 22 failures [1], 4.0 had 12 [2], 3.11 had
> 35 [3] and 3.0 had 25 [4].
>
> [1] https://ci-cassandra.apache.org/job/Cassandra-trunk/901/
> [2] https://ci-cassandra.apache.org/job/Cassandra-4.0/308/
> [3] https://ci-cassandra.apache.org/job/Cassandra-3.11/300/
> [4] https://ci-cassandra.apache.org/job/Cassandra-3.0/234
>
> Looking at the failures they mostly seem to be consistent failures
> although there are some flakes as well. If I understand Josh's
> proposal correctly, and I could be mistaken, but if this vote passes
> it seems we would be unable to cut any release on any branch on the
> project?
>
> -Joey
> .

Re: [VOTE] Formalizing our CI process

[Brandon Williams]

On Wed, Jan 12, 2022 at 1:24 AM Mick Semb Wever  wrote:
>
> Changing my vote to -1, aligned with Joey's concern here. (Thank you for 
> raising it.)
>
> I particularly like the suggestion PMCs can use failing tests as a reason to 
> -1, but we do have critical patch releases now and again and common sense in 
> getting such releases out quickly needs to be applied.

I don't want us to paint ourselves into a corner here either, but
conversely can't the PMC vote to push an exception through if
necessary?

Re: [VOTE] Formalizing our CI process

[Ekaterina Dimitrova]

“I particularly like the suggestion PMCs can use failing tests as a reason
to -1, but we do have critical patch releases now and again and common
sense in getting such releases out quickly needs to be applied. ”

For some reason I assumed this would always be the case in case of
emergency, to consider it on a per case basis. Good catch on the wording!
Thank you Joeye! I think it doesn’t hurt to elaborate a bit more on this to
be sure we are all aligned that there will be special cases. (Hopefully not
many)

On Wed, 12 Jan 2022 at 3:25, Berenguer Blasi 
wrote:

> Hi Joseph
>
> jenkins CI was at 2/3 flakies consistently post 4.0 release. Then things
> broke and we've been working hard to get back to the 2/3 flakies. Most
> current failures imo are timeuuid C17133 or early termination of process
> C17140 related afaik. So getting back to the 2/3 'impossible' flakies
> should be doable and a reasonable target (famous last words...). My 2cts.
>
> Regards
>
> On 12/1/22 7:21, Joseph Lynch wrote:
> > On Wed, Jan 12, 2022 at 12:47 AM Berenguer Blasi
> >  wrote:
> >> We shouldn't be at 15-20 failures but at 2 or 3. The problem is that
> those 2 or 3 have already been hammered for over a year by 2 or 3 different
> committers and they didn't crack.
> >>
> > Last I checked circleci was almost fully green on trunk only, and the
> > asf builds all had around 15-20 failures. For example, as of the last
> > build I checked, trunk had 22 failures [1], 4.0 had 12 [2], 3.11 had
> > 35 [3] and 3.0 had 25 [4].
> >
> > [1] https://ci-cassandra.apache.org/job/Cassandra-trunk/901/
> > [2] https://ci-cassandra.apache.org/job/Cassandra-4.0/308/
> > [3] https://ci-cassandra.apache.org/job/Cassandra-3.11/300/
> > [4] https://ci-cassandra.apache.org/job/Cassandra-3.0/234
> >
> > Looking at the failures they mostly seem to be consistent failures
> > although there are some flakes as well. If I understand Josh's
> > proposal correctly, and I could be mistaken, but if this vote passes
> > it seems we would be unable to cut any release on any branch on the
> > project?
> >
> > -Joey
> > .
>

Re: [VOTE] Formalizing our CI process

[Joseph Lynch]

I've witnessed PMCs -1 releases due to failing tests or bugs reported
by users before, but prior to everyone's awesome work on CI I think a
number of times folks might have been voting without knowing what the
results of the full test runs were. One of the amazing contributions
of this group (and others working on the CI/CD solutions over the
years) is now we have an authoritative "which tests are failing" tool
and I do hope we use it as context during the next release vote as
suggested by this proposal.

I just think it should serve as context, and not a requirement. I also
vote -1 on this specific proposal and will happily change it to +1 if
the language on the release criteria is softened slightly, e.g. "When
a release is proposed, links to the associated test runs on
ci-cassandra.apache.org MUST be provided and members MAY use failing
tests as a valid reason to -1 a release".

-Joey

On Wed, Jan 12, 2022 at 8:11 AM Ekaterina Dimitrova
 wrote:
>
> “I particularly like the suggestion PMCs can use failing tests as a reason to 
> -1, but we do have critical patch releases now and again and common sense in 
> getting such releases out quickly needs to be applied. ”
>
> For some reason I assumed this would always be the case in case of emergency, 
> to consider it on a per case basis. Good catch on the wording! Thank you 
> Joeye! I think it doesn’t hurt to elaborate a bit more on this to be sure we 
> are all aligned that there will be special cases. (Hopefully not many)
>
> On Wed, 12 Jan 2022 at 3:25, Berenguer Blasi  wrote:
>>
>> Hi Joseph
>>
>> jenkins CI was at 2/3 flakies consistently post 4.0 release. Then things
>> broke and we've been working hard to get back to the 2/3 flakies. Most
>> current failures imo are timeuuid C17133 or early termination of process
>> C17140 related afaik. So getting back to the 2/3 'impossible' flakies
>> should be doable and a reasonable target (famous last words...). My 2cts.
>>
>> Regards
>>
>> On 12/1/22 7:21, Joseph Lynch wrote:
>> > On Wed, Jan 12, 2022 at 12:47 AM Berenguer Blasi
>> >  wrote:
>> >> We shouldn't be at 15-20 failures but at 2 or 3. The problem is that 
>> >> those 2 or 3 have already been hammered for over a year by 2 or 3 
>> >> different committers and they didn't crack.
>> >>
>> > Last I checked circleci was almost fully green on trunk only, and the
>> > asf builds all had around 15-20 failures. For example, as of the last
>> > build I checked, trunk had 22 failures [1], 4.0 had 12 [2], 3.11 had
>> > 35 [3] and 3.0 had 25 [4].
>> >
>> > [1] https://ci-cassandra.apache.org/job/Cassandra-trunk/901/
>> > [2] https://ci-cassandra.apache.org/job/Cassandra-4.0/308/
>> > [3] https://ci-cassandra.apache.org/job/Cassandra-3.11/300/
>> > [4] https://ci-cassandra.apache.org/job/Cassandra-3.0/234
>> >
>> > Looking at the failures they mostly seem to be consistent failures
>> > although there are some flakes as well. If I understand Josh's
>> > proposal correctly, and I could be mistaken, but if this vote passes
>> > it seems we would be unable to cut any release on any branch on the
>> > project?
>> >
>> > -Joey
>> > .

Re: [VOTE] Formalizing our CI process

[Joseph Lynch]

On Wed, Jan 12, 2022 at 3:25 AM Berenguer Blasi
 wrote:
>
> jenkins CI was at 2/3 flakies consistently post 4.0 release.

That is really impressive and I absolutely don't mean to downplay that
achievement.

> Then things broke and we've been working hard to get back to the 2/3 flakies. 
> Most
> current failures imo are timeuuid C17133 or early termination of process
> C17140 related afaik. So getting back to the 2/3 'impossible' flakies
> should be doable and a reasonable target (famous last words...). My 2cts.

I really appreciate all the work folks have been doing to get the
project to green, and I support the parts of the proposal that try to
formalize methods to try to keep us there. I am only objecting to #2
in the proposal where we have a non-negotiable gate on tests before a
release.

-Joey

Re: [VOTE] Formalizing our CI process

[Joshua McKenzie]

I fully concede your point and concern Joey but I propose we phrase that
differently to emphasize the importance of clean tests.

"All releases by default are expected to have a green test run on
ci-cassandra Jenkins. In exceptional circumstances (security incidents,
data loss, etc requiring hotfix), members with binding votes on a release
may choose to approve a release with known failing tests."

On Wed, Jan 12, 2022 at 11:36 AM Joseph Lynch  wrote:

> I've witnessed PMCs -1 releases due to failing tests or bugs reported
> by users before, but prior to everyone's awesome work on CI I think a
> number of times folks might have been voting without knowing what the
> results of the full test runs were. One of the amazing contributions
> of this group (and others working on the CI/CD solutions over the
> years) is now we have an authoritative "which tests are failing" tool
> and I do hope we use it as context during the next release vote as
> suggested by this proposal.
>
> I just think it should serve as context, and not a requirement. I also
> vote -1 on this specific proposal and will happily change it to +1 if
> the language on the release criteria is softened slightly, e.g. "When
> a release is proposed, links to the associated test runs on
> ci-cassandra.apache.org MUST be provided and members MAY use failing
> tests as a valid reason to -1 a release".
>
> -Joey
>
> On Wed, Jan 12, 2022 at 8:11 AM Ekaterina Dimitrova
>  wrote:
> >
> > “I particularly like the suggestion PMCs can use failing tests as a
> reason to -1, but we do have critical patch releases now and again and
> common sense in getting such releases out quickly needs to be applied. ”
> >
> > For some reason I assumed this would always be the case in case of
> emergency, to consider it on a per case basis. Good catch on the wording!
> Thank you Joeye! I think it doesn’t hurt to elaborate a bit more on this to
> be sure we are all aligned that there will be special cases. (Hopefully not
> many)
> >
> > On Wed, 12 Jan 2022 at 3:25, Berenguer Blasi 
> wrote:
> >>
> >> Hi Joseph
> >>
> >> jenkins CI was at 2/3 flakies consistently post 4.0 release. Then things
> >> broke and we've been working hard to get back to the 2/3 flakies. Most
> >> current failures imo are timeuuid C17133 or early termination of process
> >> C17140 related afaik. So getting back to the 2/3 'impossible' flakies
> >> should be doable and a reasonable target (famous last words...). My
> 2cts.
> >>
> >> Regards
> >>
> >> On 12/1/22 7:21, Joseph Lynch wrote:
> >> > On Wed, Jan 12, 2022 at 12:47 AM Berenguer Blasi
> >> >  wrote:
> >> >> We shouldn't be at 15-20 failures but at 2 or 3. The problem is that
> those 2 or 3 have already been hammered for over a year by 2 or 3 different
> committers and they didn't crack.
> >> >>
> >> > Last I checked circleci was almost fully green on trunk only, and the
> >> > asf builds all had around 15-20 failures. For example, as of the last
> >> > build I checked, trunk had 22 failures [1], 4.0 had 12 [2], 3.11 had
> >> > 35 [3] and 3.0 had 25 [4].
> >> >
> >> > [1] https://ci-cassandra.apache.org/job/Cassandra-trunk/901/
> >> > [2] https://ci-cassandra.apache.org/job/Cassandra-4.0/308/
> >> > [3] https://ci-cassandra.apache.org/job/Cassandra-3.11/300/
> >> > [4] https://ci-cassandra.apache.org/job/Cassandra-3.0/234
> >> >
> >> > Looking at the failures they mostly seem to be consistent failures
> >> > although there are some flakes as well. If I understand Josh's
> >> > proposal correctly, and I could be mistaken, but if this vote passes
> >> > it seems we would be unable to cut any release on any branch on the
> >> > project?
> >> >
> >> > -Joey
> >> > .
>

Re: [VOTE] Formalizing our CI process

[Joseph Lynch]

On Wed, Jan 12, 2022 at 11:43 AM Joshua McKenzie  wrote:
>
> I fully concede your point and concern Joey but I propose we phrase that 
> differently to emphasize the importance of clean tests.
>
> "All releases by default are expected to have a green test run on 
> ci-cassandra Jenkins. In exceptional circumstances (security incidents, data 
> loss, etc requiring hotfix), members with binding votes on a release may 
> choose to approve a release with known failing tests."

I like the balance that strikes. Should we re-vote or should I propose
that text as an amendment after this vote (since a simple majority
will likely be reached)?

-Joey

Re: [VOTE] Formalizing our CI process

[Joshua McKenzie]

I'd say an amendment with a directional poll would be fine. I don't think
this is controversial.

That's me taking "the spirit of the law" rather than the letter though. I'm
good either way.

~Josh

On Wed, Jan 12, 2022 at 11:51 AM Joseph Lynch  wrote:

> On Wed, Jan 12, 2022 at 11:43 AM Joshua McKenzie 
> wrote:
> >
> > I fully concede your point and concern Joey but I propose we phrase that
> differently to emphasize the importance of clean tests.
> >
> > "All releases by default are expected to have a green test run on
> ci-cassandra Jenkins. In exceptional circumstances (security incidents,
> data loss, etc requiring hotfix), members with binding votes on a release
> may choose to approve a release with known failing tests."
>
> I like the balance that strikes. Should we re-vote or should I propose
> that text as an amendment after this vote (since a simple majority
> will likely be reached)?
>
> -Joey
>

Re: [VOTE] Formalizing our CI process

[Caleb Rackliffe]

+1 w/ Joey's amendment

On Wed, Jan 12, 2022 at 11:04 AM Joshua McKenzie 
wrote:

> I'd say an amendment with a directional poll would be fine. I don't think
> this is controversial.
>
> That's me taking "the spirit of the law" rather than the letter though.
> I'm good either way.
>
> ~Josh
>
> On Wed, Jan 12, 2022 at 11:51 AM Joseph Lynch 
> wrote:
>
>> On Wed, Jan 12, 2022 at 11:43 AM Joshua McKenzie 
>> wrote:
>> >
>> > I fully concede your point and concern Joey but I propose we phrase
>> that differently to emphasize the importance of clean tests.
>> >
>> > "All releases by default are expected to have a green test run on
>> ci-cassandra Jenkins. In exceptional circumstances (security incidents,
>> data loss, etc requiring hotfix), members with binding votes on a release
>> may choose to approve a release with known failing tests."
>>
>> I like the balance that strikes. Should we re-vote or should I propose
>> that text as an amendment after this vote (since a simple majority
>> will likely be reached)?
>>
>> -Joey
>>
>

Re: [VOTE] Formalizing our CI process

[Michael Shuler]

(still) +1 as amended

Michael

On 1/12/22 11:54, Caleb Rackliffe wrote:

+1 w/ Joey's amendment

On Wed, Jan 12, 2022 at 11:04 AM Joshua McKenzie > wrote:


I'd say an amendment with a directional poll would be fine. I don't
think this is controversial.

That's me taking "the spirit of the law" rather than the letter
though. I'm good either way.

~Josh

On Wed, Jan 12, 2022 at 11:51 AM Joseph Lynch mailto:joe.e.ly...@gmail.com>> wrote:

On Wed, Jan 12, 2022 at 11:43 AM Joshua McKenzie
mailto:jmcken...@apache.org>> wrote:
 >
 > I fully concede your point and concern Joey but I propose we
phrase that differently to emphasize the importance of clean tests.
 >
 > "All releases by default are expected to have a green test
run on ci-cassandra Jenkins. In exceptional circumstances
(security incidents, data loss, etc requiring hotfix), members
with binding votes on a release may choose to approve a release
with known failing tests."

I like the balance that strikes. Should we re-vote or should I
propose
that text as an amendment after this vote (since a simple majority
will likely be reached)?

-Joey

Re: [VOTE] Formalizing our CI process

[Ekaterina Dimitrova]

 +1 w/ Joey's amendment

On Wed, 12 Jan 2022 at 13:00, Michael Shuler  wrote:

> (still) +1 as amended
>
> Michael
>
> On 1/12/22 11:54, Caleb Rackliffe wrote:
> > +1 w/ Joey's amendment
> >
> > On Wed, Jan 12, 2022 at 11:04 AM Joshua McKenzie  > > wrote:
> >
> > I'd say an amendment with a directional poll would be fine. I don't
> > think this is controversial.
> >
> > That's me taking "the spirit of the law" rather than the letter
> > though. I'm good either way.
> >
> > ~Josh
> >
> > On Wed, Jan 12, 2022 at 11:51 AM Joseph Lynch  > > wrote:
> >
> > On Wed, Jan 12, 2022 at 11:43 AM Joshua McKenzie
> > mailto:jmcken...@apache.org>> wrote:
> >  >
> >  > I fully concede your point and concern Joey but I propose we
> > phrase that differently to emphasize the importance of clean
> tests.
> >  >
> >  > "All releases by default are expected to have a green test
> > run on ci-cassandra Jenkins. In exceptional circumstances
> > (security incidents, data loss, etc requiring hotfix), members
> > with binding votes on a release may choose to approve a release
> > with known failing tests."
> >
> > I like the balance that strikes. Should we re-vote or should I
> > propose
> > that text as an amendment after this vote (since a simple
> majority
> > will likely be reached)?
> >
> > -Joey
> >
>

Re: [DISCUSS] Next release cut

[Caleb Rackliffe]

+1

On Mon, Jan 3, 2022 at 1:21 PM Brandon Williams  wrote:

> +1 to 4.1 in May.
>
> On Tue, Dec 14, 2021, 6:46 AM Mick Semb Wever  wrote:
>
>> > We cut 4.0 in May and released it in July. It is difficult to plan for a
>> release date so we should probably agree on the cut date. One year after
>> 4.0 that would make us cut the new branch in May.
>>
>>
>> This makes sense to me. The time between each rc1 cut is the only
>> thing we control. We want the rc1 cut to GA published time frame to be
>> minimised (that is the goal of stable-trunk) but that it is a
>> variable, and not something we want to put pressure on or compromise.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>

Re: [VOTE] Formalizing our CI process

[Yifan Cai]

>
> "All releases by default are expected to have a green test run on
> ci-cassandra Jenkins. In exceptional circumstances (security incidents,
> data loss, etc requiring hotfix), members with binding votes on a release
> may choose to approve a release with known failing tests."


+1 with the amendment.

On Wed, Jan 12, 2022 at 10:01 AM Ekaterina Dimitrova 
wrote:

>  +1 w/ Joey's amendment
>
> On Wed, 12 Jan 2022 at 13:00, Michael Shuler 
> wrote:
>
>> (still) +1 as amended
>>
>> Michael
>>
>> On 1/12/22 11:54, Caleb Rackliffe wrote:
>> > +1 w/ Joey's amendment
>> >
>> > On Wed, Jan 12, 2022 at 11:04 AM Joshua McKenzie > > > wrote:
>> >
>> > I'd say an amendment with a directional poll would be fine. I don't
>> > think this is controversial.
>> >
>> > That's me taking "the spirit of the law" rather than the letter
>> > though. I'm good either way.
>> >
>> > ~Josh
>> >
>> > On Wed, Jan 12, 2022 at 11:51 AM Joseph Lynch <
>> joe.e.ly...@gmail.com
>> > > wrote:
>> >
>> > On Wed, Jan 12, 2022 at 11:43 AM Joshua McKenzie
>> > mailto:jmcken...@apache.org>> wrote:
>> >  >
>> >  > I fully concede your point and concern Joey but I propose we
>> > phrase that differently to emphasize the importance of clean
>> tests.
>> >  >
>> >  > "All releases by default are expected to have a green test
>> > run on ci-cassandra Jenkins. In exceptional circumstances
>> > (security incidents, data loss, etc requiring hotfix), members
>> > with binding votes on a release may choose to approve a release
>> > with known failing tests."
>> >
>> > I like the balance that strikes. Should we re-vote or should I
>> > propose
>> > that text as an amendment after this vote (since a simple
>> majority
>> > will likely be reached)?
>> >
>> > -Joey
>> >
>>
>

Re: [VOTE] Formalizing our CI process

[Brandon Williams]

I remain +1 with the amendment.

Re: [VOTE] Formalizing our CI process

[David Capwell]

+1

> On Jan 12, 2022, at 8:39 AM, Joseph Lynch  wrote:
> 
> On Wed, Jan 12, 2022 at 3:25 AM Berenguer Blasi
>  wrote:
>> 
>> jenkins CI was at 2/3 flakies consistently post 4.0 release.
> 
> That is really impressive and I absolutely don't mean to downplay that
> achievement.
> 
>> Then things broke and we've been working hard to get back to the 2/3 
>> flakies. Most
>> current failures imo are timeuuid C17133 or early termination of process
>> C17140 related afaik. So getting back to the 2/3 'impossible' flakies
>> should be doable and a reasonable target (famous last words...). My 2cts.
> 
> I really appreciate all the work folks have been doing to get the
> project to green, and I support the parts of the proposal that try to
> formalize methods to try to keep us there. I am only objecting to #2
> in the proposal where we have a non-negotiable gate on tests before a
> release.
> 
> -Joey

Re: [VOTE] Formalizing our CI process

[C. Scott Andreas]

+1nb, with and without the amendment.Reason for mentioning without: I see the ability to cut a 
release to address an urgent security or data loss issue as one of the strongest arguments for 
maintaining green CI as a resting state so we are ready in the event of an emergency.Test results 
that we can trust help us ship urgent fixes safely. If I were a user and had an urgent need to 
ramp a new build (e.g., if Apache Cassandra were affected by log4j), I would be very concerned 
about a fleet-wide deploy of a distributed database release with failing tests.But in both cases, 
+1nb. :)– ScottOn Jan 12, 2022, at 11:22 AM, David Capwell  wrote:+1On 
Jan 12, 2022, at 8:39 AM, Joseph Lynch  wrote:On Wed, Jan 12, 2022 
at 3:25 AM Berenguer Blasi wrote:jenkins CI was at 2/3 flakies 
consistently post 4.0 release.That is really impressive and I absolutely don't mean to downplay 
thatachievement.Then things broke and we've been working hard to get back to the 2/3 flakies. 
Mostcurrent failures imo are timeuuid C17133 or early termination of processC17140 related afaik. 
So getting back to the 2/3 'impossible' flakiesshould be doable and a reasonable target (famous 
last words...). My 2cts.I really appreciate all the work folks have been doing to get theproject 
to green, and I support the parts of the proposal that try toformalize methods to try to keep us 
there. I am only objecting to #2in the proposal where we have a non-negotiable gate on tests 
before arelease.-Joey

Re: [VOTE] Formalizing our CI process

[Jeremiah D Jordan]

I agree with Scott’s sentiments.  If we are keeping a green CI then an urgent 
release with green CI should not be hard.  In the worst case you do the 
“urgent” release as a single commit fix on top of the previous release tag, not 
by cutting the current dev branch, in that case you should easily have green CI 
assuming the urgent fix does not break tests, and if it does I would -1 
releasing it…

But I am fine with leaving some wiggle room in the wording.

-Jeremiah

> On Jan 12, 2022, at 1:57 PM, C. Scott Andreas  wrote:
> 
> +1nb, with and without the amendment.
> 
> Reason for mentioning without: I see the ability to cut a release to address 
> an urgent security or data loss issue as one of the strongest arguments for 
> maintaining green CI as a resting state so we are ready in the event of an 
> emergency.
> 
> Test results that we can trust help us ship urgent fixes safely. If I were a 
> user and had an urgent need to ramp a new build (e.g., if Apache Cassandra 
> were affected by log4j), I would be very concerned about a fleet-wide deploy 
> of a distributed database release with failing tests.
> 
> But in both cases, +1nb. :)
> 
> – Scott
> 
>> On Jan 12, 2022, at 11:22 AM, David Capwell  wrote:
>> 
>> 
>> +1
>> 
>>> On Jan 12, 2022, at 8:39 AM, Joseph Lynch  wrote:
>>> 
>>> On Wed, Jan 12, 2022 at 3:25 AM Berenguer Blasi
>>>  wrote:
 
 jenkins CI was at 2/3 flakies consistently post 4.0 release.
>>> 
>>> That is really impressive and I absolutely don't mean to downplay that
>>> achievement.
>>> 
 Then things broke and we've been working hard to get back to the 2/3 
 flakies. Most
 current failures imo are timeuuid C17133 or early termination of process
 C17140 related afaik. So getting back to the 2/3 'impossible' flakies
 should be doable and a reasonable target (famous last words...). My 2cts.
>>> 
>>> I really appreciate all the work folks have been doing to get the
>>> project to green, and I support the parts of the proposal that try to
>>> formalize methods to try to keep us there. I am only objecting to #2
>>> in the proposal where we have a non-negotiable gate on tests before a
>>> release.
>>> 
>>> -Joey
> 

Re: [VOTE] Formalizing our CI process

[Andrés de la Peña]

Still +1 with the amendment

On Wed, 12 Jan 2022 at 19:57, C. Scott Andreas  wrote:

> +1nb, with and without the amendment.
>
> Reason for mentioning without: I see the ability to cut a release to
> address an urgent security or data loss issue as one of the strongest
> arguments for maintaining green CI as a resting state so we are ready in
> the event of an emergency.
>
> Test results that we can trust help us ship urgent fixes safely. If I were
> a user and had an urgent need to ramp a new build (e.g., if Apache
> Cassandra were affected by log4j), I would be very concerned about a
> fleet-wide deploy of a distributed database release with failing tests.
>
> But in both cases, +1nb. :)
>
> – Scott
>
> On Jan 12, 2022, at 11:22 AM, David Capwell  wrote:
>
>
> +1
>
> On Jan 12, 2022, at 8:39 AM, Joseph Lynch  wrote:
>
> On Wed, Jan 12, 2022 at 3:25 AM Berenguer Blasi
>  wrote:
>
>
> jenkins CI was at 2/3 flakies consistently post 4.0 release.
>
>
> That is really impressive and I absolutely don't mean to downplay that
> achievement.
>
> Then things broke and we've been working hard to get back to the 2/3
> flakies. Most
> current failures imo are timeuuid C17133 or early termination of process
> C17140 related afaik. So getting back to the 2/3 'impossible' flakies
> should be doable and a reasonable target (famous last words...). My 2cts.
>
>
> I really appreciate all the work folks have been doing to get the
> project to green, and I support the parts of the proposal that try to
> formalize methods to try to keep us there. I am only objecting to #2
> in the proposal where we have a non-negotiable gate on tests before a
> release.
>
> -Joey
>
>
>

Re: [VOTE] Formalizing our CI process

[Francisco Guerrero]

+1nb with the amendment 

On 2022/01/12 21:03:08 Andrés de la Peña wrote:
> Still +1 with the amendment
> 
> On Wed, 12 Jan 2022 at 19:57, C. Scott Andreas  wrote:
> 
> > +1nb, with and without the amendment.
> >
> > Reason for mentioning without: I see the ability to cut a release to
> > address an urgent security or data loss issue as one of the strongest
> > arguments for maintaining green CI as a resting state so we are ready in
> > the event of an emergency.
> >
> > Test results that we can trust help us ship urgent fixes safely. If I were
> > a user and had an urgent need to ramp a new build (e.g., if Apache
> > Cassandra were affected by log4j), I would be very concerned about a
> > fleet-wide deploy of a distributed database release with failing tests.
> >
> > But in both cases, +1nb. :)
> >
> > – Scott
> >
> > On Jan 12, 2022, at 11:22 AM, David Capwell  wrote:
> >
> >
> > +1
> >
> > On Jan 12, 2022, at 8:39 AM, Joseph Lynch  wrote:
> >
> > On Wed, Jan 12, 2022 at 3:25 AM Berenguer Blasi
> >  wrote:
> >
> >
> > jenkins CI was at 2/3 flakies consistently post 4.0 release.
> >
> >
> > That is really impressive and I absolutely don't mean to downplay that
> > achievement.
> >
> > Then things broke and we've been working hard to get back to the 2/3
> > flakies. Most
> > current failures imo are timeuuid C17133 or early termination of process
> > C17140 related afaik. So getting back to the 2/3 'impossible' flakies
> > should be doable and a reasonable target (famous last words...). My 2cts.
> >
> >
> > I really appreciate all the work folks have been doing to get the
> > project to green, and I support the parts of the proposal that try to
> > formalize methods to try to keep us there. I am only objecting to #2
> > in the proposal where we have a non-negotiable gate on tests before a
> > release.
> >
> > -Joey
> >
> >
> >
> 

Re: [VOTE] Formalizing our CI process

[Mick Semb Wever]

>
>
> "All releases by default are expected to have a green test run on
> ci-cassandra Jenkins. In exceptional circumstances (security incidents,
> data loss, etc requiring hotfix), members with binding votes on a release
> may choose to approve a release with known failing tests."
>


+1, thanks Josh.

Re: [VOTE] Formalizing our CI process

[Joseph Lynch]

> "All releases by default are expected to have a green test run on 
> ci-cassandra Jenkins. In exceptional circumstances (security incidents, data 
> loss, etc requiring hotfix), members with binding votes on a release may 
> choose to approve a release with known failing tests."

+1 with amendment, thank you for driving this!

-Joey

[DISCUSS] Marketing contributions

[Melissa Logan]

Chris Thornett, Diogenese Topper and I compiled a recap of the marketing
work we contributed to Cassandra in 2021. We also developed a recommended
approach for 2022. Our aim is to be a resource that advances the
community's interests, so we would greatly appreciate your input here
and/or in the deck:

https://docs.google.com/presentation/d/1tPbU1CtRPvn6tlbuKcYkJL6Wzj0mFzj5OiixSkM5o_Q/edit?usp=sharing

1. Is the recommended approach aligned with what the community wants to
achieve this year? If not, what would you modify?

2. What are the community's thoughts on items in the Ideas &
Recommendations section? Do you have other ideas not represented here we
could help with?

3. Generally speaking, what's working and what's not? We appreciate
feedback so we can best support.

4. One of our key challenges has been getting our website pull requests
(blogs, homepage updates etc.) committed in a timely manner so the
thousands of daily visitors see the most current info. We are grateful for
the ongoing support of Mick, Erick et al and wonder if others could pitch
in ongoing? It's typically no more than one commit per week; discussed on
the #cassandra-website channel. Appreciate your consideration.

Looking forward to your input.

Melissa

[DICSUSS] Marketing contributions

[Melissa Logan]

Chris Thornett, Diogenese Topper and I compiled a recap of the marketing
work we contributed to Cassandra in 2021. We also developed a recommended
approach for 2022. Our aim is to be a resource that advances the
community's interests, so we would greatly appreciate your input here
and/or in the deck:

https://docs.google.com/presentation/d/1tPbU1CtRPvn6tlbuKcYkJL6Wzj0mFzj5OiixSkM5o_Q/edit?usp=sharing

1. Is the recommended approach aligned with what the community wants to
achieve this year? If not, what would you modify?

2. What are the community's thoughts on items in the Ideas &
Recommendations section? Do you have other ideas not represented here we
could help with?

3. Generally speaking, what's working and what's not? We appreciate
feedback so we can best support.

4. One of our key challenges has been getting our website pull requests
(blogs, homepage updates etc.) committed in a timely manner so the
thousands of daily visitors see the most current info. We are grateful for
the ongoing support of Mick, Erick et al and wonder if others could pitch
in ongoing? It's typically no more than one commit per week; discussed on
the #cassandra-website channel. Appreciate your consideration.

Looking forward to your input.

Melissa

Re: [VOTE] Formalizing our CI process

[Berenguer Blasi]

Oh I completely agree with you. I was just trying to explain that
getting to 2/3 failures is a realistic target.

+1 also on the amendment.

On 12/1/22 17:39, Joseph Lynch wrote:
> On Wed, Jan 12, 2022 at 3:25 AM Berenguer Blasi
>  wrote:
>> jenkins CI was at 2/3 flakies consistently post 4.0 release.
> That is really impressive and I absolutely don't mean to downplay that
> achievement.
>
>> Then things broke and we've been working hard to get back to the 2/3 
>> flakies. Most
>> current failures imo are timeuuid C17133 or early termination of process
>> C17140 related afaik. So getting back to the 2/3 'impossible' flakies
>> should be doable and a reasonable target (famous last words...). My 2cts.
> I really appreciate all the work folks have been doing to get the
> project to green, and I support the parts of the proposal that try to
> formalize methods to try to keep us there. I am only objecting to #2
> in the proposal where we have a non-negotiable gate on tests before a
> release.
>
> -Joey
> .