On Thu, Jul 11, 2024 at 2:33 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > We've got a lot ofJIRAs with 'Critical' priority that have been inactive > for a long time. I think we should define 'Critical' as roughly "important > enough that we need to work on it soon." At some point if something goes > unaddressed long enough that's a sign that it's not important enough to be > called critical. > > I propose doing the following: for any Critical WFLY or WFCORE that was > opened > 12 months ago and hasn't shown signs of activity since the WF 32 > release, I'll leave a comment saying I plan to downgrade it to Major unless > the assignee says they plan to deal with it for the WF 34 cycle. And then a > couple weeks later downgrade issues. > > Similarly, for issues with Fix Version 33.0.0.Final that have been > rolling from release to release since WF 31 or earlier, when I release 33 I > intend to remove the Fix Version instead of rolling it to 34. > > WDYT? > > I do agree regarding the "Critical" ones. And about the issues rolling from release to release, I would say we should apply the same policy for WildFly Core issues too. Removing the fix version if the Jira is not resolved will help developers keep their intentions up to date.

Best regards, > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... > _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...

On Thu, Jul 11, 2024 at 2:40 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Thu, Jul 11, 2024 at 4:45 AM Yeray Borges Santana <yborgess(a)redhat.com&gt; > wrote: > >> >> On Thu, Jul 11, 2024 at 2:33 AM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> We've got a lot ofJIRAs with 'Critical' priority that have been >>> inactive for a long time. I think we should define 'Critical' as roughly >>> "important enough that we need to work on it soon." At some point if >>> something goes unaddressed long enough that's a sign that it's not >>> important enough to be called critical. >>> >>> I propose doing the following: for any Critical WFLY or WFCORE that was >>> opened > 12 months ago and hasn't shown signs of activity since the WF 32 >>> release, I'll leave a comment saying I plan to downgrade it to Major unless >>> the assignee says they plan to deal with it for the WF 34 cycle. And then a >>> couple weeks later downgrade issues. >>> >>> Similarly, for issues with Fix Version 33.0.0.Final that have been >>> rolling from release to release since WF 31 or earlier, when I release 33 I >>> intend to remove the Fix Version instead of rolling it to 34. >>> >> >>> WDYT? >>> >>> >> I do agree regarding the "Critical" ones. >> >> And about the issues rolling from release to release, I would say we >> should apply the same policy for WildFly Core issues too. >> Removing the fix version if the Jira is not resolved will help >> developers keep their intentions up to date. >> > > I was thinking to give a bit of grace there, but this morning my initial > reference to WF 31 seems like too much. Perhaps letting it roll one time is > enough, so something scheduled for 33 can roll to 34, but if it was > originally for 32 or earlier, unschedule it. > > That sounds good to me, although checking the original schedule on an already rolled Jira will require checking non-resolved Jiras one by one to verify what was its original schedule. Well, maybe there won't be too many Jiras, or it might be a simple task to do or even can be done automatically. Otherwise, I would still consider letting the developer review its intention on each new release.

>> Best regards, >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>> >> _______________________________________________ >> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >> List Archives: >> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >> > > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His > _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...

On Fri, Jul 12, 2024 at 6:14 AM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > > > On Fri, Jul 12, 2024 at 11:51 AM Yeray Borges Santana < > yborgess(a)redhat.com&gt; wrote: > >> >> >> On Thu, Jul 11, 2024 at 2:40 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Thu, Jul 11, 2024 at 4:45 AM Yeray Borges Santana < >>> yborgess(a)redhat.com&gt; wrote: >>> >>>> >>>> On Thu, Jul 11, 2024 at 2:33 AM Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> We've got a lot ofJIRAs with 'Critical' priority that have been >>>>> inactive for a long time. I think we should define 'Critical' as roughly >>>>> "important enough that we need to work on it soon." At some point if >>>>> something goes unaddressed long enough that's a sign that it's not >>>>> important enough to be called critical. >>>>> >>>>> I propose doing the following: for any Critical WFLY or WFCORE that >>>>> was opened > 12 months ago and hasn't shown signs of activity since the WF >>>>> 32 release, I'll leave a comment saying I plan to downgrade it to Major >>>>> unless the assignee says they plan to deal with it for the WF 34 cycle. And >>>>> then a couple weeks later downgrade issues. >>>>> >>>>> Similarly, for issues with Fix Version 33.0.0.Final that have been >>>>> rolling from release to release since WF 31 or earlier, when I release 33 I >>>>> intend to remove the Fix Version instead of rolling it to 34. >>>>> >>>> >>>>> WDYT? >>>>> >>>>> >>>> I do agree regarding the "Critical" ones. >>>> >>>> And about the issues rolling from release to release, I would say we >>>> should apply the same policy for WildFly Core issues too. >>>> Removing the fix version if the Jira is not resolved will help >>>> developers keep their intentions up to date. >>>> >>> >>> I was thinking to give a bit of grace there, but this morning my >>> initial reference to WF 31 seems like too much. Perhaps letting it roll one >>> time is enough, so something scheduled for 33 can roll to 34, but if it was >>> originally for 32 or earlier, unschedule it. >>> >>> >> That sounds good to me, although checking the original schedule >> on an already rolled Jira will require checking non-resolved Jiras one by >> one to verify what was its original schedule. Well, maybe there won't be >> too many Jiras, or it might be a simple task to do or even can be done >> automatically. Otherwise, I would still consider letting the developer >> review its intention on each new release. >> > > If the fix versions were created in Jira before the Beta release, maybe > between Beta and Final we could ask developers to move issues forward if > they were still needed and then just unschedule the rest. > For full WF my preference is just to look at them and unschedule or roll forward as part of my normal release work. I look at them already as part of scanning for work that needs to get done before the release, so doing that is easiest for me. I don't want to have to do round trip discussions. Yeray, you're the one who does WF Core releases, so I think what works best for you is fine.

> >> >> >>>> Best regards, >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Architect, Red Hat JBoss EAP >>>>> WildFly Project Lead >>>>> He/Him/His >>>>> _______________________________________________ >>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>> List Archives: >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>> List Archives: >>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> >> _______________________________________________ >> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >> List Archives: >> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >> > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His

On Mon, Jul 15, 2024 at 3:01 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Fri, Jul 12, 2024 at 6:14 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> >> >> On Fri, Jul 12, 2024 at 11:51 AM Yeray Borges Santana < >> yborgess(a)redhat.com&gt; wrote: >> >>> >>> >>> On Thu, Jul 11, 2024 at 2:40 PM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> >>>> >>>> On Thu, Jul 11, 2024 at 4:45 AM Yeray Borges Santana < >>>> yborgess(a)redhat.com&gt; wrote: >>>> >>>>> >>>>> On Thu, Jul 11, 2024 at 2:33 AM Brian Stansberry < >>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> We've got a lot ofJIRAs with 'Critical' priority that have been >>>>>> inactive for a long time. I think we should define 'Critical' as roughly >>>>>> "important enough that we need to work on it soon." At some point if >>>>>> something goes unaddressed long enough that's a sign that it's not >>>>>> important enough to be called critical. >>>>>> >>>>>> I propose doing the following: for any Critical WFLY or WFCORE that >>>>>> was opened > 12 months ago and hasn't shown signs of activity since the WF >>>>>> 32 release, I'll leave a comment saying I plan to downgrade it to Major >>>>>> unless the assignee says they plan to deal with it for the WF 34 cycle. And >>>>>> then a couple weeks later downgrade issues. >>>>>> >>>>>> Similarly, for issues with Fix Version 33.0.0.Final that have been >>>>>> rolling from release to release since WF 31 or earlier, when I release 33 I >>>>>> intend to remove the Fix Version instead of rolling it to 34. >>>>>> >>>>> >>>>>> WDYT? >>>>>> >>>>>> >>>>> I do agree regarding the "Critical" ones. >>>>> >>>>> And about the issues rolling from release to release, I would say we >>>>> should apply the same policy for WildFly Core issues too. >>>>> Removing the fix version if the Jira is not resolved will help >>>>> developers keep their intentions up to date. >>>>> >>>> >>>> I was thinking to give a bit of grace there, but this morning my >>>> initial reference to WF 31 seems like too much. Perhaps letting it roll one >>>> time is enough, so something scheduled for 33 can roll to 34, but if it was >>>> originally for 32 or earlier, unschedule it. >>>> >>>> >>> That sounds good to me, although checking the original schedule >>> on an already rolled Jira will require checking non-resolved Jiras one by >>> one to verify what was its original schedule. Well, maybe there won't be >>> too many Jiras, or it might be a simple task to do or even can be done >>> automatically. Otherwise, I would still consider letting the developer >>> review its intention on each new release. >>> >> >> If the fix versions were created in Jira before the Beta release, maybe >> between Beta and Final we could ask developers to move issues forward if >> they were still needed and then just unschedule the rest. >> > > For full WF my preference is just to look at them and unschedule or roll > forward as part of my normal release work. I look at them already as part > of scanning for work that needs to get done before the release, so doing > that is easiest for me. I don't want to have to do round trip discussions. > I was thinking of more of a one time notification so as I release Beta I ask current assignees to review their open issues. More of a move it or lose it approach ;-) They can also always be added back manually.

