Details
-
Task
-
Resolution: Out of scope
-
P3: Somewhat important
-
None
-
None
-
None
Description
The development work flow for fixing a bug or implementing a simple task in Qt is roughly as follows, from the perspective of JIRA:
(1) The tasks exists and is assigned.
(2) One or multiple changes in Gerrit are made to address the issue or implement the task.
(3) Once the change(s) are merged into the corresponding branch, the developer estimates which release the corresponding git branch is going result in and choose that release version as "Fix version" in JIRA and closes the task.
It is the last step that is not only cumbersome but also error-prone, as the estimate may be wrong or inaccurate, thus potentially misleading the reporter about the availability of a fix.
It is coin that ultimately decides to issue the staging-approve command to Gerrit for a set of tested changes. In practice for regular Qt changes, the fix is first merged into the sub-module and finally the sub-module update is merged into qt5.git, of which packages are built (modulo tqtc-qt5).
If coin was aware of release branches (their names give away the final target release) as well as the minor branches and what next release they turn into, then coin could take care of annotating/closing tasks in JIRA with the correct values. That makes the development workflow more convenient and less error-prone.
I suggest we consider a new tag in commit message in addition to Task-number to let developers control this behavior. For example
Fixes: QTBUG-1234
could be a tag that coin interprets, as it looks at the diff of changes in sub-modules that were just approved into a qt5.git repository supermodule update.
Attachments
Issue Links
- relates to
-
QTQAINFRA-171 Close JIRA issues when a closing change is merged
- Closed