Re: [VOTE] Release Apache Cassandra 4.0.4 (take2)
+1 On Sat, May 07, 2022 at 08:39:10AM +0200, Mick Semb Wever wrote: > Proposing the test build of Cassandra 4.0.4 for release. > This is from the (take4) test artifact. > > sha1: 052125f2c6ed308f1473355dfe43470f0da44364 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.4-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1270/org/apache/cassandra/cassandra-all/4.0.4/ > > 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.4/ > > 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.4-tentative > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.4-tentative
Re: [VOTE] Release Apache Cassandra 3.0.27
+1 On Sat, May 07, 2022 at 08:37:38AM +0200, Mick Semb Wever wrote: > Proposing the test build of Cassandra 3.0.27 for release. > > sha1: 205366131484967a3a8a749f1d1d841c952127e8 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.27-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1267/org/apache/cassandra/cassandra-all/3.0.27/ > > 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.27/ > > 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.27-tentative > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.27-tentative
Re: [VOTE] Release Apache Cassandra 3.11.13
+1 On Sat, May 07, 2022 at 08:38:04AM +0200, Mick Semb Wever wrote: > Proposing the test build of Cassandra 3.11.13 for release. > > sha1: 836ab2802521a685efe84382cb48db56caf4478d > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.13-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1268/org/apache/cassandra/cassandra-all/3.11.13/ > > 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.13/ > > 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.13-tentative > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.13-tentative
Re: [VOTE] Release Apache Cassandra 3.0.27
+1 > On 7 May 2022, at 07:37, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.0.27 for release. > > sha1: 205366131484967a3a8a749f1d1d841c952127e8 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.27-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1267/org/apache/cassandra/cassandra-all/3.0.27/ > > 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.27/ > > 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.27-tentative > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.27-tentative
Re: [VOTE] Release Apache Cassandra 3.11.13
+1 > On 7 May 2022, at 07:38, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.11.13 for release. > > sha1: 836ab2802521a685efe84382cb48db56caf4478d > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.13-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1268/org/apache/cassandra/cassandra-all/3.11.13/ > > 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.13/ > > 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.13-tentative > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.13-tentative
Re: [VOTE] Release Apache Cassandra 4.0.4 (take2)
+1 > On 7 May 2022, at 07:39, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.0.4 for release. > This is from the (take4) test artifact. > > sha1: 052125f2c6ed308f1473355dfe43470f0da44364 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.4-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1270/org/apache/cassandra/cassandra-all/4.0.4/ > > 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.4/ > > 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.4-tentative > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.4-tentative
Re: [VOTE] Release Apache Cassandra 3.0.27
+1 (nb) On Wed, 11 May 2022 at 08:59, Sam Tunnicliffe wrote: > +1 > > > On 7 May 2022, at 07:37, Mick Semb Wever wrote: > > > > Proposing the test build of Cassandra 3.0.27 for release. > > > > sha1: 205366131484967a3a8a749f1d1d841c952127e8 > > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.27-tentative > > Maven Artifacts: > > > https://repository.apache.org/content/repositories/orgapachecassandra-1267/org/apache/cassandra/cassandra-all/3.0.27/ > > > > 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.27/ > > > > 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.27-tentative > > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.27-tentative > >
Re: [VOTE] Release Apache Cassandra 3.11.13
+1 (nb) On Wed, 11 May 2022 at 09:00, Sam Tunnicliffe wrote: > +1 > > > On 7 May 2022, at 07:38, Mick Semb Wever wrote: > > > > Proposing the test build of Cassandra 3.11.13 for release. > > > > sha1: 836ab2802521a685efe84382cb48db56caf4478d > > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.13-tentative > > Maven Artifacts: > > > https://repository.apache.org/content/repositories/orgapachecassandra-1268/org/apache/cassandra/cassandra-all/3.11.13/ > > > > 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.13/ > > > > 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.13-tentative > > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.13-tentative > >
Re: [VOTE] Release Apache Cassandra 4.0.4 (take2)
+1 (nb) On Wed, 11 May 2022 at 09:00, Sam Tunnicliffe wrote: > +1 > > > On 7 May 2022, at 07:39, Mick Semb Wever wrote: > > > > Proposing the test build of Cassandra 4.0.4 for release. > > This is from the (take4) test artifact. > > > > sha1: 052125f2c6ed308f1473355dfe43470f0da44364 > > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.4-tentative > > Maven Artifacts: > > > https://repository.apache.org/content/repositories/orgapachecassandra-1270/org/apache/cassandra/cassandra-all/4.0.4/ > > > > 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.4/ > > > > 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.4-tentative > > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.4-tentative > >
Re: How we flag tickets as blockers during freeze
I've updated all the 4.1.x tickets to be either 4.1-beta or 4.1-rc (we didn't have any API changers that'd qualify for alpha blockers). Kanban board swimlanes and quick filters are updated; a link to the board showing our open tickets blocking 4.1 GA can be found here: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2455 Thanks! ~Josh On Wed, May 11, 2022, at 12:30 AM, Berenguer Blasi wrote: > +1 also from me. Merging versions or bulk updating should solve the post > release version consolidation. We just need to enable that if that'd be > the case. > > On 10/5/22 16:20, J. D. Jordan wrote: > > +1 from me. > > > >> On May 10, 2022, at 9:17 AM, Josh McKenzie wrote: > >> > >> > >>> at some later point it needs to be "easy" for > >>> someone else to correct it. > >> I don't want to optimize for cleaning up later; I want to optimize for our > >> ability to know our workload blocking our next release and encouraging > >> contributors to focus their efforts if they're so inclined. > >> > >> That said, I'm in favor now of adding the unreleased versions for -alpha, > >> -beta, and -rc, and flipping to the major/minor on resolution. We should > >> also codify this in our release lifecycle wiki article so we don't have to > >> revisit the topic. > >> > >> I think this solution is compatible with what everyone on the thread has > >> said thus far, so if nobody has any major concerns, later today I will: > >> > >> 1. Add a 4.1-alpha, 4.1-beta, and 4.1-rc FixVersion (unreleased) > >> 2. Update fixversion on tickets that are blocking each release > >> respectively based on our lifecycle process > >> 3. Update our kanban board to have swimlanes for each phase of the release > >> 4. Update the lifecycle cwiki w/this process for future releases > >> > >> ~Josh > >> > >>> On Tue, May 10, 2022, at 2:23 AM, Mick Semb Wever wrote: > Why do you need to change anything post release? The whole point is to > set the version to the release the ticket blocks. So you don’t need to > change anything. > > >>> > >>> There's always many issues left with the wrong fixVersion. And we > >>> can't police that. So at some later point it needs to be "easy" for > >>> someone else to correct it. > >>> >
Re: How we flag tickets as blockers during freeze
Hi Josh, Thank you for the efforts. I wanted to raise two points: 1) some of the test tickets are in triage and even if they are marked beta blockers they do not appear on the board - I will take care of those in the next hour or so to move them to open 2) during all the discussions some of the community members were marking blockers with 4.1, those also need to be triaged. So my request would be probably to everyone to check what assigned tickets they have and move them to appropriate versions so they pop up at the right places Thanks On Wed, 11 May 2022 at 13:26, Josh McKenzie wrote: > I've updated all the 4.1.x tickets to be either 4.1-beta or 4.1-rc (we > didn't have any API changers that'd qualify for alpha blockers). > > Kanban board swimlanes and quick filters are updated; a link to the board > showing our open tickets blocking 4.1 GA can be found here: > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2455 > > Thanks! > > > ~Josh > > On Wed, May 11, 2022, at 12:30 AM, Berenguer Blasi wrote: > > +1 also from me. Merging versions or bulk updating should solve the post > release version consolidation. We just need to enable that if that'd be > the case. > > On 10/5/22 16:20, J. D. Jordan wrote: > > +1 from me. > > > >> On May 10, 2022, at 9:17 AM, Josh McKenzie > wrote: > >> > >> > >>> at some later point it needs to be "easy" for > >>> someone else to correct it. > >> I don't want to optimize for cleaning up later; I want to optimize for > our ability to know our workload blocking our next release and encouraging > contributors to focus their efforts if they're so inclined. > >> > >> That said, I'm in favor now of adding the unreleased versions for > -alpha, -beta, and -rc, and flipping to the major/minor on resolution. We > should also codify this in our release lifecycle wiki article so we don't > have to revisit the topic. > >> > >> I think this solution is compatible with what everyone on the thread > has said thus far, so if nobody has any major concerns, later today I will: > >> > >> 1. Add a 4.1-alpha, 4.1-beta, and 4.1-rc FixVersion (unreleased) > >> 2. Update fixversion on tickets that are blocking each release > respectively based on our lifecycle process > >> 3. Update our kanban board to have swimlanes for each phase of the > release > >> 4. Update the lifecycle cwiki w/this process for future releases > >> > >> ~Josh > >> > >>> On Tue, May 10, 2022, at 2:23 AM, Mick Semb Wever wrote: > Why do you need to change anything post release? The whole point is > to set the version to the release the ticket blocks. So you don’t need to > change anything. > > >>> > >>> There's always many issues left with the wrong fixVersion. And we > >>> can't police that. So at some later point it needs to be "easy" for > >>> someone else to correct it. > >>> > > >
Re: How we flag tickets as blockers during freeze
Looks like we have 7 tickets 4.1 unresolved. Will update those now. https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%204.1%20and%20resolution%20%3D%20unresolved Thanks for the heads up Ekaterina! On Wed, May 11, 2022, at 1:54 PM, Ekaterina Dimitrova wrote: > Hi Josh, > Thank you for the efforts. > I wanted to raise two points: > 1) some of the test tickets are in triage and even if they are marked beta > blockers they do not appear on the board - I will take care of those in the > next hour or so to move them to open > 2) during all the discussions some of the community members were marking > blockers with 4.1, those also need to be triaged. So my request would be > probably to everyone to check what assigned tickets they have and move them > to appropriate versions so they pop up at the right places > > Thanks > > > On Wed, 11 May 2022 at 13:26, Josh McKenzie wrote: >> __ >> I've updated all the 4.1.x tickets to be either 4.1-beta or 4.1-rc (we >> didn't have any API changers that'd qualify for alpha blockers). >> >> Kanban board swimlanes and quick filters are updated; a link to the board >> showing our open tickets blocking 4.1 GA can be found here: >> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2455 >> >> Thanks! >> >> >> ~Josh >> >> On Wed, May 11, 2022, at 12:30 AM, Berenguer Blasi wrote: >>> +1 also from me. Merging versions or bulk updating should solve the post >>> release version consolidation. We just need to enable that if that'd be >>> the case. >>> >>> On 10/5/22 16:20, J. D. Jordan wrote: >>> > +1 from me. >>> > >>> >> On May 10, 2022, at 9:17 AM, Josh McKenzie wrote: >>> >> >>> >> >>> >>> at some later point it needs to be "easy" for >>> >>> someone else to correct it. >>> >> I don't want to optimize for cleaning up later; I want to optimize for >>> >> our ability to know our workload blocking our next release and >>> >> encouraging contributors to focus their efforts if they're so inclined. >>> >> >>> >> That said, I'm in favor now of adding the unreleased versions for >>> >> -alpha, -beta, and -rc, and flipping to the major/minor on resolution. >>> >> We should also codify this in our release lifecycle wiki article so we >>> >> don't have to revisit the topic. >>> >> >>> >> I think this solution is compatible with what everyone on the thread has >>> >> said thus far, so if nobody has any major concerns, later today I will: >>> >> >>> >> 1. Add a 4.1-alpha, 4.1-beta, and 4.1-rc FixVersion (unreleased) >>> >> 2. Update fixversion on tickets that are blocking each release >>> >> respectively based on our lifecycle process >>> >> 3. Update our kanban board to have swimlanes for each phase of the >>> >> release >>> >> 4. Update the lifecycle cwiki w/this process for future releases >>> >> >>> >> ~Josh >>> >> >>> >>> On Tue, May 10, 2022, at 2:23 AM, Mick Semb Wever wrote: >>> Why do you need to change anything post release? The whole point is >>> to set the version to the release the ticket blocks. So you don’t need >>> to change anything. >>> >>> >>> >>> >>> There's always many issues left with the wrong fixVersion. And we >>> >>> can't police that. So at some later point it needs to be "easy" for >>> >>> someone else to correct it. >>> >>> >>> >>
Re: How we flag tickets as blockers during freeze
Unfortunately, I am also not sure whether also some of the 4.x tickets are not forgotten to be moved to be 4.1.x after branching. I can try to filter them tomorrow and see what we have but I already saw one flaky test ticket which made me think… To me any 4.x ticket opened before 1st May is actual 4.1.x ticket On Wed, 11 May 2022 at 16:16, Josh McKenzie wrote: > Looks like we have 7 tickets 4.1 unresolved. Will update those now. > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%204.1%20and%20resolution%20%3D%20unresolved > > Thanks for the heads up Ekaterina! > > On Wed, May 11, 2022, at 1:54 PM, Ekaterina Dimitrova wrote: > > Hi Josh, > Thank you for the efforts. > I wanted to raise two points: > 1) some of the test tickets are in triage and even if they are marked beta > blockers they do not appear on the board - I will take care of those in the > next hour or so to move them to open > 2) during all the discussions some of the community members were marking > blockers with 4.1, those also need to be triaged. So my request would be > probably to everyone to check what assigned tickets they have and move them > to appropriate versions so they pop up at the right places > > Thanks > > > On Wed, 11 May 2022 at 13:26, Josh McKenzie wrote: > > > I've updated all the 4.1.x tickets to be either 4.1-beta or 4.1-rc (we > didn't have any API changers that'd qualify for alpha blockers). > > Kanban board swimlanes and quick filters are updated; a link to the board > showing our open tickets blocking 4.1 GA can be found here: > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2455 > > Thanks! > > > ~Josh > > On Wed, May 11, 2022, at 12:30 AM, Berenguer Blasi wrote: > > +1 also from me. Merging versions or bulk updating should solve the post > release version consolidation. We just need to enable that if that'd be > the case. > > On 10/5/22 16:20, J. D. Jordan wrote: > > +1 from me. > > > >> On May 10, 2022, at 9:17 AM, Josh McKenzie > wrote: > >> > >> > >>> at some later point it needs to be "easy" for > >>> someone else to correct it. > >> I don't want to optimize for cleaning up later; I want to optimize for > our ability to know our workload blocking our next release and encouraging > contributors to focus their efforts if they're so inclined. > >> > >> That said, I'm in favor now of adding the unreleased versions for > -alpha, -beta, and -rc, and flipping to the major/minor on resolution. We > should also codify this in our release lifecycle wiki article so we don't > have to revisit the topic. > >> > >> I think this solution is compatible with what everyone on the thread > has said thus far, so if nobody has any major concerns, later today I will: > >> > >> 1. Add a 4.1-alpha, 4.1-beta, and 4.1-rc FixVersion (unreleased) > >> 2. Update fixversion on tickets that are blocking each release > respectively based on our lifecycle process > >> 3. Update our kanban board to have swimlanes for each phase of the > release > >> 4. Update the lifecycle cwiki w/this process for future releases > >> > >> ~Josh > >> > >>> On Tue, May 10, 2022, at 2:23 AM, Mick Semb Wever wrote: > Why do you need to change anything post release? The whole point is > to set the version to the release the ticket blocks. So you don’t need to > change anything. > > >>> > >>> There's always many issues left with the wrong fixVersion. And we > >>> can't police that. So at some later point it needs to be "easy" for > >>> someone else to correct it. > >>> > > > >
