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

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.

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