> On 19 Jun 2018, at 18:19, Ville Voutilainen
> wrote:
>
> On 19 June 2018 at 19:13, Philippe wrote:
>>> For the above reasons I'd lean towards not running it globally and just
>>> using it
>>> on new changes.
>>
>> +1, based on my clang-format experience on a big application.
>>
>> BTW, k
On 20 June 2018 at 03:33, Allan Sandfeld Jensen wrote:
> Btw. Just for your information.
>
> I have attached a few random examples of what we can look forward too after
> running an auto-"beautifying" tool over our hand-formated Qt code. And these
> changes are NOT something we can configure out o
On Tuesday, 19 June 2018 14:22:56 PDT Bernhard B wrote:
> On a side note: Do you know an estimated timeframe for when it will be
> publicly available?
> Would be really interested in the details.
I didn't know it existed until this morning, so no. And, of course, we began
discussing the logo the
>
> Because I didn't realise the tool wasn't public. I saw github and thought
> it
> was. Sorry about that.
>
> Well, CVEMAN will be made public some time, hopefully. It's still in
> development. For now, the other tool works.
>
Many thanks for the clarification!
On a side note: Do you know an es
> Sent: Tuesday, June 19, 2018 at 4:50 PM
> From: "Thiago Macieira"
> To: development@qt-project.org
> Subject: Re: [Development] Monitoring of upstream vulnerabilities
>
> On Tuesday, 19 June 2018 13:15:18 PDT Jason H wrote:
> > > Currently, we use https://github.com/clearlinux/cve-check-tool.
On Tuesday, 19 June 2018 14:04:45 PDT Bernhard B wrote:
> Sorry, I don't get it. But what's the point of providing a link to the
> Intel github rpo if we can't access it?
Because I didn't realise the tool wasn't public. I saw github and thought it
was. Sorry about that.
Well, CVEMAN will be made
Sorry, I don't get it. But what's the point of providing a link to the
Intel github rpo if we can't access it?
Am Dienstag, 19. Juni 2018 schrieb Thiago Macieira :
> On Tuesday, 19 June 2018 13:15:18 PDT Jason H wrote:
> > > Currently, we use https://github.com/clearlinux/cve-check-tool. This
> i
On Tuesday, 19 June 2018 13:15:18 PDT Jason H wrote:
> > Currently, we use https://github.com/clearlinux/cve-check-tool. This is
> > going to be replaced with CVEMAN -
> > https://github.intel.com/kcwells/cveman. Both tools consume the feed from
> > the National Vulnerability Database from the US N
> Sent: Tuesday, June 19, 2018 at 3:46 PM
> From: "Thiago Macieira"
> To: development@qt-project.org
> Subject: [Development] Monitoring of upstream vulnerabilities
>
> As part of the discussion on 3rdparty and security at QtCS, I took an action
> to look into what we use in Clear Linux to mon
As part of the discussion on 3rdparty and security at QtCS, I took an action
to look into what we use in Clear Linux to monitor for reported
vulnerabilities.
Currently, we use https://github.com/clearlinux/cve-check-tool. This is going
to be replaced with CVEMAN - https://github.intel.com/kcwel
Hi,
> Ulf has now submitted a workaround that should also allow us to get
> an overview of running processes if it doesn't work. We've got a set
> of changes trying integration in 5.11 with that workaround merged and
> I'll try to get this also into dev.
Nope, that didn't work. The slowdown lasts
Hi,
It is not a permission issue as far as I can see (literally).
Our best guess at the moment is that some underlying change caused a
performance degradation. That combined with the fact that the CI runs all tests
three times in debug-and-release configurations increases the changes of the
On 19 June 2018 at 19:13, Philippe wrote:
>> For the above reasons I'd lean towards not running it globally and just
>> using it
>> on new changes.
>
> +1, based on my clang-format experience on a big application.
>
> BTW, keep in mind that you can disable clang-format on code sections with:
>
>
> For the above reasons I'd lean towards not running it globally and just using
> it
> on new changes.
+1, based on my clang-format experience on a big application.
BTW, keep in mind that you can disable clang-format on code sections with:
// clang-format off
// clang-format on
Philippe
On Mo
On Tuesday, 19 June 2018 02:34:09 PDT Lars Knoll wrote:
> Currently, we only merge from 5.11 to dev, so I hope this won’t be too bad.
> But we could of course also run the tool over both branches.
I have right now 149 changes on top of qtbase's dev branch. For something that
is ostensibly a white
On Monday, 18 June 2018 02:04:33 PDT Frederik Gladhorn wrote:
> as part of the closing ceremony of this year's Qt Contributors' Summit we
> agreed to start using clang-format, to have fewer discussions around coding
> style and rather focus on the actual code.
Are we going to review the resulting
Btw. Just for your information.
I have attached a few random examples of what we can look forward too after
running an auto-"beautifying" tool over our hand-formated Qt code. And these
changes are NOT something we can configure out ouf of in clang-format, it is
just cases where it can't do any
> On 19 Jun 2018, at 09:58, Joerg Bornemann wrote:
>
>> * Which branch do you run it in? If an early one, there's many merges to do.
>> If
>> a late one, all the subsequent merges are tricky.
>
> Our commit policy suggests that the right branch would be dev.
> You're right that the merges wi
On Montag, 18. Juni 2018 11:23:53 CEST Kari Oikarinen wrote:
> On 18.06.2018 12:04, Frederik Gladhorn wrote:
>
>
> Other parts sound good, so I'll just touch on the big question.
>
> > And then there is the big question when we run it once over the entire
> > codebase.
>
> I'd hesitate to eve
Hi!
We have released Qt 5.11.1 today, see
http://blog.qt.io/blog/2018/06/19/qt-5-11-1-released/
Big thanks to everyone involved!
br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/
> On 19 Jun 2018, at 09:58, Joerg Bornemann wrote:
>
> On 06/18/2018 11:23 AM, Kari Oikarinen wrote:
>
>> I'd hesitate to ever run it over the entire codebase.
>> * It will ruin plain git blame, since so much will point to that particular
>> commit. Yes, you can use `git blame -w` to avoid wh
On 06/18/2018 11:23 AM, Kari Oikarinen wrote:
I'd hesitate to ever run it over the entire codebase.
* It will ruin plain git blame, since so much will point to that particular
commit. Yes, you can use `git blame -w` to avoid whitespace changes,
but that
does not catch rewrapped lines.
22 matches
Mail list logo
