[Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

Hi all,

I've spend a bit of time writing a script that monitors gerrit and the git
repositories to update JIRA statuses. It's not quite done yet, but getting
there.
Basically it should be able to set the fixed version and close tasks
automatically.

Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword
to trigger this.

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).

Note: Task-number will be used as before as "this is related to the issue in
some way".

Cheers,
Frederik

[Tor Arne Vestbø]

On 7 Aug 2018, at 11:46, Frederik Gladhorn <***@qt.io> wrote:
>
> Hi all,
>
> I've spend a bit of time writing a script that monitors gerrit and the git
> repositories to update JIRA statuses. It's not quite done yet, but getting
> there.
> Basically it should be able to set the fixed version and close tasks
> automatically.
>

Excellent!

> Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword
> to trigger this.

Sounds good! Perhaps the commit message template should include this field at the bottom too?

>
> 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).
>
> Note: Task-number will be used as before as "this is related to the issue in
> some way”.

Good :)

Tor Arne

>
> Cheers,
> Frederik
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Christian Kandeler]

On Tue, 7 Aug 2018 11:46:12 +0200
Frederik Gladhorn <***@qt.io> wrote:

> I've spend a bit of time writing a script that monitors gerrit and the git
> repositories to update JIRA statuses. It's not quite done yet, but getting
> there.
> Basically it should be able to set the fixed version and close tasks
> automatically.
>
> Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword
> to trigger this.

Sounds like an excellent plan. Thanks.


Christian

[Jani Heikkinen]

>________________________________________
>From: Development <development-bounces+jani.heikkinen=***@qt-project.org> on behalf of Frederik Gladhorn <***@qt.io>
>Sent: Tuesday, August 7, 2018 12:46 PM
>To: ***@qt-project.org
>Subject: [Development] Closing issues automatically with new keyword
>
>Hi all,
>
>I've spend a bit of time writing a script that monitors gerrit and the git
>repositories to update JIRA statuses. It's not quite done yet, but getting
>there.
>Basically it should be able to set the fixed version and close tasks
>automatically.
>
>Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword
>to trigger this.
>
>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).
>
>Note: Task-number will be used as before as "this is related to the issue in
>some way".
>
>Cheers,
>Frederik

Hi,

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...

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...

br,
Jani

[Alex Blasche]

> -----Original Message-----
> From: Development <development-bounces+alexander.blasche=***@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?

> 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.

> 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.

--
Alex

[Frederik Gladhorn]

On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote:
> > -----Original Message-----
> > From: Development <development-bounces+alexander.blasche=***@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

[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-
>>> 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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>

[Frederik Gladhorn]

On onsdag 8. august 2018 12.13.46 CEST André Hartmann wrote:
> 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.

Yes, that's the plan.

Frederik


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

[Thiago Macieira]

On Wednesday, 8 August 2018 02:58:08 PDT Frederik Gladhorn wrote:
> branch is x.y -> find the next valid patch version

Suggestion: use the x.y release and when we make that release, we rename it in
JIRA.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Alex Blasche]

________________________________________
From: Development <development-bounces+alexander.blasche=***@qt-project.org> on behalf of Thiago Macieira <***@intel.com>

>Suggestion: use the x.y release and when we make that release, we rename it in
>JIRA.

That is the current approach and it does not work or scale. Between branching time and release time is a fairly long time. By then the x.y branch contains already x.y.(z+1) fixes (assuming the latest release branch is x.y.z). It is a big pita going through the issues figuring out which is where. I tried this for some time and found it a waste of time.

A better approach might be to have some flag in the gerrit/git system that announces that the last merge for x.y.z was done. The script could then automatically mark fixes targeting the x.y branch as x.y.(z+1)

--
Alex

[Thiago Macieira]

On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote:
> That is the current approach and it does not work or scale. Between
> branching time and release time is a fairly long time. By then the x.y
> branch contains already x.y.(z+1) fixes (assuming the latest release branch
> is x.y.z). It is a big pita going through the issues figuring out which is
> where. I tried this for some time and found it a waste of time.
>
> A better approach might be to have some flag in the gerrit/git system that
> announces that the last merge for x.y.z was done. The script could then
> automatically mark fixes targeting the x.y branch as x.y.(z+1)

