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@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
