Re: [Development] On the effectiveness of time based releases
-Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [...] Before merging a feature the maintainers consider if yes or not the feature is ready for integration. If bad decisions are made, I don't think the time- based releases have anything to do with that. It has to some degree, because it leads to rushing features in before the deadline; and then API reviews, blatant bug fixes, writing examples, source cleanups, etc. happen in stable after the merge (and not, as I said, before even merging into dev). The thing is, you can't get out any release of something as big as Qt without deadlines. And with deadlines comes the rush to get stuff in ... Actually that's even worse when it's pretty unclear when the next major version will be released, cause everybody knows that the original schedules aren't worth the paper they're written on, in the first place. We had that in Qt 4 times. I just checked, it took 15 months from the release of 4.7.0 until 4.8.0. We routinely did miss target dates by a couple of months. One of the results was that we crammed in features into patch level releases... [1] Maybe we do indeed take features in too lightly. And maybe we have to be more strict following up on new features to make sure that they're really polished ready at release time. But for all of this, having a predictable schedule is IMO a necessary prerequisite. Regards Kai [1]: I know that Qt 4.7/4.8 were kind of special for various reasons, and that it wasn't all caused by the unpredictable schedule. But it definitely didn't help. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Performance of QUdpSocket writeDatagram between Qt4 and Qt5 in different GNU/Linux platforms
Em qua 26 fev 2014, às 10:29:46, Peter Hartmann escreveu: Hello, it might be the socket is bind()ing to a local address when it does not need to; would you be able to file a bug report with a program to reproduce the problem? The interesting part to me are those SIOCGIFINDEX calls. We don't have those directly in our codebase, so it's coming from some library function we call. Probably if_nametoindex or the reverse. -- 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] Branches and time based releases
On Feb 25, 2014, at 6:40 PM, Thiago Macieira thiago.macie...@intel.com wrote: Em ter 25 fev 2014, às 11:33:00, Oswald Buddenhagen escreveu: I.e., nothing changes. I propose this branch stay named dev, for clarity of purpose, not master. i don't think the clarity buys us much. like the rest of the branch naming stuff, it is really a minor detail for the average contributor. otoh, the deviation from the default leads to *every* project so far having to rename their master branch upon promotion to being an official part of qt. They should instead start with a branch called dev. That means there's no renaming necessary later on. It equally solves the problem. I still feel we're solving the wrong problem. Or, we can say we're working around the problem because really solving it is not within our means right now. even if we could optimize CI to the point where a forward-merge would reliably go through in half an hour (which i think is a realistic target when we actually concentrate on that, but we likely won't get there within the next months), we still have a) that half-hour lockdown which is weird in itself and b) the administrative overhead of implementing the lockdown (fiddling with gerrit permissions). so even in the optimal case, branching would be *still* cleaner than downmerging. If it passes reliably within half an hour, no lockdown is necessary. The lockdown is only necessary today so the people doing the merging don't have to tear their hair out to keep track of two moving targets. If Δt tends to 0, Δchanges also tends to zero, which means it's effectively frozen in time. Also, we don't need to pass within half an hour. We just need to pass on the first try. probably not unexpectedly, i don't like that. thiago insists on the forward merge, and all other things being equal, the number of commits wouldn't go down, so we would arrive at a significant number of duplicated commits. I really insist that the tag is part of the past history. note that there is an alternative to the forward merge that thiago at least didn't reject outright last time i proposed it: create a shadow tag on the stable branch which marks the last commit that went into a particular release (but obviously also already contains commits that were not released at that time). that would make the cherry-pick solution more palatable. I'm fine with that, as long as I can check out the tag and get the actual contents of the release. Very often, when looking at bugs or other issues, I'll do git show v5.x.y:src/corelib/foo/bar.cpp and see if the issue was already there. But I think you're suggesting something like this: A--B--C--D-- 5.3 \--E--F If F is tagged v5.3.1, then B is tagged branchpoint-5.3.1. That means D gets described as branchpoint-5.3.1-2-gXX. Maybe it could be tagged branchpoint-5.3.2. Maybe instead C should be the Bump version commit and be tagged. I dislike duplicating the number of tags in the repository. It will create confusion. So I would prefer the merge back, since the duplication of commits doesn't cause confusion, regardless of the number of them. release. The fact that we're changing the names of the branches does not invalidate the reason why we chose HEAD to point to stable back in 2011: people should be presented with the most currently relevant yet stable release available when they clone the repository. And given 2½ years of experience on this, I can confidently say that this is also the this is the branch that most of our developers spend time on. i would argue that this is one of the branch-related things that really don't matter for the vast majority of contributors. a reasonable developer makes a conscious decision about his target branch rather than cloning and just hacking away. And I would argue the opposite. A reasonable developer is not what you get in the #qt channel. There are lots of people checking out Git repositories and building their own Qt, without really understanding what they're doing. In the past two weeks or so, I've caught a lot of non-contributors building with -developer-build without understanding what it did, just because they found that in some wiki page. Maybe they did not follow “some wiki page”, but http://qt-project.org/wiki/Building_Qt_5_from_Git ? Because that is exactly what is written there, and that page is really our reference page on how to build Qt5 from git. It also explicitly states “git checkout stable”, btw. That means when we create 5.x from dev, someone needs to go and update all the Gerrit and Gitorious repositories' HEAD. only if you volunteer to either do that yourself, or write (and maintain) a http client script that reliably does it for us. I'm not the one proposing the branch name change. The people proposing that should take into account the work required to keep this working in their proposal and plan
Re: [Development] Performance of QUdpSocket writeDatagram between Qt4 and Qt5 in different GNU/Linux platforms
Hello Peter, no I haven`t report it in a bug tracker yet. I still do not know if it is just an issue related to my specific platform. If I interpreted correctly what Thiago is trying to explain, maybe using QT5 together with some other low level library of some specific version I might have installed in my platform can cause this unexpected ioctl call? Is there a way to get rid of that? Maybe initializing under the hood the socket handled by QUdpSocket with some 'magic' parameter? Also the sendto function seems to use a slightly different set of parameters. Can I make those ones the same of the QT4.8.5? Regards, Mauro On 26 February 2014 10:35, Thiago Macieira thiago.macie...@intel.comwrote: Em qua 26 fev 2014, às 10:29:46, Peter Hartmann escreveu: Hello, it might be the socket is bind()ing to a local address when it does not need to; would you be able to file a bug report with a program to reproduce the problem? The interesting part to me are those SIOCGIFINDEX calls. We don't have those directly in our codebase, so it's coming from some library function we call. Probably if_nametoindex or the reverse. -- 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] Performance of QUdpSocket writeDatagram between Qt4 and Qt5 in different GNU/Linux platforms
On 02/26/2014 10:56 AM, Mauro Brenna wrote: no I haven`t report it in a bug tracker yet. I still do not know if it is just an issue related to my specific platform. If you had an example program to reproduce the problem, I could check on my side whether the problem can be reproduced. Maybe the bug tracker (https://bugreports.qt-project.org/) is the right way to discuss this further... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On the effectiveness of time based releases
Koehne Kai [kai.koe...@digia.com] [...] Before merging a feature the maintainers consider if yes or not the feature is ready for integration. If bad decisions are made, I don't think the time- based releases have anything to do with that. It has to some degree, because it leads to rushing features in before the deadline; and then API reviews, blatant bug fixes, writing examples, source cleanups, etc. happen in stable after the merge (and not, as I said, before even merging into dev). The thing is, you can't get out any release of something as big as Qt without deadlines. And with deadlines comes the rush to get stuff in ... Worse, it creates a bias. When the more responsible people hold back their changes early to not delay the release and others keep shuffling in rushed last minute implementations, the majority of features will be rushed. [...] Maybe we do indeed take features in too lightly. And maybe we have to be more strict following up on new features to make sure that they're really polished ready at release time. But for all of this, having a predictable schedule is IMO a necessary prerequisite. Not maybe, it's certain. It's dead easy to get a feature in, especially in modules that are not as tightly controlled as qtbase. And it's basically impossible to get something out again, due to the binary compatibility promises. So we keep accumulating semi-broken, politically unfixable stuff, making Qt fatter, and stretching out resources thinner and thinner. And this _is_ a pure policy issue, nothing technical here. To stop this trend, there must be a tight reign on feature development in _all_ modules. Having a centralized joint API sanity master instance would definitely be a step into the right direction. It sort of used to work at a time... Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Performance of QUdpSocket writeDatagram between Qt4 and Qt5 in different GNU/Linux platforms
You can find the example program sourcecode in my first e-mail. I will try to open a bug then. Thanks again, Mauro On 26 February 2014 11:06, Peter Hartmann phartm...@blackberry.com wrote: On 02/26/2014 10:56 AM, Mauro Brenna wrote: no I haven`t report it in a bug tracker yet. I still do not know if it is just an issue related to my specific platform. If you had an example program to reproduce the problem, I could check on my side whether the problem can be reproduced. Maybe the bug tracker ( https://bugreports.qt-project.org/) is the right way to discuss this further... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Performance of QUdpSocket writeDatagram between Qt4 and Qt5 in different GNU/Linux platforms
I have just reported the bug: QTBUG-37092 https://bugreports.qt-project.org/browse/QTBUG-37092 We can continue the discussion there. Thanks. Kind regards, Mauro On 26 February 2014 11:27, Mauro Brenna malloble...@gmail.com wrote: You can find the example program sourcecode in my first e-mail. I will try to open a bug then. Thanks again, Mauro On 26 February 2014 11:06, Peter Hartmann phartm...@blackberry.comwrote: On 02/26/2014 10:56 AM, Mauro Brenna wrote: no I haven`t report it in a bug tracker yet. I still do not know if it is just an issue related to my specific platform. If you had an example program to reproduce the problem, I could check on my side whether the problem can be reproduced. Maybe the bug tracker ( https://bugreports.qt-project.org/) is the right way to discuss this further... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Features in Qt-5.3
On Tuesday, 2014-02-25, 09:00:21, Wolfgang Baron wrote: Hi all, I read somewhere, that there are plans for a pure-Qt QtDBus (not using dbus-1) implementation in Qt-5.3, which would run on all platforms (including mswindows). QtDBus already works on Windows. As far as I know it is just not built by default. Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On the effectiveness of time based releases
On Wednesday 26 February 2014 08:17:35 Koehne Kai wrote: [1]: I know that Qt 4.7/4.8 were kind of special for various reasons, and that it wasn't all caused by the unpredictable schedule. But it definitely didn't help. 4.8 WAS very special. 4.8 was never really planed. When 4.7 was released on the phones, it was decided that we would put all the features in 4.7.x since downstream was afraid of a 4.8 release. All development was concentrated on 4.7.4 which was really a feature realease. Then when Nokia stopped caring about meego, all the focus went to Qt5. So you can't really take 4.8 or 5.0 as examples because they are special. Maybe we do indeed take features in too lightly. And maybe we have to be more strict following up on new features to make sure that they're really polished ready at release time. But for all of this, having a predictable schedule is IMO a necessary prerequisite. Normally, according to the current model, that's how it should be currently. If it has not,that's because people have broken the rules. It's not a flaw of the model. If anything need to be changed is to be more strict with the rules. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On the effectiveness of time based releases
On Wednesday, February 26, 2014 12:18:51 Olivier Goffart wrote: If anything need to be changed is to be more strict with the rules. Hear hear! Also, be more strict with the spirit of the rules. If you get a feature in just before the branching step, you minimize testing/integration time. If you get it in just after the branching step you maximize it. The former seems to be the general way things happen, but I don't think it should be. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Features in Qt-5.3
Em qua 26 fev 2014, às 12:18:41, Kevin Krammer escreveu: On Tuesday, 2014-02-25, 09:00:21, Wolfgang Baron wrote: Hi all, I read somewhere, that there are plans for a pure-Qt QtDBus (not using dbus-1) implementation in Qt-5.3, which would run on all platforms (including mswindows). QtDBus already works on Windows. As far as I know it is just not built by default. That is true. And one of the reasons why it isn't built by default is the lack of libdbus-1 headers on Windows systems. Once we no longer depend on libdbus-1, QtDBus will be enabled by default on all platforms. -- 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] Adding 10-bit OpenGL support in QML
Thanks for the reply. On 25 Feb 2014, at 23:22, Gunnar Sletta gunnar.sle...@jolla.com wrote: On 26 Feb 2014, at 00:42, Kurt Pattyn pattyn.k...@gmail.com wrote: We are currently looking into a way to render a 10-bit image in QML. I'm going to assume we're talking about Qt Quick 2.0. Yes, indeed. As in 10-bit grayscale or GL_UNSIGNED_INT_10_10_10_2? Yes, both grayscale and color 10-bit. In any case, you can create a custom QSGTexture class which defines the format and contents of your texture and display that in the scene graph using a QSGSimpleTextureNode. If something more specific is needed, write your own material to do exactly what you want. Is it correct that we can subclass a QQuickItem and return a subclassed QSGSimpleTextureNode object from the updatePaintNode() method? Our first idea is to create an OpenGL context in C++ and use that in QML. You cannot create the OpenGL context for QQuickWindow, but you can request the format it should take via QQuickWindow::setFormat(). QML must be able to overlay text on this 10-bit OpenGL context. What is the best approach for this? Is it possible at all? Can we expose a QGLWidget, or something similar? QQuickWindow has an QOpenGLContext and does not use QGLWidget. So, as I understand this is what should be done: QSurfaceFormat surfaceFormat; surfaceFormat.setRenderableType(QSurfaceFormat::OpenGL); //set bitDepth on surfaceFormat QQuickView * view = new QQuickView(); view-setFormat(surfaceFormat); And then use a subclassed QQuickItem together with a subclassed QSGSimpleTextureNode. Is this correct? Cheers, Kurt cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding 10-bit OpenGL support in QML
On 26 Feb 2014, at 18:26, Kurt Pattyn pattyn.k...@gmail.com wrote: Thanks for the reply. On 25 Feb 2014, at 23:22, Gunnar Sletta gunnar.sle...@jolla.com wrote: On 26 Feb 2014, at 00:42, Kurt Pattyn pattyn.k...@gmail.com wrote: We are currently looking into a way to render a 10-bit image in QML. I'm going to assume we're talking about Qt Quick 2.0. Yes, indeed. As in 10-bit grayscale or GL_UNSIGNED_INT_10_10_10_2? Yes, both grayscale and color 10-bit. In any case, you can create a custom QSGTexture class which defines the format and contents of your texture and display that in the scene graph using a QSGSimpleTextureNode. If something more specific is needed, write your own material to do exactly what you want. Is it correct that we can subclass a QQuickItem and return a subclassed QSGSimpleTextureNode object from the updatePaintNode() method? Indeed. The default texture material assumes RGBA values, though, so at least for the grayscale texture, you probably want to write a custom material to pick only the 'r' gray value. https://qt-project.org/doc/qt-5.1/qtquick/scenegraph-simplematerial.html shows how to use a custom material. Our first idea is to create an OpenGL context in C++ and use that in QML. You cannot create the OpenGL context for QQuickWindow, but you can request the format it should take via QQuickWindow::setFormat(). QML must be able to overlay text on this 10-bit OpenGL context. What is the best approach for this? Is it possible at all? Can we expose a QGLWidget, or something similar? QQuickWindow has an QOpenGLContext and does not use QGLWidget. So, as I understand this is what should be done: QSurfaceFormat surfaceFormat; surfaceFormat.setRenderableType(QSurfaceFormat::OpenGL); //set bitDepth on surfaceFormat QQuickView * view = new QQuickView(); view-setFormat(surfaceFormat); And then use a subclassed QQuickItem together with a subclassed QSGSimpleTextureNode. Is this correct? I haven't tried 8-bit target frame buffers, but if they are exposed as normal GL configs, you would be doing something like: QSurfaceFormat format; format.setRedDepthBufferSize(10); format.setGreenDepthBufferSize(10); format.setBlueDepthBufferSize(10); format.setDepthBufferSize(24); format.setStencilBufferSize(8); QQuickView view; view.setFormat(format); ... view.show(); cheers, Gunnar BTW, For general questions on how to USE Qt, inter...@qt-project.org is more suited. The development list is for developing Qt itself. Cheers, Kurt cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: [ANNOUNCE] libinput 0.1
-- Mensagem encaminhada -- Assunto: [ANNOUNCE] libinput 0.1 Data: qua 26 fev 2014, 22:03:32 De: Jonas Ådahl jad...@gmail.com Para: wayland-de...@lists.freedesktop.org The first official release of libinput, 0.1, is now available. There is no API/ABI stability promised for this release, but what can be said is that there are no big changes planned, meaning a user of this library will not need to make large changes to support future versions of libinput. What is libinput? libinput is a library that handles input devices for display servers and other applications that need to directly deal with input devices. It provides device detection, device handling, input device event processing and abstraction so minimize the amount of custom input code the user of libinput need to provide the common set of functionality that users expect. Where can I get it? You can download the source code either by checking out the 0.1.0 tag from the git repository at git://anongit.freedesktop.org/wayland/libinput or download the tarball: http://www.freedesktop.org/software/libinput/libinput-0.1.0.tar.xz MD5: f5d794beb5228353f480d15a058e1885 SHA1: 4d38a9c3aea30f98c53108c7e91364427ed0015a SHA256: 63214727be5115806868ebdf9470fe2ddf4b2e1229102e080237380d22b40a1d Enjoy! Jonas ___ wayland-devel mailing list wayland-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel - -- 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] qt5.git integration failed again
Hi all, There seems to be some build break in qt5.git stable integration with latest changes: Qt Continuous Integration System7:40 AM Patch Set 3: qtscript failed to compile :( ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:1027:9: note: expanded from macro 'DEFINE_STUB_FUNCTION' ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:1027:9: note: expanded from macro 'DEFINE_STUB_FUNCTION' ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:1027:9: note: expanded from macro 'DEFINE_STUB_FUNCTION' ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:1027:9: note: expanded from macro 'DEFINE_STUB_FUNCTION' ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:1027:9: note: expanded from macro 'DEFINE_STUB_FUNCTION' ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:1027:9: note: expanded from macro 'DEFINE_STUB_FUNCTION' ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:1027:9: note: expanded from macro 'DEFINE_STUB_FUNCTION' ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:1027:9: note: expanded from macro 'DEFINE_STUB_FUNCTION' inline asm:16:1: error: invalid instruction inline asm:32:1: error: invalid instruction make[4]: *** [obj/release/iphoneos/JITStubs.o] Error 1 make[3]: *** [iphoneos-all] Error 2 make[2]: *** [sub-script-make_first-ordered] Error 2 make[1]: *** [sub-src-make_first] Error 2 make: *** [module-qtscript-make_first] Error 2 Build log: http://testresults.qt-project.org/ci/Qt5_stable_Integration/build_00611/macx-ios-clang_OSX_10.8/log.txt.gz Changes under integration: * qtbase 45e17d0...9d2d4ad (20): Cocoa: Fix popup window positioning. eglfs: Improve cursors and hotspots Cocoa: Set geometry for foreign views. Cocoa: Remove tablet event warnings. Cocoa: Dont crash at toolbar cleanup time. Use Qts RTTI setting when building ANGLE statically. Use a VAO in the texture glyph cache Fix glyph texture format on core profile Texture glyph cache: Use a vbo Android: Make default permissions less confusing Android: Support pregenerated cache in assets file engine Logging: Change rules section name to Rules Fix compile error when enabling the QHOSTINFO_DEBUG define Remove the option to force no JIT in javascript core QPrinter - Add more tests QPrintEngine - Improve devMode handling QPrintEngine - Remove Windows use of port and driver WinRT: Fix backing store for latest ANGLE ANGLE: Allow for universal program binaries Upgrade ANGLE to 1.3.5bb7ec572d0a * qtconnectivity c969ca2...f58cddd (6): Remove QBluetoothSocketPrivate::socketDescriptor() QNX Service registered value fix Fix crash when calling QBluetoothLocalDevice::connectedDevices() Max pending connection check for QNX server implemented Revert Bump latest Nfc QML API version to 5.4 QNX QBluetoothSocket state fix * qtdeclarative 7d25db8...124b8b2 (2): qmlplugindump: adding isComposite Make GridView/ListView attached view property available to all delegate types * qtdoc 15c0c98...b5f6de9 (1): Doc: Fix small typo * qtlocation e656c31...10141bb (8): Bump all qml code to QtLocation 5.3 Fix QtLocation QML API and its version. Use 512 pixel tiles from the Nokia/HERE service. Remove unnecessary code. Map item geometry do not need to be QObjects. Remove test code related to removed gestures. Fix unstable PositionInfo test. Fix translatable strings and cleanup unnecessary strings * qtquickcontrols 44e9533...14d472b (4): Add Calendar to testbench. Revise tst_applicationwindow Set baselineOffset on Styles/Base correctly TableView: Make model property consistent with ListView * qtsensors 2b67b50...0a27445 (1): Update QML plug-in interfaces for Qt 5.3 release Someone, please take a look indicate me when fix is available Br, Jani ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
