Fix version should be set on resolution

[Wilfred Spiegelenburg <wi...@apache.org>]

Hi all,

There are multiple fields that can be set with versions in jira. Two are
used in YuniKorn:
* Fix version/s
* Target Version

The Target Version is not shown by default on the pages but should be used
to mark a jira to be targeted for a specific release. Currently that is
0.11. The description of the Target Version field is given as:
The versions where this patch is intended to be committed. Use "Fix
Version" to note where it actually has been committed.

That is exactly what I was taught when I started using bug tracking
systems. The Fix Version/s is set when the jira is resolved or closed and
the code is committed and the issue is fixed in that version.

We had 29 jiras that are open marked with a fix version of 0.11. I have
moved them to a target version. Please do not set a fix version if the code
has not been committed, use the target version field.
There are two public searches available that can be used to check what is
going on for the current release:
target for next release:
https://issues.apache.org/jira/issues/?filter=12348416
fixed in next release:
https://issues.apache.org/jira/issues/?filter=12350521

These two searches are shown as the project shortcuts for anyone to access.

Wilfred

Re: Fix version should be set on resolution

[Weiwei Yang <ww...@apache.org>]

We should follow the guidelines from JIRA, so we can leverage the tool to
do more proper project management.
I strongly suggest using the Fix version and the page:
https://issues.apache.org/jira/projects/YUNIKORN/versions/12350025 to
monitor our release progress.
Please find more info from JIRA documentation:
https://www.atlassian.com/agile/tutorials/versions.

On Thu, May 13, 2021 at 9:28 AM Julia Kinga Marton
<km...@cloudera.com.invalid> wrote:

> Hi,
>
> Do we have any conclusion on this topic?
> For me it is more logical to use the Target version for marking an issue
> for a release and set the Fix version only when we resolve the issue.
> However I can live with using only the Fix version, but we should make it
> clear and update the Jiras accordingly.
>
> Regards,
> Kinga
>
>
> On Thu, Apr 29, 2021 at 3:13 AM Weiwei Yang <ww...@apache.org> wrote:
>
> > >
> > > How do you know if it is the version for planning or if that has been
> > > really
> > > fixed already?
> > >
> >
> > That is JIRA Status + Fix version. If an issue is fixed and the Fix
> Version
> > is 0.10, then this issue is fixed in 0.10.
> >
> > If you have a bug that needs to be backported to a previous
> > > release or forward ported to the master the jira is left open. The
> > release
> > > info in jira will show that it has not been fixed yet while it is for
> > that
> > > release.
> > >
> >
> > Not quite sure about this case. IMO, if a PR is committed, we need to
> close
> > the JIRA with a proper Fix Version set.
> > If the PR has been ported to more than one version, we set the Fix
> Version
> > accordingly to several versions.
> > I am not sure why we would keep the JIRA open when we have the PR
> committed
> > already.
> >
> >
> > On Wed, Apr 28, 2021 at 5:56 PM Wilfred Spiegelenburg <
> wilfreds@apache.org
> > >
> > wrote:
> >
> > > The problem with using one field for planning and showing where it is
> > > committed is that you get into trouble when you have multiple releases.
> > How
> > > do you know if it is the version for planning or if that has been
> really
> > > fixed already? If you have a bug that needs to be backported to a
> > previous
> > > release or forward ported to the master the jira is left open. The
> > release
> > > info in jira will show that it has not been fixed yet while it is for
> > that
> > > release.
> > >
> > > The release tool is not designed to be used with multiple releases in
> > mind.
> > >
> > > Wilfred
> > >
> > > On Thu, 29 Apr 2021 at 04:26, Weiwei Yang <ww...@apache.org> wrote:
> > >
> > > > Hi Wilfred
> > > >
> > > > If you look at the JIRA document:
> > > > https://www.atlassian.com/agile/tutorials/versions.
> > > >
> > > > *Fix version* is the version where you plan on releasing a feature or
> > > > bugfix to customers. This field is used for release planning,
> > monitoring
> > > > progress and velocity, and is used widely in reporting. This is most
> > > likely
> > > > the field you want.
> > > >
> > > > You can also find a similar discussion here:
> > > >
> > >
> >
> https://stackoverflow.com/questions/37874420/use-target-version-for-release-planning-in-jira
> > > > .
> > > > If we follow this instruction, we can nicely track the release plan
> and
> > > > activities here. But if we do not set the Fix Version, you see the
> > > > In-progress and Issues-todo are both empty.
> > > >
> > > > [image: YUNIKORN__0_11_-_ASF_JIRA.png]
> > > >
> > > > Instead of creating customized filters, we should rely on the JIRA
> > > > *release* tool to plan and track our releases.
> > > >
> > > > On Wed, Apr 28, 2021 at 1:06 AM Wilfred Spiegelenburg <
> > > wilfreds@apache.org>
> > > > wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> There are multiple fields that can be set with versions in jira. Two
> > are
> > > >> used in YuniKorn:
> > > >> * Fix version/s
> > > >> * Target Version
> > > >>
> > > >> The Target Version is not shown by default on the pages but should
> be
> > > used
> > > >> to mark a jira to be targeted for a specific release. Currently that
> > is
> > > >> 0.11. The description of the Target Version field is given as:
> > > >> The versions where this patch is intended to be committed. Use "Fix
> > > >> Version" to note where it actually has been committed.
> > > >>
> > > >> That is exactly what I was taught when I started using bug tracking
> > > >> systems. The Fix Version/s is set when the jira is resolved or
> closed
> > > and
> > > >> the code is committed and the issue is fixed in that version.
> > > >>
> > > >> We had 29 jiras that are open marked with a fix version of 0.11. I
> > have
> > > >> moved them to a target version. Please do not set a fix version if
> the
> > > >> code
> > > >> has not been committed, use the target version field.
> > > >> There are two public searches available that can be used to check
> what
> > > is
> > > >> going on for the current release:
> > > >> target for next release:
> > > >> https://issues.apache.org/jira/issues/?filter=12348416
> > > >> fixed in next release:
> > > >> https://issues.apache.org/jira/issues/?filter=12350521
> > > >>
> > > >> These two searches are shown as the project shortcuts for anyone to
> > > >> access.
> > > >>
> > > >> Wilfred
> > > >>
> > > >
> > >
> >
>

