Re: [Development] clang-format

[Christian Gagneraud]

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 ouf of in clang-format, it is
> just cases where it can't do any better.

You can surround code with "// clang-format off" and "// clang-format on".
We've switched to clang-format in git hooks when clang-6 got out, and
it works well.



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

Re: [Development] Monitoring of upstream vulnerabilities

[Thiago Macieira]

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 tool should use, so...

The cve-check-tool should suffice for now. Or reading directly from the NIST 
database, with specific filters for the software that Qt has as third-party.

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



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

Re: [Development] Monitoring of upstream vulnerabilities

[Bernhard B]

>
> 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 estimated timeframe for when it will be
publicly available?
Would be really interested in the details.

2018-06-19 23:13 GMT+02:00 Thiago Macieira :

> 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 public some time, hopefully. It's still in
> development. For now, the other tool works.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Monitoring of upstream vulnerabilities

[Jason H]

> 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. 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 NIST -
> > > https://nvd.nist.gov/.
> > 
> > Is that intel server publicly accessible?
> 
> The dashboard the tool produces isn't, but I also don't see why you'd want 
> that. It's not applicable to Qt. The only people who would want access to it 
> are the people who are working on the distribution and will apply the patches.

!?

The first link is a publicly accessible project. I thought you were referring 
to a replacement project. I wanted to see what CVEMAN was, why it was better, 
etc., (having never hard of it before) and see if it was something I might be 
interested in. But if it's not publicly accessible I wonder how open Qt is if 
we can't use all the tools Qt does.  It could be valid that I don't need to 
worry, but how does the bind Qt to a private tool?

I don't want to make a mountain out of a mole hill, but with all the 
transparency in Qt, I just expected it to be accessible is all. 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Monitoring of upstream vulnerabilities

[Thiago Macieira]

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 public some time, hopefully. It's still in 
development. For now, the other tool works.

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



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

Re: [Development] Monitoring of upstream vulnerabilities

[Bernhard B]

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
> 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 NIST -
> > > https://nvd.nist.gov/.
> >
> > Is that intel server publicly accessible?
>
> The dashboard the tool produces isn't, but I also don't see why you'd want
> that. It's not applicable to Qt. The only people who would want access to
> it
> are the people who are working on the distribution and will apply the
> patches.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Monitoring of upstream vulnerabilities

[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 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 NIST -
> > https://nvd.nist.gov/.
> 
> Is that intel server publicly accessible?

The dashboard the tool produces isn't, but I also don't see why you'd want 
that. It's not applicable to Qt. The only people who would want access to it 
are the people who are working on the distribution and will apply the patches.

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



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

Re: [Development] Monitoring of upstream vulnerabilities

[Jason H]

> 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 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/kcwells/cveman. Both 
> tools consume the feed from the National Vulnerability Database from the US 
> NIST - https://nvd.nist.gov/.

Is that intel server publicly accessible?
 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Monitoring of upstream vulnerabilities

[Thiago Macieira]

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/kcwells/cveman. Both 
tools consume the feed from the National Vulnerability Database from the US 
NIST - https://nvd.nist.gov/.

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



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

Re: [Development] Merge and Integration status report

[Ulf Hermann]

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 less than 15 minutes, but long 
enough to trigger a timeout in the debugging tests after it goes away. So, we 
don't get the watchdog to kill the tests (which would show the concurrently 
running processes), but the tests still fail. See 
https://bugreports.qt.io/browse/QTBUG-68741 for details. We either got 
incredibly lucky with https://codereview.qt-project.org/231618 or the CI has 
another bug and accepted this test although it shouldn't.

br,
Ulf
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Merge and Integration status report

[Simon Hausmann]

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 
failure aborting the integration enough to cause the blockage.


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.


Simon


From: Tomasz Olszak 
Sent: Saturday, June 16, 2018 12:59:46 PM
To: Simon Hausmann
Cc: Jani Heikkinen; development@qt-project.org
Subject: Re: [Development] Merge and Integration status report

Do you use up to date Win 10? Recent updates introduced many issue. E.g one of 
our app couldn't install with some privilege/policy access denied error. It was 
not clear from logs what happened. By trial and errors we just enabled camera 
for applications in security settings and it started to work. It might be good 
idea to reverse a few updates and check if it works.


