On 6 Dec 2017, at 11:36, Kabir Khan <kkhan(a)redhat.com&gt; 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

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

On 6 Dec 2017, at 13:52, Brian Stansberry <brian.stansberry(a)redhat.com&gt; 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&gt; wrote: > On 6 Dec 2017, at 11:36, Kabir Khan <kkhan(a)redhat.com&gt; 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

The cleanup has completed. For the issues in [6] I took some guesses. They were comparing the update date with the WF Final releases, so they might be slightly off in some cases, but I left comments and enabled spam for these. If I got something wrong, please reopen, adjust the fix version, and resolve and close again. Thanks, Kabir > On 6 Dec 2017, at 16:22, Kabir Khan <kkhan(a)redhat.com&gt; wrote: > > 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&gt; 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&gt; wrote: >> >> >>> On 6 Dec 2017, at 11:36, Kabir Khan <kkhan(a)redhat.com&gt; 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=true&swimlane=fix-version >>> [3] https://issues.jboss.org/issues/?jql=project%20%3D% 20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion% 20in%20(10.0.0.Alpha1%2C%20%2010.0.0.Alpha2%2C%20%2010.0. 0.Alpha3%2C%2010.0.0.Alpha4%2C%2010.0.0.Alpha5%2C%2010.0. 0.Alpha6%2C%2010.0.0.Beta1%2C%2010.0.0.Beta2%2C%2010.0.0. CR1%2C%2010.0.0.CR2%2C%20%2010.0.0.CR3%2C%20%2010.0.0. CR4%2C%2010.0.0.CR5%2C%2010.0.0.Final%2C%2010.1.0.CR1%2C% 2010.1.0.Final%2C%20%2710.x.x%20TBD%27%2C%20%2011.0.0. Alpha1%2C%20%2011.0.0.Beta1%2C%20%2011.0.0.CR1%2C%20%2011. 0.0.Final%2C%20%20%208.0.0.Alpha1%2C%20%208.0.0.Alpha2% 2C%20%208.0.0.Alpha3%2C%20%208.0.0.Alpha4%2C%20%208.0.0. Beta1%2C%208.0.0.CR1%2C%20%208.0.0.Final%2C%208.1.0.CR1% 2C%20%208.1.0.CR2%2C%20%208.1.0.Final%2C%20%208.2.0.Final% 2C%20%209.0.0.Alpha1%2C%20%209.0.0.Beta1%2C%20%209.0.0. Beta2%2C%20%209.0.0.CR1%2C%20%209.0.0.CR2%2C%20%209.0.0. Final%2C%20%209.0.1.Final%2C%20%20%27JBoss%20AS7%207.1.1.Final%27)%0A >>> [4] https://issues.jboss.org/issues/?jql=project%20%3D% 20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion% 20in%20(%22Awaiting%20Volunteers%22)%0A >>> [5] https://issues.jboss.org/issues/?jql=project%20%3D% 20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion% 20in%20(%22No%20Release%22)%0A >>> [6] https://issues.jboss.org/issues/?jql=project%20%3D% 20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion% 20is%20EMPTY%20and%20resolution%20in%20(Done%2C% 20%22Resolved%20at%20Apache%22) >>> [7] https://issues.jboss.org/issues/?jql=project%20%3D% 20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion% 20is%20EMPTY%20and%20resolution%20not%20in%20(Done%2C%20%22Resolved%20at% 20Apache%22) >> >> >> _______________________________________________ >> 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 >