> > Yeray, you're the one who does WF Core releases, so I think what works > best for you is fine. > > >> >>> >>> >>>>> Best regards, >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Principal Architect, Red Hat JBoss EAP >>>>>> WildFly Project Lead >>>>>> He/Him/His >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>> List Archives: >>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>> List Archives: >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>> >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Principal Architect, Red Hat JBoss EAP >>>> WildFly Project Lead >>>> He/Him/His >>>> >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>> >> > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His >

On Tue, Jul 16, 2024 at 11:38 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Tue, Jul 16, 2024 at 5:20 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> >> On Mon, Jul 15, 2024 at 3:01 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Fri, Jul 12, 2024 at 6:14 AM Darran Lofthouse < >>> darran.lofthouse(a)jboss.com&gt; wrote: >>> >>>> >>>> >>>> On Fri, Jul 12, 2024 at 11:51 AM Yeray Borges Santana < >>>> yborgess(a)redhat.com&gt; wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jul 11, 2024 at 2:40 PM Brian Stansberry < >>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 11, 2024 at 4:45 AM Yeray Borges Santana < >>>>>> yborgess(a)redhat.com&gt; wrote: >>>>>> >>>>>>> >>>>>>> On Thu, Jul 11, 2024 at 2:33 AM Brian Stansberry < >>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> We've got a lot ofJIRAs with 'Critical' priority that have been >>>>>>>> inactive for a long time. I think we should define 'Critical' as roughly >>>>>>>> "important enough that we need to work on it soon." At some point if >>>>>>>> something goes unaddressed long enough that's a sign that it's not >>>>>>>> important enough to be called critical. >>>>>>>> >>>>>>>> I propose doing the following: for any Critical WFLY or WFCORE >>>>>>>> that was opened > 12 months ago and hasn't shown signs of activity since >>>>>>>> the WF 32 release, I'll leave a comment saying I plan to downgrade it to >>>>>>>> Major unless the assignee says they plan to deal with it for the WF 34 >>>>>>>> cycle. And then a couple weeks later downgrade issues. >>>>>>>> >>>>>>>> Similarly, for issues with Fix Version 33.0.0.Final that have been >>>>>>>> rolling from release to release since WF 31 or earlier, when I release 33 I >>>>>>>> intend to remove the Fix Version instead of rolling it to 34. >>>>>>>> >>>>>>> >>>>>>>> WDYT? >>>>>>>> >>>>>>>> >>>>>>> I do agree regarding the "Critical" ones. >>>>>>> >>>>>>> And about the issues rolling from release to release, I would say >>>>>>> we should apply the same policy for WildFly Core issues too. >>>>>>> Removing the fix version if the Jira is not resolved will help >>>>>>> developers keep their intentions up to date. >>>>>>> >>>>>> >>>>>> I was thinking to give a bit of grace there, but this morning my >>>>>> initial reference to WF 31 seems like too much. Perhaps letting it roll one >>>>>> time is enough, so something scheduled for 33 can roll to 34, but if it was >>>>>> originally for 32 or earlier, unschedule it. >>>>>> >>>>>> >>>>> That sounds good to me, although checking the original schedule >>>>> on an already rolled Jira will require checking non-resolved Jiras one by >>>>> one to verify what was its original schedule. Well, maybe there won't be >>>>> too many Jiras, or it might be a simple task to do or even can be done >>>>> automatically. Otherwise, I would still consider letting the developer >>>>> review its intention on each new release. >>>>> >>>> >>>> If the fix versions were created in Jira before the Beta release, >>>> maybe between Beta and Final we could ask developers to move issues forward >>>> if they were still needed and then just unschedule the rest. >>>> >>> >>> For full WF my preference is just to look at them and unschedule or >>> roll forward as part of my normal release work. I look at them already as >>> part of scanning for work that needs to get done before the release, so >>> doing that is easiest for me. I don't want to have to do round trip >>> discussions. >>> >> >> I was thinking of more of a one time notification so as I release Beta I >> ask current assignees to review their open issues. More of a move it or >> lose it approach ;-) They can also always be added back manually. >> > > Ok, we can come up with wording and try that with 34. I'll do it manually > for 33. > We could start softly got 34 and I will just send out a notification encouraging a clean up of current scheduled issues, seems like a good practice anyway to encourage at release time.

