[Development] Closing issues automatically with new keyword

[André Hartmann]

Hi Frederik,

one more question: does the script also sets the final Git-SHA1 in the 
Jira "commits" field?

If yes, that would really be a *big* improvement.

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

I think that's acceptable.

André

Am 08.08.2018 um 11:58 schrieb 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
> 
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
>