Why can't the renaming in JIRA be done at that exact time? That way, we
wouldn't get a mass update of tasks with the version changed.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Alex Blasche]

________________________________________
From: Development <development-bounces+alexander.blasche=***@qt-project.org> on behalf of Thiago Macieira <***@intel.com>

On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote:
> That is the current approach and it does not work or scale. Between
> branching time and release time is a fairly long time. By then the x.y
> branch contains already x.y.(z+1) fixes (assuming the latest release branch
> is x.y.z). It is a big pita going through the issues figuring out which is
> where. I tried this for some time and found it a waste of time.
>
>> A better approach might be to have some flag in the gerrit/git system that
>> announces that the last merge for x.y.z was done. The script could then
>> automatically mark fixes targeting the x.y branch as x.y.(z+1)

>Why can't the renaming in JIRA be done at that exact time? That way, we
>wouldn't get a mass update of tasks with the version changed.

It can and it should probably be done by the release manager. We have never consistently done it so far though.

I find an automated version much cleaner and scalable. Hence my hope fregl can pick this up.

--
Alex

[Oswald Buddenhagen]

On Fri, Aug 10, 2018 at 08:38:46AM +0000, Alexander Blasche wrote:
> Thiago Macieira <***@intel.com> wrote:
> > On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote:
> > > That is the current approach and it does not work or scale.
> > > Between branching time and release time is a fairly long time. By
> > > then the x.y branch contains already x.y.(z+1) fixes (assuming the
> > > latest release branch is x.y.z). It is a big pita going through
> > > the issues figuring out which is where. I tried this for some time
> > > and found it a waste of time.
> > >
this is rather obviously something that should be automated. the system
can easily query the sha1 from the ticket, see what the lowest branch it
appears on in git is, and update the ticket's fix-version if it's wrong.

> > > A better approach might be to have some flag in the gerrit/git
> > > system that announces that the last merge for x.y.z was done. The
> > > script could then automatically mark fixes targeting the x.y
> > > branch as x.y.(z+1)
> > >
i previously thought that this is a good idea, too, but a) there is
inherently a race condition here due to the downmerge, and b) it's an
additional meta data store that needs to be 1) created and 2)
maintained.

so now i think the hook/intergration should just set the fix version to
the target branch name. yes, that implies that we should have the
version "dev" in jira.

a note on the "changes" field: it's kind of redundant with the automated
gerrit link derived from the task-number footer, and consequently many
people _refuse_ to set it "out of principle". however, it has the big
advantage that it allows fixing things up retroactively, both when a bug
link turned out to be bogus and when it was not done to start with. so
the hook should definitely populate it.

> > Why can't the renaming in JIRA be done at that exact time? That way,
> > we wouldn't get a mass update of tasks with the version changed.
> >
that's not a problem. notifications can be suppressed.

> It can and it should probably be done by the release manager. We have
> never consistently done it so far though.
>
yes, because the effort was ridiculous as you noticed yourself.

> I find an automated version much cleaner and scalable. Hence my hope
> fregl can pick this up.
>
yes, as a separate script that is operated "off-line" by the release
manager (or the guy doing the downmerge, which was me so far).

[Shawn Rutledge]

> On 10 Aug 2018, at 12:07, Oswald Buddenhagen <***@qt.io> wrote:
>
> so now i think the hook/intergration should just set the fix version to
> the target branch name. yes, that implies that we should have the
> version "dev" in jira.

Why? I think you can check the tags in git and find out that the highest numbered release was 5.11.1 so far, so dev has to be 5.12? (until Qt 6 anyway) And Jira knows which future versions are not released yet. So when I mark fixed a bug that I fixed on dev, manually, I choose 5.12 alpha, because that’s not released yet. I’d think the script could that too.

[Oswald Buddenhagen]