Re: Fix version should be set on resolution

[Julia Kinga Marton <km...@cloudera.com.INVALID>]

Hi,

Do we have any conclusion on this topic?
For me it is more logical to use the Target version for marking an issue
for a release and set the Fix version only when we resolve the issue.
However I can live with using only the Fix version, but we should make it
clear and update the Jiras accordingly.

Regards,
Kinga


On Thu, Apr 29, 2021 at 3:13 AM Weiwei Yang <ww...@apache.org> wrote:

> >
> > How do you know if it is the version for planning or if that has been
> > really
> > fixed already?
> >
>
> That is JIRA Status + Fix version. If an issue is fixed and the Fix Version
> is 0.10, then this issue is fixed in 0.10.
>
> If you have a bug that needs to be backported to a previous
> > release or forward ported to the master the jira is left open. The
> release
> > info in jira will show that it has not been fixed yet while it is for
> that
> > release.
> >
>
> Not quite sure about this case. IMO, if a PR is committed, we need to close
> the JIRA with a proper Fix Version set.
> If the PR has been ported to more than one version, we set the Fix Version
> accordingly to several versions.
> I am not sure why we would keep the JIRA open when we have the PR committed
> already.
>
>
> On Wed, Apr 28, 2021 at 5:56 PM Wilfred Spiegelenburg <wilfreds@apache.org
> >
> wrote:
>
> > The problem with using one field for planning and showing where it is
> > committed is that you get into trouble when you have multiple releases.
> How
> > do you know if it is the version for planning or if that has been really
> > fixed already? If you have a bug that needs to be backported to a
> previous
> > release or forward ported to the master the jira is left open. The
> release
> > info in jira will show that it has not been fixed yet while it is for
> that
> > release.
> >
> > The release tool is not designed to be used with multiple releases in
> mind.
> >
> > Wilfred
> >
> > On Thu, 29 Apr 2021 at 04:26, Weiwei Yang <ww...@apache.org> wrote:
> >
> > > Hi Wilfred
> > >
> > > If you look at the JIRA document:
> > > https://www.atlassian.com/agile/tutorials/versions.
> > >
> > > *Fix version* is the version where you plan on releasing a feature or
> > > bugfix to customers. This field is used for release planning,
> monitoring
> > > progress and velocity, and is used widely in reporting. This is most
> > likely
> > > the field you want.
> > >
> > > You can also find a similar discussion here:
> > >
> >
> https://stackoverflow.com/questions/37874420/use-target-version-for-release-planning-in-jira
> > > .
> > > If we follow this instruction, we can nicely track the release plan and
> > > activities here. But if we do not set the Fix Version, you see the
> > > In-progress and Issues-todo are both empty.
> > >
> > > [image: YUNIKORN__0_11_-_ASF_JIRA.png]
> > >
> > > Instead of creating customized filters, we should rely on the JIRA
> > > *release* tool to plan and track our releases.
> > >
> > > On Wed, Apr 28, 2021 at 1:06 AM Wilfred Spiegelenburg <
> > wilfreds@apache.org>
> > > wrote:
> > >
> > >> Hi all,
> > >>
> > >> There are multiple fields that can be set with versions in jira. Two
> are
> > >> used in YuniKorn:
> > >> * Fix version/s
> > >> * Target Version
> > >>
> > >> The Target Version is not shown by default on the pages but should be
> > used
> > >> to mark a jira to be targeted for a specific release. Currently that
> is
> > >> 0.11. The description of the Target Version field is given as:
> > >> The versions where this patch is intended to be committed. Use "Fix
> > >> Version" to note where it actually has been committed.
> > >>
> > >> That is exactly what I was taught when I started using bug tracking
> > >> systems. The Fix Version/s is set when the jira is resolved or closed
> > and
> > >> the code is committed and the issue is fixed in that version.
> > >>
> > >> We had 29 jiras that are open marked with a fix version of 0.11. I
> have
> > >> moved them to a target version. Please do not set a fix version if the
> > >> code
> > >> has not been committed, use the target version field.
> > >> There are two public searches available that can be used to check what
> > is
> > >> going on for the current release:
> > >> target for next release:
> > >> https://issues.apache.org/jira/issues/?filter=12348416
> > >> fixed in next release:
> > >> https://issues.apache.org/jira/issues/?filter=12350521
> > >>
> > >> These two searches are shown as the project shortcuts for anyone to
> > >> access.
> > >>
> > >> Wilfred
> > >>
> > >
> >
>

