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 <kna...@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 <t...@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 >