On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote:
> On 10 Aug 2018, at 12:07, Oswald Buddenhagen <***@qt.io> wrote:
> > so now i think the hook/intergration should just set the fix version to
> > the target branch name. yes, that implies that we should have the
> > version "dev" in jira.
>
> Why? I think you can check the tags in git and find out that the highest numbered release was 5.11.1 so far, so dev has to be 5.12? (until Qt 6 anyway) And Jira knows which future versions are not released yet. So when I mark fixed a bug that I fixed on dev, manually, I choose 5.12 alpha, because that’s not released yet. I’d think the script could that too.
>
firstly, adding a git query to the hook complicates it and reduces its
reliability.

secondly, as your own caveat highlights, you need to encode and maintain
policy in the script to make that work.

thirdly, your proposed heuristics are wrong, because there is a window
of time where changes integrated into dev do *not* target the next minor
release (or a pre-release thereof): the time between the final downmerge
form dev and the actual release.
and we see in practice that people *do* get it wrong all the time,
despite the announcement mails.
dealing with that requires additional meta data, which is precisely what
much of the previous mails was about.

stick to your guns, maybe?

[Shawn Rutledge]

> On 10 Aug 2018, at 15:14, Oswald Buddenhagen <***@qt.io> wrote:
>
> On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote:
>> On 10 Aug 2018, at 12:07, Oswald Buddenhagen <***@qt.io> wrote:
>>> so now i think the hook/intergration should just set the fix version to
>>> the target branch name. yes, that implies that we should have the
>>> version "dev" in jira.
>>
>> Why? I think you can check the tags in git and find out that the highest numbered release was 5.11.1 so far, so dev has to be 5.12? (until Qt 6 anyway) And Jira knows which future versions are not released yet. So when I mark fixed a bug that I fixed on dev, manually, I choose 5.12 alpha, because that’s not released yet. I’d think the script could that too.
>>
> firstly, adding a git query to the hook complicates it and reduces its
> reliability.
>
> secondly, as your own caveat highlights, you need to encode and maintain
> policy in the script to make that work.

Starting to use the Fixes: tag at all is a policy, and writing code that reacts to it amounts to encoding a policy. It’s not the first script which does something like that.

> thirdly, your proposed heuristics are wrong, because there is a window
> of time where changes integrated into dev do *not* target the next minor
> release (or a pre-release thereof): the time between the final downmerge
> form dev and the actual release.

The window between the first creation of a new branch (on Monday) and the final merge from dev to that branch (a week from Monday) is more of a concern; during that time we have a 5.12 branch (assuming we check the highest branch rather than tag) but changes to dev are still for 5.12.

Maybe read .qmake.conf then?

[Oswald Buddenhagen]

On Fri, Aug 10, 2018 at 03:57:31PM +0200, Shawn Rutledge wrote:
> On 10 Aug 2018, at 15:14, Oswald Buddenhagen <***@qt.io> wrote:
> > secondly, as your own caveat highlights, you need to encode and
> > maintain policy in the script to make that work.
>
> Starting to use the Fixes: tag at all is a policy, and writing code
> that reacts to it amounts to encoding a policy. It’s not the first
> script which does something like that.
>
yes, but it's bad engineering to hard-code the policy if it's implicitly
available from somewhere else as data.

> > thirdly, your proposed heuristics are wrong, because there is a window
> > of time where changes integrated into dev do *not* target the next minor
> > release (or a pre-release thereof): the time between the final downmerge
> > form dev and the actual release.
>
> The window between the first creation of a new branch (on Monday) and
> the final merge from dev to that branch (a week from Monday) is more
> of a concern;

> during that time we have a 5.12 branch (assuming we check the highest
> branch rather than tag) but changes to dev are still for 5.12.
>
that's completely true. how is that a concern?

> Maybe read .qmake.conf then?
>
you just topped yourself: now we not only read the git repo's meta data,
but also its content, to extract data in a format that is bound to the
current version of a certain subset of the repositories.
also, this won't work, because the contents of these files intentionally
lag the downmerges - just in case somebody comes to request another
downmerge in some repo, because they've been living under a rock and
missed the deadline (happens on a somewhat regular basis).

