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
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")
***
***
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
On 21.09.2018 15:32, Tor Arne Vestbø wrote:
On 21 Sep 2018, at 13:32, Jedrzej Nowacki 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
> On 21 Sep 2018, at 13:32, Jedrzej Nowacki 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
On Friday, September 21, 2018 1:02:10 PM CEST Tor Arne Vestbø wrote:
> > On 21 Sep 2018, at 12:47, Jedrzej Nowacki 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/
>
> On 21 Sep 2018, at 12:47, Jedrzej Nowacki 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:
>>
> 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?
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
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
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
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
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.
> >
> On 29 Aug 2018, at 20:17, 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
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
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
On Fri, Aug 10, 2018 at 03:57:31PM +0200, Shawn Rutledge wrote:
> On 10 Aug 2018, at 15:14, Oswald Buddenhagen 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,
> On 10 Aug 2018, at 15:14, Oswald Buddenhagen wrote:
>
> On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote:
>> On 10 Aug 2018, at 12:07, Oswald Buddenhagen
>> wrote:
>>> so now i think the hook/intergration should just set the fix version to
>>> the target branch name. yes, that
On Fri, Aug 10, 2018 at 02:42:59PM +0200, Shawn Rutledge wrote:
> On 10 Aug 2018, at 12:07, Oswald Buddenhagen 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.
>
>
> On 10 Aug 2018, at 12:07, Oswald Buddenhagen 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
On Fri, Aug 10, 2018 at 08:38:46AM +, Alexander Blasche wrote:
> Thiago Macieira 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
>
From: Development
on behalf of 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
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
From: Development
on behalf of Thiago Macieira
>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
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
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
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
On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote:
> > -Original Message-
> > From: Development > 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:".
> >
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
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
> On 7 Aug 2018, at 16:06, Frederik Gladhorn 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
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
> >
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
> >
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
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
> -Original Message-
> From: Development 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
>
>
>From: Development on
>behalf of Frederik Gladhorn
>Sent: Tuesday, August 7, 2018 12:46 PM
>To: development@qt-project.org
>Subject: [Development] Closing issues automatically with new keyword
>
>Hi all,
>
>I've spend
On Tue, 7 Aug 2018 11:46:12 +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.
> Basically it should be able to set the fixed version and close tasks
On 7 Aug 2018, at 11:46, Frederik Gladhorn 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
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
40 matches
Mail list logo