> > I think the initial cleanup will mostly take care of the problem. > > >> >>> >>> Yeray, you're the one who does WF Core releases, so I think what works >>> best for you is fine. >>> >>> >>>> >>>>> >>>>> >>>>>>> Best regards, >>>>>>>> >>>>>>>> -- >>>>>>>> Brian Stansberry >>>>>>>> Principal Architect, Red Hat JBoss EAP >>>>>>>> WildFly Project Lead >>>>>>>> He/Him/His >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>>>> List Archives: >>>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>>> List Archives: >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Principal Architect, Red Hat JBoss EAP >>>>>> WildFly Project Lead >>>>>> He/Him/His >>>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>> List Archives: >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>> >>>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> >> > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His >

On Wed, Jul 17, 2024 at 3:51 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Wed, Jul 17, 2024 at 3:03 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> On Tue, Jul 16, 2024 at 11:38 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Tue, Jul 16, 2024 at 5:20 AM Darran Lofthouse < >>> darran.lofthouse(a)jboss.com&gt; wrote: >>> >>>> >>>> On Mon, Jul 15, 2024 at 3:01 PM Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> >>>>> >>>>> On Fri, Jul 12, 2024 at 6:14 AM Darran Lofthouse < >>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Jul 12, 2024 at 11:51 AM Yeray Borges Santana < >>>>>> yborgess(a)redhat.com&gt; wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 11, 2024 at 2:40 PM Brian Stansberry < >>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 11, 2024 at 4:45 AM Yeray Borges Santana < >>>>>>>> yborgess(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jul 11, 2024 at 2:33 AM Brian Stansberry < >>>>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> We've got a lot ofJIRAs with 'Critical' priority that have been >>>>>>>>>> inactive for a long time. I think we should define 'Critical' as roughly >>>>>>>>>> "important enough that we need to work on it soon." At some point if >>>>>>>>>> something goes unaddressed long enough that's a sign that it's not >>>>>>>>>> important enough to be called critical. >>>>>>>>>> >>>>>>>>>> I propose doing the following: for any Critical WFLY or WFCORE >>>>>>>>>> that was opened > 12 months ago and hasn't shown signs of activity since >>>>>>>>>> the WF 32 release, I'll leave a comment saying I plan to downgrade it to >>>>>>>>>> Major unless the assignee says they plan to deal with it for the WF 34 >>>>>>>>>> cycle. And then a couple weeks later downgrade issues. >>>>>>>>>> >>>>>>>>>> Similarly, for issues with Fix Version 33.0.0.Final that have >>>>>>>>>> been rolling from release to release since WF 31 or earlier, when I release >>>>>>>>>> 33 I intend to remove the Fix Version instead of rolling it to 34. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> WDYT? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I do agree regarding the "Critical" ones. >>>>>>>>> >>>>>>>> For this part, I just added the following comment to 20 WFLY issues: "This issue has been open for over a year and remains unaddressed. 'Critical' priority should be used for things we intend we intend to focus on in a relatively short period, so the fact it is unaddressed for a year is an indication the WildFly developer community doesn't see it as truly critical. If the assignee or a relevant component lead believes this issue should continue to have Critical priority, please reply by July 31, 2024 with a comment indicating when this issue is expected to be addressed. Absent that I will downgrade the issue to Major." I also added a 'downgrade-candidate' label, which is just to help me find these issues again for follow-up in August.

>>>>>>>>> And about the issues rolling from release to release, I would say >>>>>>>>> we should apply the same policy for WildFly Core issues too. >>>>>>>>> Removing the fix version if the Jira is not resolved will help >>>>>>>>> developers keep their intentions up to date. >>>>>>>>> >>>>>>>> >>>>>>>> I was thinking to give a bit of grace there, but this morning my >>>>>>>> initial reference to WF 31 seems like too much. Perhaps letting it roll one >>>>>>>> time is enough, so something scheduled for 33 can roll to 34, but if it was >>>>>>>> originally for 32 or earlier, unschedule it. >>>>>>>> >>>>>>>> >>>>>>> That sounds good to me, although checking the original schedule >>>>>>> on an already rolled Jira will require checking non-resolved Jiras one by >>>>>>> one to verify what was its original schedule. Well, maybe there won't be >>>>>>> too many Jiras, or it might be a simple task to do or even can be done >>>>>>> automatically. Otherwise, I would still consider letting the developer >>>>>>> review its intention on each new release. >>>>>>> >>>>>> >>>>>> If the fix versions were created in Jira before the Beta release, >>>>>> maybe between Beta and Final we could ask developers to move issues forward >>>>>> if they were still needed and then just unschedule the rest. >>>>>> >>>>> >>>>> For full WF my preference is just to look at them and unschedule or >>>>> roll forward as part of my normal release work. I look at them already as >>>>> part of scanning for work that needs to get done before the release, so >>>>> doing that is easiest for me. I don't want to have to do round trip >>>>> discussions. >>>>> >>>> >>>> I was thinking of more of a one time notification so as I release Beta >>>> I ask current assignees to review their open issues. More of a move it or >>>> lose it approach ;-) They can also always be added back manually. >>>> >>> >>> Ok, we can come up with wording and try that with 34. I'll do it >>> manually for 33. >>> >> >> We could start softly got 34 and I will just send out a notification >> encouraging a clean up of current scheduled issues, seems like a good >> practice anyway to encourage at release time. >> > > I dropped the Fix Version from about a dozen issues. I rolled forward a > couple dozen where there was either a PR or I had a strong reason to > believe work would happen for 34 -- e.g. Paul had a bunch of pretty new > ones that are similar to things he's been cranking through in the last > month. > > >> >>> >>> I think the initial cleanup will mostly take care of the problem. >>> >>> >>>> >>>>> >>>>> Yeray, you're the one who does WF Core releases, so I think what >>>>> works best for you is fine. >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Brian Stansberry >>>>>>>>>> Principal Architect, Red Hat JBoss EAP >>>>>>>>>> WildFly Project Lead >>>>>>>>>> He/Him/His >>>>>>>>>> _______________________________________________ >>>>>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>>>>> To unsubscribe send an email to >>>>>>>>>> wildfly-dev-leave(a)lists.jboss.org >>>>>>>>>> Privacy Statement: >>>>>>>>>> https://www.redhat.com/en/about/privacy-policy >>>>>>>>>> List Archives: >>>>>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>>>>> List Archives: >>>>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Brian Stansberry >>>>>>>> Principal Architect, Red Hat JBoss EAP >>>>>>>> WildFly Project Lead >>>>>>>> He/Him/His >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>>> List Archives: >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Architect, Red Hat JBoss EAP >>>>> WildFly Project Lead >>>>> He/Him/His >>>>> >>>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> >> > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His