Use of JIRA fixVersion

[Thomas Weise <th...@apache.org>]

Hi,

As part of preparing the 1.14.3 release, I observed that there were
around 200 JIRA issues with fixVersion 1.14.3 that were unresolved
(after blocking issues had been dealt with). Further cleanup resulted
in removing fixVersion 1.14.3  from most of these and we are left with
[1] - these are the tickets that rolled over to 1.14.4.

The disassociated issues broadly fell into following categories:

* test infrastructure / stability related (these can be found by label)
* stale tickets (can also be found by label)
* tickets w/o label that pertain to addition of features that don't
fit into or don't have to go into patch release

I wanted to bring this up so that we can potentially come up with
better guidance for use of the fixVersion field, since it is important
for managing releases [2]. Manual cleanup as done in this case isn't
desirable. A few thoughts:

* In most cases, it is not necessary to set fixVersion upfront.
Instead, we can set it when the issue is actually resolved, and set it
for all versions/branches for which a backport occured after the
changes are merged
* How to know where to backport? "Affect versions" seems to be the
right field to use for that purpose. While resolving an issue for
master it can guide backporting.
* What if an issue should block a release? The priority of the issue
should be blocker. Blockers are low cardinality and need to be fixed
before release. So that would be the case where fixVersion is set
upfront.

Thanks,
Thomas

[1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20Flink%20and%20fixVersion%20%3D%201.14.4%20and%20resolution%20%3D%20Unresolved%20
[2] https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release

Re: Use of JIRA fixVersion

[Till Rohrmann <tr...@apache.org>]

Hi Thomas,

Thanks for creating this proposal. I agree with Konstantin and you that a
bit more guidance for this topic is definitely helpful. I would be ok with
adopting your proposal.

Cheers,
Till

On Wed, Jan 12, 2022 at 9:23 AM Konstantin Knauf <kn...@apache.org> wrote:

> Hi Thomas,
>
> I am also +1 to set fixVersion more conservatively, in particular for patch
> releases. I am not sure we can or should solve this in a "strict" way. I am
> happy to give contributors and contributing teams a bit of freedom in how
> they use fixVersion for planning, but giving more concrete guidance than
> what we currently have in [1] would be desirable, I believe.
>
> Cheers,
>
> Konstantin
>
> [1]
>
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process#FlinkJiraProcess-FixVersion/s
> :
>
> On Tue, Jan 11, 2022 at 8:44 PM Thomas Weise <th...@apache.org> wrote:
>
> > Hi,
> >
> > As part of preparing the 1.14.3 release, I observed that there were
> > around 200 JIRA issues with fixVersion 1.14.3 that were unresolved
> > (after blocking issues had been dealt with). Further cleanup resulted
> > in removing fixVersion 1.14.3  from most of these and we are left with
> > [1] - these are the tickets that rolled over to 1.14.4.
> >
> > The disassociated issues broadly fell into following categories:
> >
> > * test infrastructure / stability related (these can be found by label)
> > * stale tickets (can also be found by label)
> > * tickets w/o label that pertain to addition of features that don't
> > fit into or don't have to go into patch release
> >
> > I wanted to bring this up so that we can potentially come up with
> > better guidance for use of the fixVersion field, since it is important
> > for managing releases [2]. Manual cleanup as done in this case isn't
> > desirable. A few thoughts:
> >
> > * In most cases, it is not necessary to set fixVersion upfront.
> > Instead, we can set it when the issue is actually resolved, and set it
> > for all versions/branches for which a backport occured after the
> > changes are merged
> > * How to know where to backport? "Affect versions" seems to be the
> > right field to use for that purpose. While resolving an issue for
> > master it can guide backporting.
> > * What if an issue should block a release? The priority of the issue
> > should be blocker. Blockers are low cardinality and need to be fixed
> > before release. So that would be the case where fixVersion is set
> > upfront.
> >
> > Thanks,
> > Thomas
> >
> > [1]
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20Flink%20and%20fixVersion%20%3D%201.14.4%20and%20resolution%20%3D%20Unresolved%20
> > [2]
> >
> https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release
> >
>
>
> --
>
> Konstantin Knauf
>
> https://twitter.com/snntrable
>
> https://github.com/knaufk
>

Re: Use of JIRA fixVersion

[Konstantin Knauf <kn...@apache.org>]

Hi Thomas,

I am also +1 to set fixVersion more conservatively, in particular for patch
releases. I am not sure we can or should solve this in a "strict" way. I am
happy to give contributors and contributing teams a bit of freedom in how
they use fixVersion for planning, but giving more concrete guidance than
what we currently have in [1] would be desirable, I believe.

Cheers,

Konstantin

[1]
https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process#FlinkJiraProcess-FixVersion/s
:

On Tue, Jan 11, 2022 at 8:44 PM Thomas Weise <th...@apache.org> wrote:

> Hi,
>
> As part of preparing the 1.14.3 release, I observed that there were
> around 200 JIRA issues with fixVersion 1.14.3 that were unresolved
> (after blocking issues had been dealt with). Further cleanup resulted
> in removing fixVersion 1.14.3  from most of these and we are left with
> [1] - these are the tickets that rolled over to 1.14.4.
>
> The disassociated issues broadly fell into following categories:
>
> * test infrastructure / stability related (these can be found by label)
> * stale tickets (can also be found by label)
> * tickets w/o label that pertain to addition of features that don't
> fit into or don't have to go into patch release
>
> I wanted to bring this up so that we can potentially come up with
> better guidance for use of the fixVersion field, since it is important
> for managing releases [2]. Manual cleanup as done in this case isn't
> desirable. A few thoughts:
>
> * In most cases, it is not necessary to set fixVersion upfront.
> Instead, we can set it when the issue is actually resolved, and set it
> for all versions/branches for which a backport occured after the
> changes are merged
> * How to know where to backport? "Affect versions" seems to be the
> right field to use for that purpose. While resolving an issue for
> master it can guide backporting.
> * What if an issue should block a release? The priority of the issue
> should be blocker. Blockers are low cardinality and need to be fixed
> before release. So that would be the case where fixVersion is set
> upfront.
>
> Thanks,
> Thomas
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20Flink%20and%20fixVersion%20%3D%201.14.4%20and%20resolution%20%3D%20Unresolved%20
> [2]
> https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release
>


-- 

Konstantin Knauf

https://twitter.com/snntrable

https://github.com/knaufk