On 11/27/2015 11:46 AM, Eskil A. Blomfeldt wrote:
We've had a few informal discussions locally about the current process
of manually adding bugs to a meta-task in order for them to be
considered blockers for a particular release.
Wouldn't it be more practical if this was baked into the
Hi Marc,
> You should be able to develop a QPromise/QPackagedTask with the current
> QFutureInterface already.
> At least as long as it's attached to some > QThreadPool.
> What, exactly, are you trying to do that requires a patch to QFI?
I am not aware of any QPackagedTask in Qt, only of
Yes x 1000
On 27/11/15 11:46, Eskil A. Blomfeldt wrote:
Hi!
We've had a few informal discussions locally about the current process
of manually adding bugs to a meta-task in order for them to be
considered blockers for a particular release.
Wouldn't it be more practical if this was baked into
On 27. nov. 2015 13:44, Christian Kandeler wrote:
On 11/27/2015 11:46 AM, Eskil A. Blomfeldt wrote:
So we could define it like this: If a bug report is open and has "Fix
version: Qt X.Y", then it will be considered a blocker for Qt X.Y. The
release team will maintain this the same way they
On Friday, November 27, 2015 02:23:01 PM Eskil A. Blomfeldt wrote:
> I think a batched change for all open reports with a "Fix version" !=
> "Some future release" would have to be part of this. A quick check
> reveals that we (for instance) currently have 27 unresolved bugs with
> fix version
> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Of Christian Kandeler
...
> Sounds sensible, but what about all the existing bugs that have a "Fix
> version" assigned? Won't they all become blockers now? Or can a script
> wipe this field
On Sat, Nov 28, 2015 at 3:07 AM, René JV Bertin wrote:
>
>
> On 28 Nov 2015, at 01:07, Olivier Goffart wrote:
>
>>>
>>> A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct?
>>
>> That code was written for integrating into KDE 4.
>> It
On 28 Nov 2015, at 01:07, Olivier Goffart wrote:
>>
>> A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct?
>
> That code was written for integrating into KDE 4.
> It was not adapted to work with Plasma 5.
>
> A pure KF5 appliation would anyway use
On Friday 27. November 2015 23:39:07 René J.V. Bertin wrote:
> Digging through Qt's source code to figure out if and how I can get KF5
> applications to honour theming settings on OS X, I observe the following in
> class QKdeThemePrivate in qgenericunixthemes.cpp:
>
> static QString
Digging through Qt's source code to figure out if and how I can get KF5
applications to honour theming settings on OS X, I observe the following in
class QKdeThemePrivate in qgenericunixthemes.cpp:
static QString kdeGlobals(const QString )
{
return kdeDir +
On Saturday November 28 2015 01:07:17 Olivier Goffart wrote:
> > A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct?
>
> That code was written for integrating into KDE 4.
That much was clear :)
> A pure KF5 appliation would anyway use the KDE platform theme plugin
Hi!
We've had a few informal discussions locally about the current process
of manually adding bugs to a meta-task in order for them to be
considered blockers for a particular release.
Wouldn't it be more practical if this was baked into the information you
register on the bug itself, so
12 matches
Mail list logo