Re: How we flag tickets as blockers during freeze
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 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=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=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=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=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
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=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
+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
+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
> 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
> 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
Overloading fixVersion shouldn't be a problem. IIRC you can: - bulk update - Merge versions: https://support.atlassian.com/jira-work-management/docs/view-and-manage-a-projects-versions/#Merge-versions We just need the permissions for jira to allow us to do it. Regards On 10/5/22 3:02, Mick Semb Wever wrote: Thus anything unresolved flagged 4.1-alpha would be a blocker for that, same for beta and rc. When the tickets are closed, we switch them to FixVersion 4.1; I don't see there being much value in knowing in the future if a ticket is fixed during the alpha, beta, or rc phases by using the above as resolved FixVersions. Users might want to know this distinction? Do we want parity between CHANGES.txt and jira fixVersions? This approach potentially breaks down if we have any final blockers on 4.1 ga, but could just cycle through 4.1-rc until it's all clear. What do we do for a blocker to any other version, e.g. say there's a blocker to 4.0.5? (As has been discussed on slack, the priority and severity fields don't really work for us here.) > We have done similar in the past and if something is a blocker it means it will be in that version before it is released Jeremiah, around when was this? I can see that it makes sense (works in theory), but trying to correct fixVersions in jira post release can be quite the headache, without having to reach out to people to understand if something is intentional or a mistake. So long as there's a way to bulk change issues after a release I am happy.
Re: How we flag tickets as blockers during freeze
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. > On May 9, 2022, at 8:03 PM, Mick Semb Wever wrote: > > Jeremiah, around when was this? I can see that it makes sense (works in > theory), but trying to correct fixVersions in jira post release can be quite > the headache, without having to reach out to people to understand if > something is intentional or a mistake. So long as there's a way to bulk > change issues after a release I am happy.
Re: How we flag tickets as blockers during freeze
> > > Thus anything unresolved flagged 4.1-alpha would be a blocker for that, > same for beta and rc. When the tickets are closed, we switch them to > FixVersion 4.1; I don't see there being much value in knowing in the future > if a ticket is fixed during the alpha, beta, or rc phases by using the > above as resolved FixVersions. > Users might want to know this distinction? Do we want parity between CHANGES.txt and jira fixVersions? > This approach potentially breaks down if we have any final blockers on 4.1 > ga, but could just cycle through 4.1-rc until it's all clear. > What do we do for a blocker to any other version, e.g. say there's a blocker to 4.0.5? (As has been discussed on slack, the priority and severity fields don't really work for us here.) > We have done similar in the past and if something is a blocker it means it will be in that version before it is released Jeremiah, around when was this? I can see that it makes sense (works in theory), but trying to correct fixVersions in jira post release can be quite the headache, without having to reach out to people to understand if something is intentional or a mistake. So long as there's a way to bulk change issues after a release I am happy.
Re: How we flag tickets as blockers during freeze
And back to the point - 4.1.0 which? Alpha, beta or rc? As we have that on the table too. On Mon, 9 May 2022 at 18:59, David Capwell wrote: > I am in favor of option 1. If you are 4.1.0 and not resolved, then we > either need to kick you out of the 4.1.0 release (as you are not a blocker) > or you are a blocker for that release and must be fixed in 4.1.0 > > > On May 9, 2022, at 2:49 PM, bened...@apache.org wrote: > > I think this is close to what we settled on last we hashed this out. > > > *From: *Josh McKenzie > *Date: *Monday, 9 May 2022 at 22:47 > *To: *dev@cassandra.apache.org > *Subject: *Re: How we flag tickets as blockers during freeze > As you mentioned on slack, we can introduce FixVersions for the unreleased > interim versions specified in the lifecycle wiki ( > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle), > so add the following specific *unresolved placeholder FixVersions*: > > 4.1-alpha > 4.1-beta > 4.1-rc > > Thus anything unresolved flagged 4.1-alpha would be a blocker for that, > same for beta and rc. When the tickets are closed, we switch them to > FixVersion 4.1; I don't see there being much value in knowing in the future > if a ticket is fixed during the alpha, beta, or rc phases by using the > above as resolved FixVersions. > > This approach potentially breaks down if we have any final blockers on 4.1 > ga, but could just cycle through 4.1-rc until it's all clear. > > On Mon, May 9, 2022, at 5:07 PM, Mick Semb Wever wrote: > > Any other opinions or ideas out there? Would like to tidy our tickets up > as build lead and scope out remaining work for 4.1. > > > > My request is that we don't overload fixVersions. That is, a fixVersion is > either for resolved tickets, or a placeholder for unresolved, but never > both. > This makes it easier with jira hygiene post release, ensuring issues do > get properly assigned their correct fixVersion. (This work can be many > tickets and already quite cumbersome, but it is valued by users.) > > It would also be nice to try keep what is a placeholder fixVersion as > intuitively as possible. The easiest way I see us doing this is to avoid > using patch numbers. This rules out Option 1. > > While the use of 4.0 and 4.1 as resolved fixVersions kinda breaks the > above notion of "if it doesn't have a patch version then it's a > placeholder". The precedence here is that all resolved tickets before the > first .0 of a major gets this short-hand version (and often in addition to > the alpha1, beta1, rc1 fixVersions). > > >
Re: How we flag tickets as blockers during freeze
I am in favor of option 1. If you are 4.1.0 and not resolved, then we either need to kick you out of the 4.1.0 release (as you are not a blocker) or you are a blocker for that release and must be fixed in 4.1.0 > On May 9, 2022, at 2:49 PM, bened...@apache.org wrote: > > I think this is close to what we settled on last we hashed this out. > > From: Josh McKenzie > Date: Monday, 9 May 2022 at 22:47 > To: dev@cassandra.apache.org > Subject: Re: How we flag tickets as blockers during freeze > > As you mentioned on slack, we can introduce FixVersions for the unreleased > interim versions specified in the lifecycle wiki > (https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle > <https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle>), > so add the following specific unresolved placeholder FixVersions: > > 4.1-alpha > 4.1-beta > 4.1-rc > > Thus anything unresolved flagged 4.1-alpha would be a blocker for that, same > for beta and rc. When the tickets are closed, we switch them to FixVersion > 4.1; I don't see there being much value in knowing in the future if a ticket > is fixed during the alpha, beta, or rc phases by using the above as resolved > FixVersions. > > This approach potentially breaks down if we have any final blockers on 4.1 > ga, but could just cycle through 4.1-rc until it's all clear. > > On Mon, May 9, 2022, at 5:07 PM, Mick Semb Wever wrote: > Any other opinions or ideas out there? Would like to tidy our tickets up as > build lead and scope out remaining work for 4.1. > > > My request is that we don't overload fixVersions. That is, a fixVersion is > either for resolved tickets, or a placeholder for unresolved, but never both. > This makes it easier with jira hygiene post release, ensuring issues do get > properly assigned their correct fixVersion. (This work can be many tickets > and already quite cumbersome, but it is valued by users.) > > It would also be nice to try keep what is a placeholder fixVersion as > intuitively as possible. The easiest way I see us doing this is to avoid > using patch numbers. This rules out Option 1. > > While the use of 4.0 and 4.1 as resolved fixVersions kinda breaks the above > notion of "if it doesn't have a patch version then it's a placeholder". The > precedence here is that all resolved tickets before the first .0 of a major > gets this short-hand version (and often in addition to the alpha1, beta1, rc1 > fixVersions).
Re: How we flag tickets as blockers during freeze
I think this is close to what we settled on last we hashed this out. From: Josh McKenzie Date: Monday, 9 May 2022 at 22:47 To: dev@cassandra.apache.org Subject: Re: How we flag tickets as blockers during freeze As you mentioned on slack, we can introduce FixVersions for the unreleased interim versions specified in the lifecycle wiki (https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle), so add the following specific unresolved placeholder FixVersions: 4.1-alpha 4.1-beta 4.1-rc Thus anything unresolved flagged 4.1-alpha would be a blocker for that, same for beta and rc. When the tickets are closed, we switch them to FixVersion 4.1; I don't see there being much value in knowing in the future if a ticket is fixed during the alpha, beta, or rc phases by using the above as resolved FixVersions. This approach potentially breaks down if we have any final blockers on 4.1 ga, but could just cycle through 4.1-rc until it's all clear. On Mon, May 9, 2022, at 5:07 PM, Mick Semb Wever wrote: Any other opinions or ideas out there? Would like to tidy our tickets up as build lead and scope out remaining work for 4.1. My request is that we don't overload fixVersions. That is, a fixVersion is either for resolved tickets, or a placeholder for unresolved, but never both. This makes it easier with jira hygiene post release, ensuring issues do get properly assigned their correct fixVersion. (This work can be many tickets and already quite cumbersome, but it is valued by users.) It would also be nice to try keep what is a placeholder fixVersion as intuitively as possible. The easiest way I see us doing this is to avoid using patch numbers. This rules out Option 1. While the use of 4.0 and 4.1 as resolved fixVersions kinda breaks the above notion of "if it doesn't have a patch version then it's a placeholder". The precedence here is that all resolved tickets before the first .0 of a major gets this short-hand version (and often in addition to the alpha1, beta1, rc1 fixVersions).
Re: How we flag tickets as blockers during freeze
As you mentioned on slack, we can introduce FixVersions for the unreleased interim versions specified in the lifecycle wiki (https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle), so add the following specific *unresolved placeholder FixVersions*: 4.1-alpha 4.1-beta 4.1-rc Thus anything unresolved flagged 4.1-alpha would be a blocker for that, same for beta and rc. When the tickets are closed, we switch them to FixVersion 4.1; I don't see there being much value in knowing in the future if a ticket is fixed during the alpha, beta, or rc phases by using the above as resolved FixVersions. This approach potentially breaks down if we have any final blockers on 4.1 ga, but could just cycle through 4.1-rc until it's all clear. On Mon, May 9, 2022, at 5:07 PM, Mick Semb Wever wrote: >> Any other opinions or ideas out there? Would like to tidy our tickets up as >> build lead and scope out remaining work for 4.1. > > > My request is that we don't overload fixVersions. That is, a fixVersion is > either for resolved tickets, or a placeholder for unresolved, but never both. > This makes it easier with jira hygiene post release, ensuring issues do get > properly assigned their correct fixVersion. (This work can be many tickets > and already quite cumbersome, but it is valued by users.) > > It would also be nice to try keep what is a placeholder fixVersion as > intuitively as possible. The easiest way I see us doing this is to avoid > using patch numbers. This rules out Option 1. > > While the use of 4.0 and 4.1 as resolved fixVersions kinda breaks the above > notion of "if it doesn't have a patch version then it's a placeholder". The > precedence here is that all resolved tickets before the first .0 of a major > gets this short-hand version (and often in addition to the alpha1, beta1, rc1 > fixVersions). > >
Re: How we flag tickets as blockers during freeze
I would vote for option 1. We have done similar in the past and if something is a blocker it means it will be in that version before it is released. So there should not be any confusion of things getting bumped forward to another patch number because they were not committed in time, which is where confusion usually arises from. > On May 9, 2022, at 4:07 PM, Mick Semb Wever wrote: > > >> Any other opinions or ideas out there? Would like to tidy our tickets up as >> build lead and scope out remaining work for 4.1. > > > My request is that we don't overload fixVersions. That is, a fixVersion is > either for resolved tickets, or a placeholder for unresolved, but never both. > This makes it easier with jira hygiene post release, ensuring issues do get > properly assigned their correct fixVersion. (This work can be many tickets > and already quite cumbersome, but it is valued by users.) > > It would also be nice to try keep what is a placeholder fixVersion as > intuitively as possible. The easiest way I see us doing this is to avoid > using patch numbers. This rules out Option 1. > > While the use of 4.0 and 4.1 as resolved fixVersions kinda breaks the above > notion of "if it doesn't have a patch version then it's a placeholder". The > precedence here is that all resolved tickets before the first .0 of a major > gets this short-hand version (and often in addition to the alpha1, beta1, rc1 > fixVersions). > > >
Re: How we flag tickets as blockers during freeze
> > Any other opinions or ideas out there? Would like to tidy our tickets up > as build lead and scope out remaining work for 4.1. > My request is that we don't overload fixVersions. That is, a fixVersion is either for resolved tickets, or a placeholder for unresolved, but never both. This makes it easier with jira hygiene post release, ensuring issues do get properly assigned their correct fixVersion. (This work can be many tickets and already quite cumbersome, but it is valued by users.) It would also be nice to try keep what is a placeholder fixVersion as intuitively as possible. The easiest way I see us doing this is to avoid using patch numbers. This rules out Option 1. While the use of 4.0 and 4.1 as resolved fixVersions kinda breaks the above notion of "if it doesn't have a patch version then it's a placeholder". The precedence here is that all resolved tickets before the first .0 of a major gets this short-hand version (and often in addition to the alpha1, beta1, rc1 fixVersions).
