Re: [Development] HEADS UP: Qt 5.6.0 branching ongoing
Hi, As Jani explained in another mail, the fact that something does not block a release does not mean it's considered unimportant. We want to be as close as possible to a time-based release schedule, which means that if a new release does not regress and is an improvement to most users, it's better to get it out than to delay for everyone in order to get a bug fix in. As for priorities: P0 is for bugs that prevent further development of Qt and that need to be fixed right away. P1 is for crashes, regressions, security issues, memory corruption, bad drawing bugs, some build issues, etc. The highest priority we have for issues that do not fall into these categories is P2, so I think that's the appropriate priority for the bug in question since it's an inconvenience that you cannot debug on the simulator using Qt Creator. If you disagree with the priority set, you can discuss it with the assignee in the comment field of the bug report and explain why you believe the bug is more critical. It happens that the bug triaging team or assignee has underestimated a bug, so it's important to get input from the people affected by it. It's also possible to vote for bugs. That will usually be taken into account when people prioritize what they work on, since it's an indication of the number of users affected by the bug. -- Eskil From: Development on behalf of mark diener Sent: Tuesday, February 2, 2016 3:37 PM To: Heikkinen Jani Cc: development@qt-project.org Subject: Re: [Development] HEADS UP: Qt 5.6.0 branching ongoing Jani: I submitted a message a week ago about the blocker list criterion and could not find a QT FAQ on what are the critierion. For example: https://bugreports.qt.io/browse/QTBUG-50374 is NOT a blocker for 5.6.0 RC. It is P2: Important. Likely I am missing something about how the blocker list is constructed and interpreted. But should 5.6.0 release with QTBUG-50374 still present, Qt is effectively saying, we have cut back support for IOS. And that would be big news. Please educate me. md On Tue, Feb 2, 2016 at 6:51 AM, Heikkinen Jani wrote: > Hi, > > Final downmerge is now done and branching is complete. From now on '5.6' is > for Qt 5.6.1 and '5.6.0' for Qt 5.6.0. Staging in '5.6.0' is restricted and > we in the release team will stage needed changes in '5.6.0' from now on. We > will check approved changes automatically so no need for any special actions > from you; just take care that your changes will be approved. > > And please remember: We will take in only really important changes so please > don't add any nice-to-haves in '5.6.0' anymore! If we can live with issue in > Qt 5.6.0 then please use '5.6' instead. > > And as usual please send re-targeting request to Ossi if there is some change > open in '5.6' and which must be in Qt 5.6.0 > > br, > Jani > > > Lähettäjä: Heikkinen Jani > Lähetetty: 25. tammikuuta 2016 13:39 > Vastaanottaja: development@qt-project.org > Kopio: releas...@qt-project.org > Aihe: HEADS UP: Qt 5.6.0 branching ongoing > > ‘5.6.0’ branch is now available, please start using it for the changes > targeted to Qt5.6.0 release. > > We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be > enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All > new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on. > > Target is to release Qt5.6.0 RC quite soon so please make sure all blockers > will be fixed as soon as possible. Blocker list here: > https://bugreports.qt.io/issues/?filter=17225 > Please make sure all Qt 5.6.0 blockers are found from blocker list (== set > 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize > changes between RC and final. > > And please remember: Do not add any 'nice to have' -changes in anymore (P0 & > P1 bug fixes mostly, in some special cases p2 fixes might be ok as well). > > Best regards, > Jani Heikkinen > Release Manager | The Qt Company > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland > Email: jani.heikki...@theqtcompany.com | Mobile: + 358 50 48 73 735 > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, > @Qtproject Facebook: www.facebook.com/qt > > ___ > 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 release coming soon
Hi, Oops! That's supposed to be QTBUG-38256. Sorry about that! I see that Thiago has removed the bug ID from the changelog, which is good enough I think. Thanks for catching this :) -- Eskil Fra: development-bounces+eskil.abrahamsen-blomfeldt=theqtcompany@qt-project.org [mailto:development-bounces+eskil.abrahamsen-blomfeldt=theqtcompany@qt-project.org] På vegne av Adam Light Sendt: 27. november 2014 00:55 Til: Thiago Macieira Kopi: Emne: Re: [Development] Qt 5.4.0 release coming soon On Wed, Nov 26, 2014 at 2:26 PM, Thiago Macieira mailto:thiago.macie...@intel.com>> wrote: On Wednesday 26 November 2014 12:33:52 Adam Light wrote: > Where's the correct place to file a bug about a changelog entry being > incorrect? > > Specifically, the bug # in the following entry doesn't seem to have > anything to do with the changelog item: > > - [QTBUG-41192] Fixed menu item shortcuts without keyboard modifiers. Nowhere. Just tell us (me) what the correct one should be and we'll update the changelog. I have no idea what the correct bug is for that commit, only that the referenced bug does seem to have anything to do with menu item shortcuts. Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] WebView for Android on track for Qt 5.2?
Hi, So far there hasn't been much research on this, but the idea was to render it into a texture and use this in the QML scene graph, yes. Any experience you collect on this will probably be very helpful. I think the path forward may be to make an Android-specific API for this that can easily be adapted to a cross-platform API later. That gives us a bit more flexibility as we do not have to commit to a cross-platform API right away. I can't give any promises as for the Qt version this will be targeted at yet, but I do understand that it's a very important feature, so I definitely want to have it as soon as at all possible. Here's a blog which might be helpful if you're going to be looking at this: http://anuraagsridhar.wordpress.com/2013/03/13/rendering-an-android-webview-or-for-that-matter-any-android-view-directly-to-opengl/ -- Eskil -Opprinnelig melding- Fra: Cornelius Hald [mailto:h...@icandy.de] Sendt: 6. september 2013 16:15 Til: Abrahamsen-Blomfeldt Eskil Kopi: development@qt-project.org Emne: Re: [Development] WebView for Android on track for Qt 5.2? On Fri, 2013-09-06 at 10:41 +0200, Eskil Abrahamsen Blomfeldt wrote: > On 09/05/2013 06:18 PM, Cornelius Hald wrote: > > Hi guys, > > > > what is the state of WebView (QQ2) for Android? Is it still planed > > for Qt 5.2? Is there a branch to track somewhere? The bug report > > suggests that instead of using QtWebKit a wrapper around the > > Android-WebView is now planned. > > > > https://bugreports.qt-project.org/browse/QTBUG-32093 > > > > Anything I could help you with? > > Hi, > > I've talked to the team working on the web engine in Qt in Digia, and > right now there are no resources to do work on this in Digia > unfortunately. It might be possible to do something specifically for > Android, but it would be a lot nicer to have a cross-platform solution > like the web engine guys initially planned, and I think this is needed > for iOS as well. I'll talk to the iOS team here, but I don't think it > sounds feasible that this will be done in the one and a half weeks we > have left before the Qt 5.2 feature freeze. Sorry :( > > -- Eskil > Hi Eskil, thank you for your fast reply. Of course that wasn't the answer I was hoping for but at least I can be sure now. I have two projects running on Windows and Linux. Both I should port to Android as soon as possible. Are there any known workarounds? Like using the Android WebView and rendering it into a GL texture that could be used with QQ2? I only need output. No input or interaction. I will research my options but would be very grateful for any hints and tips. Also it would be great to know for what Qt version it is planned to have a working WebView on Android. Thanks! Conny ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android port - Why do we need Ministro?
Note that with some tweaking, it is already quite possible to build statically or bundle the libraries you want as part of your .apk if you're not worried about the library size. We probably won't make a out-of-the-box-solution for this for the Qt 5.1 release, since it just doesn't fit in the schedule, but I've tested it with both Necessitas and with Qt 5, and if you're comfortable with Java and the Android package system, it's not that hard. About protecting against unexpected behavior: I think this will be an issue anyway, since you're depending on several shared libraries in the platform in addition to Qt, and they can all be updated behind the app's back. So developers will have to test against changes in the underlying stack and maybe make their own updates if it turns out that they depended on buggy behavior. -- Eskil Fra: djsz...@archlinux.us [mailto:djsz...@archlinux.us] På vegne av Laszlo Papp Sendt: 11. januar 2013 20:14 Til: BogDan Kopi: Pau Garcia i Quiles; Abrahamsen-Blomfeldt Eskil; Felipe Crochik; development@qt-project.org Emne: Re: [Development] Android port - Why do we need Ministro? On Fri, Jan 11, 2013 at 6:52 PM, BogDan mailto:bog_dan...@yahoo.com>> wrote: I'll do a summary of them: - the most important is that qt libs are very big (Qt4 libs are +40Mb for one platform and most probably Qt5 will be more than that), if you want to target two platforms (armv5 and armv7) you need to bundle +80Mb of qt libs. Even more, if you want to use NEON for armv7 and VFP for armv5 you need to double that size. Ministro downloads the right libs for your platform only once. QtCore 4.8.4 is 2.9 MB for me. It does not look that bad if you need some core feature only. Besides, there is another point (perhaps mentioned in this thread already), you can make sure your application remains working against unexpected behavior and so forth changes we had unfortunate examples in the past. So, it is also a matter of ensuring the functionality of your application. In my opinion, this can be a valid concern for certain application developers. The convenient way for the end user would just be a plus in such a scenario. - android offers no way to install shared libs into its system libs folder, and there is no read/write location that application can use to store shared libs (obviously, for security reasons). Ministro solves this problem by using its own home folder as a central location for qt libs, where only Ministro has read/write permissions to these libs, the other app have only read-only permission, just like your linux desktop. - statically linking or bundling LGPL libs into your package comes with even more challenges than the package size, developers *MUST* provide a way to their users to repack the application with other Qt libs (please check LGPL license on this matter). I do not see the problem in there yet. It is replacable after repackaging or by direct overwrite if the platform security allows that with Harmattan for instance. That being said, I also agree about that Ministro can be a useful tool. Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android
Hi, I think there will have to be further discussion around this. Ministro was initially written to be a common-purpose library distribution, not exclusively used for Qt libraries. It would be like depending on "apt" or something like that. More discussion is needed to decide how to proceed with this, I think. However, regardless of the outcome there, I don't think there's any problem branding the technology which distributes and shares the libraries as "Ministro". What name is used for distributing the app in app stores can be unrelated to the name of the technology which is only used in the code. So, like Alan said, I don't think this issue has to be resolved before the code is integrated in the Qt Project. I think we need to make start off by making the binding-code for a Qt app generic enough that it can be configured to connect to a Ministro-based app with any name/app identifier. This way, we can do any necessary rebranding or other changes at a later stage when all opinions are heard. The idea from there is to try to make the Ministro-app in the app store owned by a Qt Project-user, but how this would work legally is currently a bit unclear. If it turns out it's impossible, then we might need to make Qt Creator's Android-plugin Ministro-app-agnostic, Digia will make a Digia-owned distribution of Qt which can be selected in Qt Creator, but also allow developers to connect to the current Ministro app or their own, custom distribution of Qt if they so wish. As for the name of the app: For the end-user of the app, I think it makes little difference whether the external app they have to download is called "Ministro" or "Qt". Either will most likely be a name they've never heard before. "Qt" might actually sound scarier to the average end-user than "Ministro" if you think about it :) If the app is exclusively used for Qt libraries, it should be named Qt, though, but if it's a general-purpose distribution mechanism, I think "Ministro" is a good name. I do think the main issue for many people will be the fact that you have to download a separate app to start the app you just downloaded, regardless of its name. I am worried that this will give developers an extra argument to use regular Android APIs for their app rather than Qt. Ideally, you should have to accept as few compromises as possible when using Qt for your app. -- Eskil -----Opprinnelig melding- Fra: Bache-Wiig Jens Sendt: 11. januar 2013 22:43 Til: Abrahamsen-Blomfeldt Eskil Kopi: development@qt-project.org Emne: Re: [Development] Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android > Hi, > > As part of the Android-port of Qt 5 being contributed to the Qt > Project by BogDan, he also contributed the code for a general-purpose > Android app which is used for getting libraries and plugins on demand > when a Qt app is deployed to an Android device. This tool is called > "Ministro". > > We need a repository to put it in, and the existing repositories do > not seem to fit, so I'm proposing making a new repository for this: > ministro/ministro I certainly don't mind adding the repository but I presume there will be a branding change once the Android port is made official. While "Neccessitas" and "Ministro" sounds cool, I think it would be better if we stop using those names officially and start to refer to them just as "Qt for Android" and "Qt Library Installer" or something similar and clear. I think people get a bit worried when they have to install something called "Ministro" on their phones. At least I was rather concerned the first time I installed a Qt app on my device and had to check twice. Perhaps we should name the repository accordingly? Regards, Jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