Re: Fix version should be set on resolution

[Weiwei Yang <ww...@apache.org>]

>
> How do you know if it is the version for planning or if that has been
> really
> fixed already?
>

That is JIRA Status + Fix version. If an issue is fixed and the Fix Version
is 0.10, then this issue is fixed in 0.10.

If you have a bug that needs to be backported to a previous
> release or forward ported to the master the jira is left open. The release
> info in jira will show that it has not been fixed yet while it is for that
> release.
>

Not quite sure about this case. IMO, if a PR is committed, we need to close
the JIRA with a proper Fix Version set.
If the PR has been ported to more than one version, we set the Fix Version
accordingly to several versions.
I am not sure why we would keep the JIRA open when we have the PR committed
already.


On Wed, Apr 28, 2021 at 5:56 PM Wilfred Spiegelenburg <wi...@apache.org>
wrote:

> The problem with using one field for planning and showing where it is
> committed is that you get into trouble when you have multiple releases. How
> do you know if it is the version for planning or if that has been really
> fixed already? If you have a bug that needs to be backported to a previous
> release or forward ported to the master the jira is left open. The release
> info in jira will show that it has not been fixed yet while it is for that
> release.
>
> The release tool is not designed to be used with multiple releases in mind.
>
> Wilfred
>
> On Thu, 29 Apr 2021 at 04:26, Weiwei Yang <ww...@apache.org> wrote:
>
> > Hi Wilfred
> >
> > If you look at the JIRA document:
> > https://www.atlassian.com/agile/tutorials/versions.
> >
> > *Fix version* is the version where you plan on releasing a feature or
> > bugfix to customers. This field is used for release planning, monitoring
> > progress and velocity, and is used widely in reporting. This is most
> likely
> > the field you want.
> >
> > You can also find a similar discussion here:
> >
> https://stackoverflow.com/questions/37874420/use-target-version-for-release-planning-in-jira
> > .
> > If we follow this instruction, we can nicely track the release plan and
> > activities here. But if we do not set the Fix Version, you see the
> > In-progress and Issues-todo are both empty.
> >
> > [image: YUNIKORN__0_11_-_ASF_JIRA.png]
> >
> > Instead of creating customized filters, we should rely on the JIRA
> > *release* tool to plan and track our releases.
> >
> > On Wed, Apr 28, 2021 at 1:06 AM Wilfred Spiegelenburg <
> wilfreds@apache.org>
> > wrote:
> >
> >> Hi all,
> >>
> >> There are multiple fields that can be set with versions in jira. Two are
> >> used in YuniKorn:
> >> * Fix version/s
> >> * Target Version
> >>
> >> The Target Version is not shown by default on the pages but should be
> used
> >> to mark a jira to be targeted for a specific release. Currently that is
> >> 0.11. The description of the Target Version field is given as:
> >> The versions where this patch is intended to be committed. Use "Fix
> >> Version" to note where it actually has been committed.
> >>
> >> That is exactly what I was taught when I started using bug tracking
> >> systems. The Fix Version/s is set when the jira is resolved or closed
> and
> >> the code is committed and the issue is fixed in that version.
> >>
> >> We had 29 jiras that are open marked with a fix version of 0.11. I have
> >> moved them to a target version. Please do not set a fix version if the
> >> code
> >> has not been committed, use the target version field.
> >> There are two public searches available that can be used to check what
> is
> >> going on for the current release:
> >> target for next release:
> >> https://issues.apache.org/jira/issues/?filter=12348416
> >> fixed in next release:
> >> https://issues.apache.org/jira/issues/?filter=12350521
> >>
> >> These two searches are shown as the project shortcuts for anyone to
> >> access.
> >>
> >> Wilfred
> >>
> >
>