sob., 16 cze 2018, 11:08 użytkownik Simon Hausmann 
mailto:simon.hausm...@qt.io>> napisał:
Hi,

Unfortunately we haven’t found a solution or workaround yet - the module 
remains blocked.

We can observe some virtual machines slowing down to a grinding halt and we can 
observe that quite often at boot time. The latter causes the CI to kill the vm 
after some time and try creating a new one. That story repeats itself until 
finally a situation/host is found where everything works. This also makes 
overall integration times slower.

We can also observe how every test in debug-and-release is run three times and 
with flaky tests as in this case that increases the probability of an overall 
failure and it increases the overall time to test for all projects.

What nobody has managed to do so far is reproduce the declarative failure in 
front of human eyes. Whenever observed through the hypervisor’s vnc interface 
it appears to work smoothly.

One thing that is unclear to me is what exactly has changed that causes this, 
because I think that given the spread across branches it was not a change in 
declarative or qtbase. Unfortunately we do not have a journal of sorts that 
records what changes were done on the infrastructure at what time.

It might even be an innocent change that triggered an actual bug in 
declarative. Does anybody see odd test failures that seem performance related 
in other modules, across branches?

Simon

On 14. Jun 2018, at 10:53, Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:



Yes, that is another issue. But before that qtbase issue started showing up, 
the same change to 5.11.1 that you're trying to integrated failed when running 
a test that launches a separate process of testing the debugging integration. 
So once the qtbase issue is resolved it's likely that you'll run into the 
declarative failure again.



Simon


From: Jani Heikkinen
Sent: Thursday, June 14, 2018 10:47:43 AM
To: Simon Hausmann; 
development@qt-project.org
Subject: Re: Merge and Integration status report

Actually at least 5.11.1 declarative integration failure is timeout in qtbase 
-> Linux QEMU (gcc-armv7) build. So the failure is different there (in case it 
helps anything)

br,
Jani

From: Development 
mailto:development-bounces+jani.heikkinen=qt...@qt-project.org>>
 on behalf of Simon Hausmann mailto:simon.hausm...@qt.io>>
Sent: Thursday, June 14, 2018 10:32 AM
To: development@qt-project.org
Subject: Re: [Development] Merge and Integration status report

 Hi,


Thank you Liang for the report.


On top of that, qtdeclarative is not accepting any changes in the 5.9, 5.11, 
5.11.1 and dev branches right now.


Those who may have tried staging changes there may have noticed that they are 
failing in one of the tests that launch a separate process for testing the 
debugging integration, limited to Windows 10 (x86 and x86-64).


Until we've found the root cause or a suitable workaround, please don't stage 
changes to qtdeclarative.


I can't see any recent common changes to qtbase or declarative that apply to 
all _four_ branches, so I suspect this flaky issue was caused by something 
below those two modules.


I'll post an update here when we've figured it out (workaround or solution).


Simon


From: Development 
mailto:development-bounces+simon.hausmann=qt...@qt-project.org>>
 on behalf of Liang Qi mailto:liang...@qt.io>>
Sent: Thursday, June 14, 2018 9:18:32 AM
To: development@qt-project.org
Subject: [Development] Merge and Integration status report

Integrations

* qt5 dev integration failed from June 

Re: [Development] clang-format

[Ville Voutilainen]

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:
>
> // clang-format off
> // clang-format on

When I last experienced a large-scale clang-format reformat, it really
hurt development
during the churn. We should somehow manage to do it during a time when
there aren't
many pending patches in the pipeline. I'm not concerned about
git-blame; that has never
been a problem after reformats. However, I do not care about
indentation nor do I want
to spend time on it either way, it has no actual effect on readability
and maintainability
of code, and consistency outside the file you're in has never mattered
to me one bit.

IOW, I'm not opposed to reformats and auto-checking of clang-format
(or even hooking it),
but I do not see it as a thing with all that great return-of-investment.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Philippe]

