Re: [Development] IMPORTANT: topic reviews on gerrit disabled
On 11/16/11 16:44, Storm-Olsen Marius (Nokia-MP-Qt/Austin) wrote: On 11/14/11 5:13 PM, ext Oswald Buddenhagen oswald.buddenha...@nokia.com wrote: due to about a dozen bugs, a few of them fairly serious, i went ahead and disabled the topic review functionality. it will come back, but not necessarily this year. :} Have you made a note of those dozen bugs on the wiki, so we can get them looked at properly? it's all in our jira (as far as people could be bothered to report it properly), and the upstream topic review issue (51) links to those i knew of as of monday or so. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NOTE: Gerrit going down for quick fix deployment (13:30 CET)
On 11/17/11 1:12 PM, ext marius.storm-ol...@nokia.com marius.storm-ol...@nokia.com wrote: Hi, Gerrit will go down at 13:30 CET today, for deployment of fixes for the following issues: https://bugreports.qt.nokia.com/browse/QTQAINFRA-167 https://bugreports.qt.nokia.com/browse/QTQAINFRA-270 https://bugreports.qt.nokia.com/browse/QTQAINFRA-335 https://bugreports.qt.nokia.com/browse/QTQAINFRA-347 https://bugreports.qt.nokia.com/browse/QTQAINFRA-350 https://bugreports.qt.nokia.com/browse/QTQAINFRA-352 It should only take a few minutes to deploy and restart the service, should nothing unexpected happen. I'll will send out a follow-up once the service is back up. Deployment was successful, thank you for your patience. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] proposing Richard Moore as approver
On 11/16/11 6:07 PM, ext Sven Anderson sven.ander...@snom.com wrote: Am 02.11.2011 11:14, schrieb Olivier Goffart: But am I alone to think that 3 weeks of waiting time is a lot? 15 work day is a lot, how about reducing it to something between 7 and 10 work days? OTOH, is this really a time-critical process? In doubt I would choose the longer option, not the shorter. The whole point of the time period is to enable key personnel which might be on vacation, sick or otherwise indisposed, to be able to react. 15 business days is normally enough to catch that, while 7-10 days normally isn't. (People tend to take 2 week vacations from work, and not so much 3 weeks or more) It will not affect their ways of working, since those people should even from before they get a nomination be working *as if* they already had the role. The only difference is that after the 15 days they will get a +2 instead of the +1. Nothing else really changes. (Yes, they get a Stage button too, but normally the Author pushes that button) -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Behavior of QStringList in QML changed recently?
Hi, I have some C++ code, returning QStringList to QML. Then I have these code in QML: var stringList = myObject.getStringList(); console.log(stringList) // place 1 var idx = stringList.indexOf(rants); if (idx != -1) stringList.splice(idx, 1); At place 1, it was printing the string list, something like this: random,rants,qml Now it was printing: Object And the splice function on longer remove the rants from the list now... But now I can still get e.g. stringList.length, stringList[1] working fine as before. Any hints? A bug, or just an expected change of the behavior? P.S. I have the latest Qt5 code updated this morning, and running on Kubuntu 11.10. Xizhi Zhu (Steven) Software Engineer @ Qt Development Frameworks Nokia Mobile: +358 (0)50 480 1247 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTemporaryDir API
On Thursday 17 November 2011 14:52:55 ext lars.kn...@nokia.com wrote: Hi David, looks good in general. I am however concerned about the static removeDir() method. This one is pretty much the equivalent of a 'rm -rf'. Since it's not limited to temporary directories, so it doesn't match the class. It's also a rather dangerous operation, and I'm worried we'll see bugs in it's usage leading to users home directories being blown away. The alternative is that each user rolls his own. Of course, he can't blame Qt then if that fails... I'd actually like to have that functionality in Qt, but with a name that stands out and makes it very clear that it is dangerous. removeAllFilesAndDirectoriesRecursively(..., Qt::IReallyMeanIt) ;-) Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTemporaryDir API
On Thursday 17 November 2011 13:52:55 lars.kn...@nokia.com wrote: Hi David, looks good in general. I am however concerned about the static removeDir() method. This one is pretty much the equivalent of a 'rm -rf'. Since it's not limited to temporary directories, so it doesn't match the class. It's also a rather dangerous operation, and I'm worried we'll see bugs in it's usage leading to users home directories being blown away. Well this is actually one of the reasons for having it in QTemporaryDir rather than in QDir : to make it clear that this should only be used for programmatically created dirs (mostly temp dirs, but there are a few other use cases like apps saving stuff into dirs). Not as a general QDir method to be used . The method already asserts if the path is empty or is ., we could make that stricter to catch more bugs (error instead of debug-mode-only assert, and refuse more paths, including the home dir). But I fail to see why this API could be misused is a reason for not having it. I mean, one could make the same argument against having QFile::remove in the API -- it could be used to delete the document that a user spent days to write! In any case: see http://developer.qt.nokia.com/forums/viewthread/9860/ for the popular demand for such a method. I could be convinced to put it into QDir, I would also be very happy to leave it in QTemporaryDir, for almost-like a temp dir but not created by QTemporaryDir because a random naming isn't wanted. But I think it would be a mistake to not have any recursive deletion method, available, still, in Qt5. Note that KTemporaryDir had a removeDir method for many many years and nobody ever blamed the kdelibs developers for bugs in its usage leading to users home dirs being blown away... If the app developers implement their own version and call it wrongly, then the users still lose data, and worse, we make this more likely by not providing a well-tested method to app developers. E.g. it's not only about the starting directory. There's the issue of not following symlinks to directories. Any naive implementation based on QFileInfo will get this wrong, and will follow symlinks. Ouch! -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NOTE: Gerrit going down for quick fix deployment (13:30 CET)
marius.storm-ol...@nokia.com said: On 11/17/11 1:12 PM, ext marius.storm-ol...@nokia.com marius.storm-ol...@nokia.com wrote: Hi, Gerrit will go down at 13:30 CET today, for deployment of fixes for the following issues: https://bugreports.qt.nokia.com/browse/QTQAINFRA-167 https://bugreports.qt.nokia.com/browse/QTQAINFRA-270 https://bugreports.qt.nokia.com/browse/QTQAINFRA-335 https://bugreports.qt.nokia.com/browse/QTQAINFRA-347 https://bugreports.qt.nokia.com/browse/QTQAINFRA-350 https://bugreports.qt.nokia.com/browse/QTQAINFRA-352 It should only take a few minutes to deploy and restart the service, should nothing unexpected happen. I'll will send out a follow-up once the service is back up. Deployment was successful, thank you for your patience. Unfortunately the new version appears to have some quite annoying bug which is damaging the history of our repositories: https://bugreports.qt.nokia.com/browse/QTQAINFRA-389 If you have a look at http://qt.gitorious.org/qt/qtbase/commits/master for example you can see that all of today's changes look like they've been applied twice. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behavior of QStringList in QML changed recently?
Bug reported at: https://bugreports.qt.nokia.com/browse/QTBUG-22808 Thanks in advance ;) Xizhi Zhu (Steven) Software Engineer @ Qt Development Frameworks Nokia Mobile: +358 (0)50 480 1247 From: Adams Christopher (Nokia-MP-Qt/Brisbane) Sent: Friday, November 18, 2011 1:36 AM To: Zhu Xizhi (Nokia-MP-Qt/Tampere); development@qt-project.org Subject: RE: Behavior of QStringList in QML changed recently? Hi, And the splice function on longer remove the rants from the list now... But now I can still get e.g. stringList.length, stringList[1] working fine as before. Any hints? A bug, or just an expected change of the behavior? Yes, I probably broke this accidentally while adding support for QListQString and so forth. Clearly my unit tests weren't comprehensive enough. Please create a bug in jira and assign it to me, I'll get it fixed asap. Cheers, Chris. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
