[wildfly-dev] Re: 'Critical' JIRA cleanup

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