> 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 Mon, 18 Jun 2018 12:23:53 +0300
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 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.
> 
> * Open changes would need to be rebased on top of it. When would be a good 
> point
>in time with few open changes?
> 
> * 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.
> 
> It is quite a bit of pain while the benefit isn't that big. Actively worked on
> areas would shape up incrementally anyway and the other areas are not read 
> that
> much, so the damage of inconsistent formatting is limited.
> 
> For the above reasons I'd lean towards not running it globally and just using 
> it
> on new changes.
> 
> -- Kari
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] clang-format

[Thiago Macieira]

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 whitespace change, I will dedicate no more than 1 minute per 
change to resolve a conflict or 15 minutes total to rebase my branch once it 
goes in.

Any change that times out will be dropped. That includes all the Qt 6 
container work, the un-accepted QtDBus updates (which include a 
QDBusConnection::connect taking PMF), a large refactoring of QFileSystemEngine 
that no one has reviewed yet despite being on Gerrit for over a year, some 
work for CBOR and a few other miscellaneous changes.

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



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

Re: [Development] clang-format

[Thiago Macieira]

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 format?

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



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

Re: [Development] clang-format

[Allan Sandfeld Jensen]

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 better.Before:

// QStringRef <> QByteArray
inline QT_ASCII_CAST_WARN bool operator==(const QStringRef , const 
QByteArray ) { return lhs.compare(rhs) == 0; }
inline QT_ASCII_CAST_WARN bool operator!=(const QStringRef , const 
QByteArray ) { return lhs.compare(rhs) != 0; }
inline QT_ASCII_CAST_WARN bool operator< (const QStringRef , const 
QByteArray ) { return lhs.compare(rhs) <  0; }
inline QT_ASCII_CAST_WARN bool operator> (const QStringRef , const 
QByteArray ) { return lhs.compare(rhs) >  0; }
inline QT_ASCII_CAST_WARN bool operator<=(const QStringRef , const 
QByteArray ) { return lhs.compare(rhs) <= 0; }
inline QT_ASCII_CAST_WARN bool operator>=(const QStringRef , const 
QByteArray ) { return lhs.compare(rhs) >= 0; }

inline QT_ASCII_CAST_WARN bool operator==(const QByteArray , const 
QStringRef ) { return rhs.compare(lhs) == 0; }
inline QT_ASCII_CAST_WARN bool operator!=(const QByteArray , const 
QStringRef ) { return rhs.compare(lhs) != 0; }
inline QT_ASCII_CAST_WARN bool operator< (const QByteArray , const 
QStringRef ) { return rhs.compare(lhs) >  0; }
inline QT_ASCII_CAST_WARN bool operator> (const QByteArray , const 
QStringRef ) { return rhs.compare(lhs) <  0; }
inline QT_ASCII_CAST_WARN bool operator<=(const QByteArray , const 
QStringRef ) { return rhs.compare(lhs) >= 0; }
inline QT_ASCII_CAST_WARN bool operator>=(const QByteArray , const 
QStringRef ) { return rhs.compare(lhs) <= 0; }

After:

// QStringRef <> QByteArray
inline QT_ASCII_CAST_WARN bool operator==(const QStringRef , const 
QByteArray )
{
return lhs.compare(rhs) == 0;
}
inline QT_ASCII_CAST_WARN bool operator!=(const QStringRef , const 
QByteArray )
{
return lhs.compare(rhs) != 0;
}
inline QT_ASCII_CAST_WARN bool operator<(const QStringRef , const 
QByteArray ) { return lhs.compare(rhs) < 0; }
inline QT_ASCII_CAST_WARN bool operator>(const QStringRef , const 
QByteArray ) { return lhs.compare(rhs) > 0; }
inline QT_ASCII_CAST_WARN bool operator<=(const QStringRef , const 
QByteArray )
{
return lhs.compare(rhs) <= 0;
}
inline QT_ASCII_CAST_WARN bool operator>=(const QStringRef , const 
QByteArray )
{
return lhs.compare(rhs) >= 0;
}