Re: Fix version should be set on resolution

[Wilfred Spiegelenburg <wi...@apache.org>]

The problem with using one field for planning and showing where it is
committed is that you get into trouble when you have multiple releases. How
do you know if it is the version for planning or if that has been really
fixed already? If you have a bug that needs to be backported to a previous
release or forward ported to the master the jira is left open. The release
info in jira will show that it has not been fixed yet while it is for that
release.

The release tool is not designed to be used with multiple releases in mind.

Wilfred

On Thu, 29 Apr 2021 at 04:26, Weiwei Yang <ww...@apache.org> wrote:

> Hi Wilfred
>
> If you look at the JIRA document:
> https://www.atlassian.com/agile/tutorials/versions.
>
> *Fix version* is the version where you plan on releasing a feature or
> bugfix to customers. This field is used for release planning, monitoring
> progress and velocity, and is used widely in reporting. This is most likely
> the field you want.
>
> You can also find a similar discussion here:
> https://stackoverflow.com/questions/37874420/use-target-version-for-release-planning-in-jira
> .
> If we follow this instruction, we can nicely track the release plan and
> activities here. But if we do not set the Fix Version, you see the
> In-progress and Issues-todo are both empty.
>
> [image: YUNIKORN__0_11_-_ASF_JIRA.png]
>
> Instead of creating customized filters, we should rely on the JIRA
> *release* tool to plan and track our releases.
>
> On Wed, Apr 28, 2021 at 1:06 AM Wilfred Spiegelenburg <wi...@apache.org>
> wrote:
>
>> Hi all,
>>
>> There are multiple fields that can be set with versions in jira. Two are
>> used in YuniKorn:
>> * Fix version/s
>> * Target Version
>>
>> The Target Version is not shown by default on the pages but should be used
>> to mark a jira to be targeted for a specific release. Currently that is
>> 0.11. The description of the Target Version field is given as:
>> The versions where this patch is intended to be committed. Use "Fix
>> Version" to note where it actually has been committed.
>>
>> That is exactly what I was taught when I started using bug tracking
>> systems. The Fix Version/s is set when the jira is resolved or closed and
>> the code is committed and the issue is fixed in that version.
>>
>> We had 29 jiras that are open marked with a fix version of 0.11. I have
>> moved them to a target version. Please do not set a fix version if the
>> code
>> has not been committed, use the target version field.
>> There are two public searches available that can be used to check what is
>> going on for the current release:
>> target for next release:
>> https://issues.apache.org/jira/issues/?filter=12348416
>> fixed in next release:
>> https://issues.apache.org/jira/issues/?filter=12350521
>>
>> These two searches are shown as the project shortcuts for anyone to
>> access.
>>
>> Wilfred
>>
>

Re: Fix version should be set on resolution

[Weiwei Yang <ww...@apache.org>]

Hi Wilfred

If you look at the JIRA document:
https://www.atlassian.com/agile/tutorials/versions.

*Fix version* is the version where you plan on releasing a feature or
bugfix to customers. This field is used for release planning, monitoring
progress and velocity, and is used widely in reporting. This is most likely
the field you want.

You can also find a similar discussion here:
https://stackoverflow.com/questions/37874420/use-target-version-for-release-planning-in-jira
.
If we follow this instruction, we can nicely track the release plan and
activities here. But if we do not set the Fix Version, you see the
In-progress and Issues-todo are both empty.

[image: YUNIKORN__0_11_-_ASF_JIRA.png]

Instead of creating customized filters, we should rely on the JIRA *release*
tool to plan and track our releases.

On Wed, Apr 28, 2021 at 1:06 AM Wilfred Spiegelenburg <wi...@apache.org>
wrote:

> Hi all,
>
> There are multiple fields that can be set with versions in jira. Two are
> used in YuniKorn:
> * Fix version/s
> * Target Version
>
> The Target Version is not shown by default on the pages but should be used
> to mark a jira to be targeted for a specific release. Currently that is
> 0.11. The description of the Target Version field is given as:
> The versions where this patch is intended to be committed. Use "Fix
> Version" to note where it actually has been committed.
>
> That is exactly what I was taught when I started using bug tracking
> systems. The Fix Version/s is set when the jira is resolved or closed and
> the code is committed and the issue is fixed in that version.
>
> We had 29 jiras that are open marked with a fix version of 0.11. I have
> moved them to a target version. Please do not set a fix version if the code
> has not been committed, use the target version field.
> There are two public searches available that can be used to check what is
> going on for the current release:
> target for next release:
> https://issues.apache.org/jira/issues/?filter=12348416
> fixed in next release:
> https://issues.apache.org/jira/issues/?filter=12350521
>
> These two searches are shown as the project shortcuts for anyone to access.
>
> Wilfred
>