---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124736/#review83860
---
Ship it!
Looks good, but there's a couple of debugging lines
On Monday 18 August 2014 21:54:40 Michael Pyne wrote:
>
> Overview of Proposed Fix
>
>
> What we would like to do instead is the classic Comp. Sci. fix: Another layer
> of indirection.
>
> In this case, we'd like to re-organize the `kde-build-metadata` to map to the
> sa
On 2015-08-13 09:57, Kai Uwe Broulik wrote:
Hi,
My experience with MSVC 2013 was that you even need at least Update 4
for initializer lists to work properly, which was released quite
recently iirc.
And even then, initializer lists don't work in all circumstances
(specifically in member initi
> On Aug. 16, 2015, 9:20 a.m., Alex Merry wrote:
> > Looks good, but there's a couple of debugging lines you've left in that
> > should be removed.
Woa thanks for pointing out the debug lines It shows again that everything
should be reviewed.
- Patrick
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124736/
---
(Updated Aug. 16, 2015, 11:14 a.m.)
Status
--
This change has been m
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124772/
---
Review request for KDE Frameworks.
Repository: kservice
Description
---
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124105/
---
(Updated Aug. 16, 2015, 1:14 p.m.)
Status
--
This change has been ma
On 16 August 2015 at 11:14, David Faure wrote:
> (*) I keep finding the "division" term a bit obscure, and I wonder if this
> shouldn't be
> called "product" instead. I.e. matching how we release things. Nowadays we
> basically have 4 products (frameworks, plasma, applications, extragear?),
> pr
On Sun, August 16, 2015 17:48:59 John Layt wrote:
> On 16 August 2015 at 11:14, David Faure wrote:
> > (*) I keep finding the "division" term a bit obscure, and I wonder if this
> > shouldn't be called "product" instead. I.e. matching how we release
> > things. Nowadays we basically have 4 product
On Sunday 16 August 2015 13:51:29 Michael Pyne wrote:
> There's no reason even with our current build metadata that we'd *have* to
> have project hierarchies, as long as each underlying git repository name
> remains unique. It might even make things easier since there would be no way
> for a sub
David Faure ha scritto:
> On Sunday 16 August 2015 13:51:29 Michael Pyne wrote:
>> There's no reason even with our current build metadata that we'd *have* to
>> have project hierarchies, as long as each underlying git repository name
>> remains unique. It might even make things easier since there
On Sunday, August 16, 2015 11:21:00 PM David Faure wrote:
> On Sunday 16 August 2015 13:51:29 Michael Pyne wrote:
> > There's no reason even with our current build metadata that we'd *have* to
> > have project hierarchies, as long as each underlying git repository name
> > remains unique. It migh
12 matches
Mail list logo
