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 <jmcken...@apache.org> 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 <jmcken...@apache.org> 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. >>> >>> >>> >>
