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

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 >