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

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. >>>>>>>> >>>>>>>

>>>>>>>> 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