[Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote:
> > -----Original Message-----
> > From: Development <development-bounces+alexander.blasche=qt.io at qt-
> > project.org> On Behalf Of Jani Heikkinen
> > 
> > >The plan is to update the fix versions and close the task as done when
> > >a line in the commit message starts with "Fixes:".
> > >If the issue is already closed (e.g. cherry-pick) it can add an
> > >additional fix version (e.g. 5.9.7).
> 
> The devil is in the detail. We don't want FixVersion to be set to 5.11 but
> set to 5.11.x.  When you look at a bug 6 month down the road you don't want
> to know that it was fixed in 5.11 but you want to know the exact patch
> level release. Especially the LTS releases tend to have many patch lvl
> number.
> 
> This implies that the script needs to know when 5.11.x was branched off and
> that every following commit to 5.11 branch will imply 5.11.x+1. Whether x+1
> may never be released is irrelevant though as that's a simple bulk change
> when the decision to not have x+1 comes through. Is this what you intend to
> do?

Indeed, I have to make some assumptions.
Right now I have the simple case done: branch == x.y.z -> set fix version to 
x.y.z.

Then there are two cases that I will handle:
branch is 'dev' or 'master' -> find the next minor version
branch is x.y -> find the next valid patch version

Everything else (wip/foobar, other branch names) will be ignored, unless 
someone explains what to do with them otherwise.

> > I see at least one problem there: If bug is affecting to several branches
> > it will be closed when fix for first branch is done even in that case it
> > shouldn't be closed until every branch has a fix...
> 
> That's the developer's decision as much as it is today already. If you know
> that the fix should go to multiple branches you should probably not use the
> "Fixes" keyword for the first commit but the existing "Task-number"
> keyword.

My plan was to let the bot add additional fix versions as changes move through 
branches.
So if a Fixes: QTBUG-9999 goes into 5.12.1, the bug gets closed and fix 
version set to 5.12.1. When it then gets cherry-picked to 5.9.8, the bot will 
see the change again and will add a fix version 5.9.8.

> > Another concern or question is that in which phase we should close the
> > bug; is it done immediately when fix is in or should it be done when fix
> > is in the packages and someone can verify that fix is there and really
> > fixes the problem...
> It can only ever be when it is in the code line. That's correct for 90% of
> all cases. We cannot optimize for the case when releasing becomes creative
> and starts shifting around SHA's or decides to create the package. I am
> sure releasing does not want to be responsible for setting the fix version
> across all tasks. It does not scale. In other words the status quo applies.

Agreed. There is no magic solution and we need to close bugs, even when the 
fix is not released yet, otherwise JIRA becomes useless.
Everyone will understand that if something is closed for 5.12.0 today, it will 
not be in their copy of Qt 5.11.0.
Right now we often don't set the fix version at all, which is even more 
harmful in my opinion.

Frederik

> 
> --
> Alex