[Thiago Macieira]

On Tuesday, 7 August 2018 04:59:02 PDT Jani Heikkinen wrote:
> 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...

I usually close the bug when the first branch gets the fix. When the other
branches get it, I just update the bug report with an extra Fix For and SHA-1.

This is a nice way for the script to do the same.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Oswald Buddenhagen]

On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
> I've spend a bit of time writing a script that monitors gerrit and the git
> repositories to update JIRA statuses. It's not quite done yet, but getting
> there.
>
so why exactly are you doing this after i implied in
https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a
look at
https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
did your investigation reveal that it's unsalvagably bad?

after the elusive gerrit upgrade (hey, we finally have someone assigned
to that now (!)), either script based solution will be obsoleted by
deploying
https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira
anyway.

[Frederik Gladhorn]

On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
> > I've spend a bit of time writing a script that monitors gerrit and the git
> > repositories to update JIRA statuses. It's not quite done yet, but getting
> > there.
>
> so why exactly are you doing this after i implied in
> https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a
> look at
> https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
> did your investigation reveal that it's unsalvagably bad?

I guess it could work, it can close issues, but it doesn't have any idea about
versions. I just looked at the code now.

>
> after the elusive gerrit upgrade (hey, we finally have someone assigned
> to that now (!)), either script based solution will be obsoleted by
> deploying
> https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira
> anyway.

I was not aware of/forgot that comment. I am also unsure if I want to wait for
that gerrit update to manifest.
I'd really like to get the fix version set, so that we can generate change
logs more easily when it comes to fixed issues for each release.

Cheers,
Frederik

>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Tor Arne Vestbø]

> On 7 Aug 2018, at 16:06, Frederik Gladhorn <***@qt.io> wrote:
>
> On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
>> On Tue, Aug 07, 2018 at 11:46:12AM +0200, Frederik Gladhorn wrote:
>>> I've spend a bit of time writing a script that monitors gerrit and the git
>>> repositories to update JIRA statuses. It's not quite done yet, but getting
>>> there.
>>
>> so why exactly are you doing this after i implied in
>> https://bugreports.qt.io/browse/QTQAINFRA-171 that you should have a
>> look at
>> https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
>> did your investigation reveal that it's unsalvagably bad?
>
> I guess it could work, it can close issues, but it doesn't have any idea about
> versions. I just looked at the code now.
>
>>
>> after the elusive gerrit upgrade (hey, we finally have someone assigned
>> to that now (!)), either script based solution will be obsoleted by
>> deploying
>> https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira
>> anyway.
>
> I was not aware of/forgot that comment. I am also unsure if I want to wait for
> that gerrit update to manifest.

Agreed, let’s decouple these two tasks for now. If it turns out the script will be obsoleted, so be it 😊

Tor Arne


> I'd really like to get the fix version set, so that we can generate change
> logs more easily when it comes to fixed issues for each release.


>
> Cheers,
> Frederik
>
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Oswald Buddenhagen]

On Tue, Aug 07, 2018 at 04:06:38PM +0200, Frederik Gladhorn wrote:
> On tirsdag 7. august 2018 14.14.56 CEST Oswald Buddenhagen wrote:
> > https://gerrit-review.googlesource.com/admin/repos/plugins/hooks-jira ?
> > did your investigation reveal that it's unsalvagably bad?
>
> I guess it could work, it can close issues,
>
well, obviously. that's the preferred approach, because the gerrit-based
trigger is easier to get reliable than an external script.

> but it doesn't have any idea about versions. I just looked at the code
> now.
>
your script should be integrated then.

> > https://gerrit-review.googlesource.com/admin/repos/plugins/its-jira
>
> I'd really like to get the fix version set, so that we can generate change
> logs more easily when it comes to fixed issues for each release.
>
yes, me as well. if that feature is missing in the plugin, let's
contribute it - this really looks like something everyone would want.

[Robert Löhning]

