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. > >>> > > >
