[wildfly-dev] Jirban board for WFLY feature requests/Jira cleanup

[Brian Stansberry]

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 at redhat.com> wrote:

>
>
> > On 6 Dec 2017, at 11:36, Kabir Khan <kkhan at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171206/423a0acb/attachment.html