Am 07.08.2018 um 11:46 schrieb Frederik Gladhorn:
> Hi all,
>
> I've spend a bit of time writing a script that monitors gerrit and the git
> repositories to update JIRA statuses. It's not quite done yet, but getting
> there.
> Basically it should be able to set the fixed version and close tasks
> automatically.
>
> Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the keyword
> to trigger this.
>
> 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).
>
> Note: Task-number will be used as before as "this is related to the issue in
> some way".
>
> Cheers,
> Frederik

Hi,

would that work for all project in JIRA immediately or only in QTBUG?

Cheers,
Robert

[Frederik Gladhorn]

On tirsdag 7. august 2018 15.23.52 CEST Robert Löhning wrote:
> Am 07.08.2018 um 11:46 schrieb Frederik Gladhorn:
> > Hi all,
> >
> > I've spend a bit of time writing a script that monitors gerrit and the git
> > repositories to update JIRA statuses. It's not quite done yet, but getting
> > there.
> > Basically it should be able to set the fixed version and close tasks
> > automatically.
> >
> > Assuming there is no major protest, I'll use "Fixes: QTBUG-123" as the
> > keyword to trigger this.
> >
> > 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).
> >
> > Note: Task-number will be used as before as "this is related to the issue
> > in some way".
> >
> > Cheers,
> > Frederik
>
> Hi,
>
> would that work for all project in JIRA immediately or only in QTBUG?

It should work for all.

Frederik

>
> Cheers,
> Robert
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Thiago Macieira]

On Tuesday, 7 August 2018 02:46:12 PDT Frederik Gladhorn wrote:
> The plan is to update the fix versions and close the task as done when a
> line in the commit message starts with "Fixes:".

Thanks, Frederik!