inline QT_ASCII_CAST_WARN bool operator==(const QByteArray , const 
QStringRef )
{
return rhs.compare(lhs) == 0;
}
inline QT_ASCII_CAST_WARN bool operator!=(const QByteArray , const 
QStringRef )
{
return rhs.compare(lhs) != 0;
}
inline QT_ASCII_CAST_WARN bool operator<(const QByteArray , const 
QStringRef ) { return rhs.compare(lhs) > 0; }
inline QT_ASCII_CAST_WARN bool operator>(const QByteArray , const 
QStringRef ) { return rhs.compare(lhs) < 0; }
inline QT_ASCII_CAST_WARN bool operator<=(const QByteArray , const 
QStringRef )
{
return rhs.compare(lhs) >= 0;
}
inline QT_ASCII_CAST_WARN bool operator>=(const QByteArray , const 
QStringRef )
{
return rhs.compare(lhs) <= 0;
}


Before:

#define QT_MEMCPY_USHORT(dest, src, length) \
do {  \
/* Duff's device */   \
ushort *_d = (ushort*)(dest); \
const ushort *_s = (const ushort*)(src);\
int n = ((length) + 7) / 8;   \
switch ((length) & 0x07)  \
{ \
case 0: do { *_d++ = *_s++; Q_FALLTHROUGH(); \
case 7:  *_d++ = *_s++; Q_FALLTHROUGH(); \
case 6:  *_d++ = *_s++; Q_FALLTHROUGH(); \
case 5:  *_d++ = *_s++; Q_FALLTHROUGH(); \
case 4:  *_d++ = *_s++; Q_FALLTHROUGH(); \
case 3:  *_d++ = *_s++; Q_FALLTHROUGH(); \
case 2:  *_d++ = *_s++; Q_FALLTHROUGH(); \
case 1:  *_d++ = *_s++; \
} while (--n > 0);\
} \
} while (false)

inline ushort qConvertRgb32To16(uint c)
{
   return (((c) >> 3) & 0x001f)
| (((c) >> 5) & 0x07e0)
| (((c) >> 8) & 0xf800);
}

inline QRgb qConvertRgb16To32(uint c)
{
return 0xff00
| c) << 3) & 0xf8) | (((c) >> 2) & 0x7))
| c) << 5) & 0xfc00) | (((c) >> 1) & 0x300))
| c) << 8) & 0xf8) | (((c) << 3) & 0x7));
}


After:

#define QT_MEMCPY_USHORT(dest, src, length) 
   \
do {
   \
/* Duff's device */ 
   \
ushort *_d = (ushort *)(dest);  
   \
const ushort *_s = (const ushort 

Re: [Development] clang-format

[Liang Qi]

> 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 will be harder. What's the opinion of our merge 
> master?
> 
> 

We will have 5.11 for a while, perhaps a 5.11.2 after summer at least. So 
better to do it in 5.11, and after it got merged in dev, then do it in dev 
again. That should help merge a lot.

— Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[Allan Sandfeld Jensen]

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 ever run it over the entire codebase.
> 
I would prefer the same. Especially since the first few iterations of the 
formating are not going to be good. If the goal is to minimize the amount of 
back-and-forth during code-review, then we only need to apply it to new 
patches.

And while there are ways around the noise generated, there is really no good 
reason to generate all that noise and auto-uglify the code.

'Allan


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

[Development] Qt 5.11.1 Released

[Jani Heikkinen]

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/mailman/listinfo/development

Re: [Development] clang-format

[Lars Knoll]

> 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 whitespace changes, but 
>> that
>>   does not catch rewrapped lines.
> 
> In my experience, plain "git blame" is not enough in most cases anyway. You 
> go back in history and skip commits you're not interested in. One cleanup 
> commit more to skip doesn't really hurt.

I agree, and Qt Creator makes that actually pretty easy in practice.
> 
>> * Open changes would need to be rebased on top of it. When would be a good 
>> point
>>   in time with few open changes?
> 
> Summer holidays? :)
> I guess there's no perfect point in time. Some open changes will have to be 
> rebased. This also happens if someone else is working in the area your commit 
> touched. Just a minor annoyance IMO.

Some time during summer is fine for me. But we’ll need to have the infra in 
place, so that formatting is enforced for new changes.
> 
>> * 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 will be harder. What's the opinion of our merge 
> master?

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.

Cheers,
Lars

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