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

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 >