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