[Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

On onsdag 29. august 2018 20.17.52 CEST Robert Löhning wrote:
> Am 22.08.2018 um 10:53 schrieb Frederik Gladhorn:
> > Quick status update from my side:
> > I have the script running against a test installation of JIRA. It seems to
> > work, there are some small issues to be worked out still.
> > 
> > - Qt Creator version numbers are verbose, so I need to be more generous in
> > matching strings, right now I don't detect the version number correctly
> > there. This one I will fix, it's just going to take a few minutes.
> > 
> > - Qt 3D Studio seems to be a mess, it has 5.x branches but the JIRA
> > versions are 2.x, I consider this a won't fix.
> > 
> > I'd love if people started using "Fixes:", it will work retro-actively.
> > And if you manually close a task in the meantime, no harm is done.
> 
> Looks like somebody should tell the sanity bot:
> https://codereview.qt-project.org/#/c/238280/1//COMMIT_MSG

Seems like nobody volunteered (surprise :P).

Sanity bot:
https://codereview.qt-project.org/#/c/238437/1

Commit template:
https://codereview.qt-project.org/#/c/238435/

I now consider the code done, no idea if/where it should live in the future, 
currently it's some internal repo inside TQtC. It's running in a VM and just 
needs the integration to be enabled in the real JIRA instance, so hopefully it 
goes live in the next few days :)

Cheers,
Frederik


> 
> Cheers,
> Robert
> 
> > Multiple fix versions:
> > There were some doubts about which fix versions would be set, for example
> > during the down-merge. This actually turns out to work quite nicely:
> > If a change ends up in dev, the script will detect that it will end up in
> > 5.13.0 right now and sets that as fix version. If the downmerge happens,
> > the script will see the change again in 5.12.0 and add that fix version.
> > In my opinion there is no major harm.
> > If the change is then cherry-picked to 5.9.7, it will also add that fix
> > version.
> > 
> > This also means that changes going into 5.11.4 will be marked as fixed in
> > 5.12.1 or whatever is applicable branch/version wise. So we will actually
> > set fix versions nicely.
> > 
> > There are some fixes in JIRA that would be easy to make, assuming there is
> > agreement. Since I have to use some heuristics, I decided to only ever
> > look at full version numbers, including patch level releases.
> > Currently we have version numbers in JIRA which do not make much sense to
> > me, since they will never be released, such as 6.0, 5.12 and a few more.
> > I would propose we always use the full version, so 6.0.0 and 5.12.0.
> > If the script finds 5.13 but not 5.13.0 it will not set any fix version.
> > 
> > I'm unsure where the whole thing should live, currently it's internal to
> > The Qt Company, I'd love to publish it somewhere (it's a bunch of python
> > files).
> > 
> > Cheers,
> > Frederik
> > 
> > 
> > 
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development