+1 to waiver On Tue, 15 Nov 2022 at 05:54, Berenguer Blasi <berenguerbl...@gmail.com> wrote:
> +1 to waiver > On 15/11/22 2:07, Josh McKenzie wrote: > > +1 to waiver. > > We still don't have some kind of @flaky annotation that sequesters tests > do we? :) > > On Mon, Nov 14, 2022, at 5:58 PM, Ekaterina Dimitrova wrote: > > +1 > > On Mon, 14 Nov 2022 at 17:55, Brandon Williams <dri...@gmail.com> wrote: > > +1 to waiving these. > > On Mon, Nov 14, 2022, 4:49 PM Miklosovic, Stefan < > stefan.mikloso...@netapp.com> wrote: > > Tickets for the flaky tests are here > > https://issues.apache.org/jira/browse/CASSANDRA-18047 > https://issues.apache.org/jira/browse/CASSANDRA-18048 > > ________________________________________ > From: Mick Semb Wever <m...@apache.org> > Sent: Monday, November 14, 2022 23:28 > To: dev@cassandra.apache.org > Subject: Re: Some tests are never executed in CI due to their name > > 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. > > > > > in CASSANDRA-18029, two flaky tests were committed by mistake due to my > misunderstanding. We agreed on this thread that we should not commit flaky > tests right before rc. So now the rc is technically blocked by them. To > unblock it, what is needed is to have a waiver on them. If there is not a > waiver, I need to go back to that test and remove the two test methods > which are flaky. (In practice they will be probably just @Ignore-ed with > comment about flakiness so we can fix them later). > > Flaky tests are > > > org.apache.cassandra.distributed.test.PaxosRepair2Test.paxosRepairHistoryIsntUpdatedInForcedRepair > > org.apache.cassandra.distributed.test.PaxosRepair2Test.legacyPurgeRepairLoop > > > +1 to a waiver on these two 4.1 flaky regressions to the RC and GA > releases. > > Thanks for bringing it back to dev@ Stefan. Waivers should be done on dev@ > (build/release managers can't be keeping up with every ticket), and dev > threads and tickets should be kept (reasonably) in-sync, for the sake of > inclusiveness. > > I believe there will be follow up tickets to address these flakies in > 4.1.x ? > > >
