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