Please update the changelog-creation script to detect this keyword too.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[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.

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

[Robert Löhning]

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

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

[Shawn Rutledge]

> On 29 Aug 2018, at 20:17, Robert Löhning <***@qt.io> 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
>
> Cheers,
> Robert

Yes. Also Jira should ideally start showing the patch alongside the bug, as in https://bugreports.qt.io/browse/QTCREATORBUG-20991

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

[Frederik Gladhorn]

Quick update:
Sanity bot and commit template (in 5.11, soon other places) are now updated
and the bot is running.

I'd appreciate if people tried using the Fixes: footer and let me know if the
issue is closed with the right version (or even better, if the fix version is
not set or incorrectly set).

Note that for some products in JIRA the versions are not in any way logical,
so the bot will not set a fix version (QTQAINFRA and the 3d studio stuff for
example).

One thing that would still be great to have is the jira links working so that
the changes show up in JIRA like they do for Task-number, I'm looking into
this and thought the config was fixed, but so far that doesn't seem to do the
trick...

Happy bug fixing!

Cheers,
Frederik

[Frederik Gladhorn]

On Tuesday, September 4, 2018 10:24:17 AM CEST Frederik Gladhorn wrote:
> One thing that would still be great to have is the jira links working so
> that the changes show up in JIRA like they do for Task-number, I'm looking
> into this and thought the config was fixed, but so far that doesn't seem to
> do the trick...

Looks like I nudged it in the right way nwo (writing the config slightly
differently, why one version works and the other doesn't is beyond me).
You should now get jira to show gerrit links when using Fixes.

Cheers,
Frederik

[Sami Nurmenniemi]

I committed this to 5.11 branch:
https://codereview.qt-project.org/#/c/240566/

Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
https://bugreports.qt.io/browse/QTBUG-70493

I'm not sure if it should automatically select the next unreleased version (5.11.3) or use more general version (5.11) or if I used it incorrectly.

> On Tuesday, September 4, 2018 10:24:17 AM CEST Frederik Gladhorn wrote:
> > One thing that would still be great to have is the jira links working so
> > that the changes show up in JIRA like they do for Task-number, I'm looking
> > into this and thought the config was fixed, but so far that doesn't seem to
> > do the trick...

> Looks like I nudged it in the right way nwo (writing the config slightly
> differently, why one version works and the other doesn't is beyond me).
> You should now get jira to show gerrit links when using Fixes.

[Jedrzej Nowacki]

On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote:
> I committed this to 5.11 branch:
> https://codereview.qt-project.org/#/c/240566/
>
> Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
> https://bugreports.qt.io/browse/QTBUG-70493
>
> I'm not sure if it should automatically select the next unreleased version
> (5.11.3) or use more general version (5.11) or if I used it incorrectly.
> > On Tuesday, September 4, 2018 10:24:17 AM CEST Frederik Gladhorn wrote:
> > > One thing that would still be great to have is the jira links working so
> > > that the changes show up in JIRA like they do for Task-number, I'm
> > > looking
> > > into this and thought the config was fixed, but so far that doesn't seem
> > > to
> > > do the trick...
> >
> > Looks like I nudged it in the right way nwo (writing the config slightly
> > differently, why one version works and the other doesn't is beyond me).
> > You should now get jira to show gerrit links when using Fixes.

I looked into the code... That happened because none of these commands
returned 5.11.x:
git show-ref --tags
git show-ref --heads
So from the bot perspective 5.11 branch was never released therefore 5.11.0 is
the next release. For me it looks quite sane, who can add missing tags?

Cheers,
Jędrek

[Sami Nurmenniemi]

> I looked into the code... That happened because none of these commands
> returned 5.11.x:
> git show-ref --tags
> git show-ref --heads
> So from the bot perspective 5.11 branch was never released therefore 5.11.0 is
> the next release. For me it looks quite sane, who can add missing tags?

Thanks, that makes sense for the 5.11 branch. But how did it then generate correct fix version "5.12.0 Beta 1" after this merge commit:
https://codereview.qt-project.org/#/c/240613/ ?

[Tor Arne Vestbø]

> On 21 Sep 2018, at 12:47, Jedrzej Nowacki <***@qt.io> wrote:
>
> On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote:
>> I committed this to 5.11 branch:
>> https://codereview.qt-project.org/#/c/240566/
>>
>> Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
>> https://bugreports.qt.io/browse/QTBUG-70493
>>
>> I'm not sure if it should automatically select the next unreleased version
>> (5.11.3) or use more general version (5.11) or if I used it incorrectly.
>>> On Tuesday, September 4, 2018 10:24:17 AM CEST Frederik Gladhorn wrote:
>>>> One thing that would still be great to have is the jira links working so
>>>> that the changes show up in JIRA like they do for Task-number, I'm
>>>> looking
>>>> into this and thought the config was fixed, but so far that doesn't seem
>>>> to
>>>> do the trick...
>>>
>>> Looks like I nudged it in the right way nwo (writing the config slightly
>>> differently, why one version works and the other doesn't is beyond me).
>>> You should now get jira to show gerrit links when using Fixes.
>
> I looked into the code... That happened because none of these commands
> returned 5.11.x:
> git show-ref --tags
> git show-ref —heads

Shouldn’t that pick refs/heads/5.11?

Tor Arne

[Jedrzej Nowacki]

On Friday, September 21, 2018 1:02:10 PM CEST Tor Arne Vestbø wrote:
> > On 21 Sep 2018, at 12:47, Jedrzej Nowacki <***@qt.io> wrote:
> >
> > On Friday, September 21, 2018 9:07:14 AM CEST Sami Nurmenniemi wrote:
> >
> >> I committed this to 5.11 branch:
> >> https://codereview.qt-project.org/#/c/240566/
> >>
> >> Now Gerrit Bot marked this as fixed in 5.11.0, which is not correct:
> >> https://bugreports.qt.io/browse/QTBUG-70493
> >>
> >> I'm not sure if it should automatically select the next unreleased
> >> version
> >> (5.11.3) or use more general version (5.11) or if I used it incorrectly.
> >>
> >>> On Tuesday, September 4, 2018 10:24:17 AM CEST Frederik Gladhorn wrote:
> >>>
> >>>> One thing that would still be great to have is the jira links working
> >>>> so
> >>>> that the changes show up in JIRA like they do for Task-number, I'm
> >>>> looking
> >>>> into this and thought the config was fixed, but so far that doesn't
> >>>> seem
> >>>> to
> >>>> do the trick...
> >>>
> >>>
> >>> Looks like I nudged it in the right way nwo (writing the config
> >>> slightly
> >>> differently, why one version works and the other doesn't is beyond me).
> >>> You should now get jira to show gerrit links when using Fixes.
> >
> >
> > I looked into the code... That happened because none of these commands
> > returned 5.11.x:
> > git show-ref --tags
> > git show-ref —heads
>
>
> Shouldn’t that pick refs/heads/5.11?
>
> Tor Arne

Yes, that is what happened. The first release branch for 5.11 is 5.11.0,
therefore it marked 5.11.0 as fixed version.

Jędrek

[Tor Arne Vestbø]

> On 21 Sep 2018, at 13:32, Jedrzej Nowacki <***@qt.io> wrote:
>>
>> Shouldn’t that pick refs/heads/5.11?
>>
>> Tor Arne
>
> Yes, that is what happened. The first release branch for 5.11 is 5.11.0,
> therefore it marked 5.11.0 as fixed version.

That doesn’t make any sense. The 5.11 branch is constantly moving. If it resolved to refs/heads/5.11, it should pick the _upcoming_ release for 5.11, or if there is none (in JIRA), not set a fixed version.

Tor Arne

[Kari Oikarinen]

On 21.09.2018 15:32, Tor Arne Vestbø wrote:
>
>> On 21 Sep 2018, at 13:32, Jedrzej Nowacki <***@qt.io> wrote:
>>>
>>> Shouldn’t that pick refs/heads/5.11?
>>>
>>> Tor Arne
>>
>> Yes, that is what happened. The first release branch for 5.11 is 5.11.0,
>> therefore it marked 5.11.0 as fixed version.
>
> That doesn’t make any sense. The 5.11 branch is constantly moving. If it resolved to refs/heads/5.11, it should pick the _upcoming_ release for 5.11, or if there is none (in JIRA), not set a fixed version.
>

Normally it would find a 5.11.2 tag and thus set the fix version as 5.11.3.

The repository in particular does not have those tags, which is the root
cause
for the script not picking the right version. We'll see if we start
tagging it
(the version actually included in releases is determined in meta-boot2qt
which
is tagged, so it's not mandatory) or just mark the versions for these
bugs by
hand, which is not any more work than before the script.


--
Kari

[Christian Ehrlicher]

Hi,

I get this warning when I only add 'Fixes:' in the footer:

***
*** Suspicious changes in commit HEAD (QSqlQuery: add another testcase
for bindBool()):
***
***   commit message:
***     - 8: Text following footers (key "footer")
***
***   See http://wiki.qt.io/Early_Warning_System for explanations.

But gerrit does not complain: https://codereview.qt-project.org/#/c/240736/


Christian

[Christian Ehrlicher]

Am 23.09.2018 um 17:39 schrieb Christian Ehrlicher:
> Hi,
>
> I get this warning when I only add 'Fixes:' in the footer:
>
> ***
> *** Suspicious changes in commit HEAD (QSqlQuery: add another testcase
> for bindBool()):
> ***
> ***   commit message:
> ***     - 8: Text following footers (key "footer")
> ***
> ***   See http://wiki.qt.io/Early_Warning_System for explanations.
>
> But gerrit does not complain:
> https://codereview.qt-project.org/#/c/240736/
Ok, I thought I updated qtrepotools but it wasn't the case.


Christian

[Frederik Gladhorn]

Hello again,

After another round of fixing (such as allowing to close issues that are 'In
Progress', because they have a different name for the transition), adding the
setting of the commit sha1 and no longer setting too many versions, we should
be live with a working bot.

I'm interested in issues that you encounter. I just let the bot run through
all historical commits to fix them up and add for example the missing sha1s.

The rules are basically:
- if there is a lower patch level already in the fix versions, nothing is
added
5.12.1 is there: do not add 5.12.2 or 5.12.3

- if there is a .0 release that is earlier than the current release, nothing
is added
5.12.0 is there: do not add 5.13.0

Cheers,
Frederik