I am doing the bulk closures. I already had some complaints about the email spam, and
there is a lot more to come. So, I will ask Jira not to send notifications for anything
from the first set at least ([3] below).
On 6 Dec 2017, at 13:52, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
Closing issues after the .Final release is done sounds fine to me. We leave them Resolved
until the .Final release is done because if something comes up and we need further work
it's more of a pain to deal with a closed issue. But once the .Final release is done,
I actually want it to be a pain to change the issue; e.g. reopening it because someone
wants something more is usually wrong.
10.x.x.TBD is the name of the "next release from the 10.x branch that we don't
have any real plan to ever do, but we have the 10.x branch anyway just in case so
here's a version to track activity on it" version. So things merged to 10.x since
the last release have that version.
Re: "No Release" that's sometimes used for things that aren't really in
the software or something versioned with the software and thus aren't in the release
per se. Some of the stuff in that query looks like that; others just look like mistakes.
On Wed, Dec 6, 2017 at 6:05 AM, Kabir Khan <kkhan(a)redhat.com> wrote:
> On 6 Dec 2017, at 11:36, Kabir Khan <kkhan(a)redhat.com> wrote:
>
> I have set up a Jirban board for WFLY, which can be found at [1] (log into
issues.jboss.org first). It effectively uses the following JQL:
>
> project = WFLY and status != Closed and issuetype = "Feature
Request" and (level is EMPTY and "Security Sensitive Issue" is EMPTY)
>
> As you can see, it currently displays only feature requests.
>
> However, if I organise this into swimlanes by fix version [2] it seems that there a
lot of issues in the Resolved state for old releases.
>
> I think these resolved issues should be closed. Firstly, I believe this is 'The
Jira Way'. Secondly, it keeps the Jirban cache of issues on the server as small as
possible, as the issues in the states configured to be 'done' in the Jirban config
(i.e. Closed) are not cached. Also, the list of Fix Versions in the Jirban filters is
populated from the issue data, so a nice side effect will be to keep that list more
manageable. At the moment there are too many versions in there to make much sense out of
it.
>
> [3] contains a query for all issues in released versions. Here ' 10.x.x TBD'
is a bit strange, but I assume these must have been released as part of something by now?
>
> Then we have a few with Fix Version 'Awaiting Volunteers': [4]
>
> There is a very mysterious Fix Version 'No Release': [5]
>
> Then we have many resolved issues with no fix version but which have been done [6]
>
> Finally we have a load of unresolved issues with no fix version which are rejected,
duplicates, out of date etc. [7]
>
> If my queries seem ok, I'd like to bulk close all of these. The ones from [4],
[5] and [6] need a bit of care, but hopefully the date they were resolved can help figure
out which release they went into. Or perhaps since they have been resolved with a strange
fix version for so long, it doesn't matter if they are closed against that version
either?
>
> Thanks,
>
> Kabir
>
>
>
> [1]
https://issues.jboss.org/jirban/index.html#/board?board=WFLY
[1] should have been
https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr
>
> [2]
https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr&bl=tr...
> [3]
https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%...
> [4]
https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%...
> [5]
https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%...
> [6]
https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%...
> [7]
https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%...
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat