On Thu, Jul 11, 2024 at 2:40 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
On Thu, Jul 11, 2024 at 4:45 AM Yeray Borges Santana <yborgess(a)redhat.com>
wrote:
>
> On Thu, Jul 11, 2024 at 2:33 AM Brian Stansberry <
> brian.stansberry(a)redhat.com> 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.
> 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