4.x open bugs == 4.1.x 4.x open improvements become 4.2 4.x open new features become 4.2
I went through and flagged failing tests in butler on the 4.1 line as 4.1-beta (don't release beta with flaky tests as per release lifecycle doc) We can either have someone(s) go through the 4.x bugfix tickets and see if they think any of them should be included in 4.1, or we can lean on folks interested in certain work to flag those tickets themselves and get caught by the filter (which we've already done). If we're feature complete and pass all tests in 4.1 and burn down all the tickets we currently have flagged as 4.1-alpha, 4.1-beta, or 4.1-rc I think we'll be in a good spot. On Thu, May 12, 2022, at 12:23 AM, Ekaterina Dimitrova wrote: > 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. >>>>> >>> >>>>> >>>> >>
