Whoops, re-sending to dev...
On Tue, Mar 26, 2013 at 1:38 PM, Alan Alpert <4163654...@gmail.com> wrote:
> On Tue, Mar 26, 2013 at 12:32 AM, Stephen Kelly
> wrote:
>> On Monday, March 25, 2013 18:19:57 Alan Alpert wrote:
>>> More time to iterate is always welcomed. This may lead to a
>>> source-i
On Tue, Mar 26, 2013 at 11:04 AM, Thiago Macieira
wrote:
> On segunda-feira, 25 de março de 2013 10.42.27, Alan Alpert wrote:
>> > This is not good enough a reason. Any new feature can only be accepted in
>> > *dev* once it's complete: that is, it is there, works, unit-tested,
>> > documented, wit
On terça-feira, 26 de março de 2013 14.07.56, Sergio Ahumada wrote:
> As far as I understand, the CI is all in Finland, so GMT +2.
In other words, the tests are effectively disabled.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
si
On segunda-feira, 25 de março de 2013 18.19.57, Alan Alpert wrote:
> tl;dr -> Okay, let's make it private for 5.1 (also works for
> BlackBerry) and aim to polish it for 5.2.
Maintainer agrees. Go for it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source T
On segunda-feira, 25 de março de 2013 10.42.27, Alan Alpert wrote:
> > This is not good enough a reason. Any new feature can only be accepted in
> > *dev* once it's complete: that is, it is there, works, unit-tested,
> > documented, with examples if necessary, and an initial API review has been
> >
> > It fails for me, too; the tests are off by 1 hour, it seems.
> > This is indeed a mystery. Is the CI in a "European" timezone?
> >
>
> the CI log shows:
>
> --
> Testing tst_QDateTime
> Totals: 350 passed, 0 failed, 34 skipped
> -
On terça-feira, 26 de março de 2013 15.30.42, David Faure wrote:
> > correct (though, if it really is a performance *fix*, you should
> > consider 5.1/stable).
>
> Well, performance *improvements*.
>
> AFAIU these should go into dev, because of the higher risk of regressions.
Depends on the change
On Tuesday 26 March 2013 14:25:35 Oswald Buddenhagen wrote:
> On Tue, Mar 26, 2013 at 01:30:26PM +0100, David Faure wrote:
> > On Wednesday 20 March 2013 15:53:38 Oswald Buddenhagen wrote:
> > > the "lock" can be removed on friday evening, i think. at least i hope
> > > all integrations are done an
On Tue, Mar 26, 2013 at 01:30:26PM +0100, David Faure wrote:
> On Wednesday 20 March 2013 15:53:38 Oswald Buddenhagen wrote:
> > the "lock" can be removed on friday evening, i think. at least i hope
> > all integrations are done and everyone got that by this time.
>
> Now that all modules have had
On 03/26/2013 01:48 PM, Friedemann Kleint wrote:
> Hi,
>
> > tst_qdatetime on Windows with a European time zone throws up 8
> failures for
> > me on a clean build without my changes. Does this happen for anyone
> else? Is
> > this test disabled in CI, because I don't see how anything could
Hi,
I've pushed (and merge) most of the changelogs for 5.0.2 release. The
only missing one (in terms of completeness) is the one from qtbase.git
So please (Maintainers in particular) go and check that all the
changelogs are correct and fill up the missing bit and pieces for qtbase.git
- https:
Hi,
> tst_qdatetime on Windows with a European time zone throws up 8
failures for
> me on a clean build without my changes. Does this happen for anyone
else? Is
> this test disabled in CI, because I don't see how anything could be
passing
> otherwise?
It fails for me, too; the tests are
On Wednesday 20 March 2013 15:53:38 Oswald Buddenhagen wrote:
> the "lock" can be removed on friday evening, i think. at least i hope
> all integrations are done and everyone got that by this time.
Now that all modules have had dev merged into stable, could the lock be
removed?
"dev" is Qt 5.2 n
> qtbase:
> Freetype (*)
https://codereview.qt-project.org/#change,52240 +
https://codereview.qt-project.org/52241
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Monday, March 25, 2013 18:19:57 Alan Alpert wrote:
> More time to iterate is always welcomed. This may lead to a
> source-incompatible change in Plasma Packages though, ideally we'd
> only do that once with the existing incompatible change of KDE
> Frameworks 5. Would that be using the 5.1 or 5.
15 matches
Mail list logo
