Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available
On 19.02.2013 20:29, Turunen Tuukka wrote: We have the packages ready and tested with minor fixes compared to RC1 (21st Dec). If we re-do these packages it is a significant effort with very limited benefits. It seems to me this already happens before: you first do the packaging and then ask on the list for a go. I would say this is the wrong order, you should first coordinate with the qt-project and then invest Digia's time. This mainly saves YOUR time and budget. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] : Test Application Failing to load QtCore Lib of qt-4.8.4 Event Dispatcher Assertion
Thanks Thiago and Peter for your suggestions. I am trying to debug the cause for assertion. @Peter : Yes I have compiled the Qt on Windows with the required configuration. Regards, Amogh. On Thu, Feb 21, 2013 at 1:15 PM, Peter Kümmel syntheti...@gmx.net wrote: On 21.02.2013 06:04, Amogh Kudari wrote: Hi All, Any idea on how to proceed to remove this assertion mentioned below. Please provide any inputs/suggestions. Thanks and Regards, Amogh. I've tested your program on Windows with msvc12 and wit the 4.8 branch. It starts here without problems. Only when quitting an assert is triggered because of the widgets are created on stack. Have you compiled Qt yourself? Peter ___ 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 4.6.5 and 4.7.6 release candidates available
On 21.2.2013 10.07, Peter Kümmel syntheti...@gmx.net wrote: On 19.02.2013 20:29, Turunen Tuukka wrote: We have the packages ready and tested with minor fixes compared to RC1 (21st Dec). If we re-do these packages it is a significant effort with very limited benefits. It seems to me this already happens before: you first do the packaging and then ask on the list for a go. I would say this is the wrong order, you should first coordinate with the qt-project and then invest Digia's time. This mainly saves YOUR time and budget. This is incorrect assumption as we have discussed this before making the RC1 - it just took a lot of time due to other release creation activities to continue the releasing work, so it seems that some persons (at least Thiago) just noticed it now when we are making RC2. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available
The original talk in Dec, 2012: http://lists.qt-project.org/pipermail/releasing/2012-December/000930.html Maybe not many people have noticed it. In my own opinion, they are from 4.7-digia and 4.6-digia branch, better name the packages like that. Otherwise, need to merge them to upstream at first. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available
Long emails and good discussion. It would have been great to have this in December, but better late than never. To summarize, here is the situation up until now: - Digia did 4.6.4 and 4.7.5 releases for the needs of the commercial customers - Digia did similar releases for LGPL - These were not accepted for distribution at the time (by Nokia) - Source code is available in gitorious: http://qt.gitorious.org/qt/digia-qt/commits/4.7.5 and http://qt.gitorious.org/qt/digia-qt/commits/4.6.4 - Content is all in the Qt Project, releases contain fixes cherry picked from e.g. 4.8 branch - Unfortunately the releases have not been part of the official 4.6 and 4.7 branches In order to have these 'unforked' - at least to the extent practical. I would like to have 4.6.5 and 4.7.6 done in the way proposed (and for my viewpoint agreed) in December. These release packages contain a few security fixes as well as correct copyrights. They are created based on 4.6.4 and 4.7.5. It may be that some other way to make these is better, but these are now available, binary installers work fine, we have not found any regressions and so forth. World does not end if we do not make these official. All the commercial customers have already had these for a long time and main focus in all development is in Qt 5 and 4.8. All the work we are now doing is very well aligned with what we have agreed together. I see two alternatives and I am fine with either of these - whatever we together think is best: 1. Release the packages as proposed with the content frozen in December (i.e. same as RC1, but with a few minor fixes in packaging) and have them available as branches of the official branches Or 2. Not to release the packages and remove current 4.6 and 4.7 packages from distribution and place to the archive. All the packages actively distributed should have correct copyrights. Unfortunately we do not have unlimited resources in the release team, so pointlessly redoing the packages is not something I want to do. Yours, -- Tuukka Turunen Director, RD Digia, Qt Address: Piippukatu 11, 40100 Jyväskylä, FINLAND Email: tuukka.turu...@digia.com Mobile: + 358 40 7655 800 Qt Website: http://qt.digia.com Qt Blog: http://blog.qt.digia.com Qt Project: http://www.qt-project.org -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. -- On 21.2.2013 2.34, Thiago Macieira thiago.macie...@intel.com wrote: On quarta-feira, 20 de fevereiro de 2013 21.03.10, Turunen Tuukka wrote: I understand how the previous releases were done, but I disagree on the plan. I want the changes in the 4.7 branch released and I don't want the changes in the 4.7-digia branch released unless the rest of the Qt Project is given the opportunity to review them. These are all already reviewed as the items are from 4.7 or 4.8 branch. There is no new functionality and we are not proposing to sneak in something. To our knowledge e.g. 4.7.5 has been used quite much by the LGPL users, and from that perspective 4.7.6 is a natural addition. There is no Qt 4.7.5, so open source users have not used it. If it was released as Open Source, please upload it to ftp.qt-project.org and upload the tag to qt.git. That settles the matter of the next version number. The problem is that some of the backports from 4.8 were not approved by the Qt Project. Those are the ones I want to review and allow others to do the same. They were submitted to 4.8 (not 4.7) for a reason. As said before this does not represent the way branches should be handled, but in these circumstances it is seen as the best approach - especially since everything is ready and tested now - we just need to release packages and make sure right branch is found. We have the packages ready and tested with minor fixes compared to RC1 (21st Dec). If we re-do these packages it is a significant effort with very limited benefits. Sorry, the current packages are a complete no-go. They need to be recreated anyway, since they're missing the shmget security fix. As the shmget security fix changes behavior and its risk rating, I would not like to put it into these. Well, the security team reviewed the fix and approved its release. Any security fix should be included in releases made after the fix is provided. So I don't think you can make that call and the fix must be
Re: [Development] Android: Merge or no merge?
On Mon, Feb 11, 2013 at 05:15:45PM +0100, Eskil Abrahamsen Blomfeldt wrote: We have a disagreement on how to integrate the Android port into Qt which we need to get resolved. Here's the discussion: https://codereview.qt-project.org/#change,47480 tl;dr: Should we merge or rebase the Android branch when integrating it into Qt mainline? [...] 1. The initial commit does not have a review-stamp. that's not the problem. that's not even *a* problem. the problem is that this commit would never have gotten an approval - for very good reasons. 2. There is clutter in the commit log, i.e. changes that change code style and whitespace errors. yes, they do. big time. but that's not even the problem. the problem are the dozens of workarounds and other hacks, that were later amended, sometimes multiple times, and finally reverted. this mess will stay in the history. it doesn't matter how much you optimize blame - every other way of browsing the history (specifically, my favorite (because very efficient) git log -p) is messed up. In my opinion, the amount of history we submit seems like a luxury problem. no. it is a problem of longer-term workflow optimization. I would very much like to be able to track the development of the Android branch after merging it, so in my opinion having the history intact is nice, even if they are not interesting to everyone. i postulate that this proposition is wrong. it's simply not true that more history is better. the main information you want to get out of the history is why something was done in a particular way. somewhat secondary is the question when something came in. for neither of these questions the actual history is relevant, if what ends up in the mainline satisfies the requirements of the commit policy: atomicity and good commit messages, including documenting non-obvious decisions. everything else is just noise. One of the major history-based problems in the Qt 4 days was that we would squash together commits from topic branches and lose the history in those branches. yes, this is a terrible practice, indeed. fortunately, this is not what re-shaping the history would be about. Squashing the clutter commits and rewriting the entire history is a lot of work, yes, it is. however, it is not *that* much work. and I fear it will jeopardize our chances of meeting the Qt 5.1 deadline. ah, yeah, there it is: we have a deadline to meet. let's ignore good practice! A compromise would be to rebase on top of dev, review the initial commit, and then rebase the rest of the branch on top of this. This would break the references in Jira tasks, though, so personally I'd prefer not to do this. i postulate that this is mostly irrelevant: - it is possible to backup the branch, say refs/dead-heads/android. this way all external references would stay valid, even if these commits were not part of the regular git history. note also that the commits are kept alive in gerrit by all the reviews which were done on top of them. - many of the jira tasks refer to issues with the initial code drop. iow, these tasks are merely part of the review process, and have no long-term value. they shouldn't have existed in the first place - under normal circumstances it would have all happened on gerrit. - for real tasks, it would be possible to automatically fix up the jira references to the rebased sha1s. I also wonder how it's achieved technically, with a forced direct push. i just did that to the winrt branch upon request. it was a remarkably painless experience. a reasonably efficient process which would lead to a clean history (which includes a proper review of every commit on its own merits, rather than improving from the original code drop) would look like that: - first squash all fixup commits and reverts which were done in the branch - it is possible to record the change-ids of the fixups in this commit to make absolutely sure that the real history can be easily tracked. however, for many (if not most) of these commits this doesn't really make sense. - then rebase on top of dev. this eliminates a bunch of commits and shrinks others. - chop up the initial commit into atomic parts: general portability improvements and generalizations, buildsystem enhancements, then the addition of the java module and the specific porting work. - submit the extracted groundwork directly for dev, as eskil has already done to some degree. this gets the full incremental review and CI-testing, and ensures that we get no diverging solutions for the same problems (cf., the concurrent ios port). - rebase again. what is left now can be seen as a proper long-lived branch and can be actually merged, and possibly even continued *after* it has been merged the first time. i'll also point out that the winrt and ios branches are both following a history re-shaping approach. these ports are arguably smaller, and they have the big
Re: [Development] Android: Merge or no merge?
On 02/21/2013 02:16 PM, Oswald Buddenhagen wrote: and I fear it will jeopardize our chances of meeting the Qt 5.1 deadline. ah, yeah, there it is: we have a deadline to meet. let's ignore good practice! Yes, of course it is a trade-off. In this case, the negative effects of having a code drop with some amendments is outweighed by the positive effects of having usable SHA1s in Jira and of being able to focus the time of developers on more important issues. This does not mean that we would accept any compromise thinkable, but in this case either solution is a compromise. One favours time and history over cleanliness, while the other favours cleanliness. As far as I can gather from the attention this discussion is getting, having the code drop with amendments in the Android-specific parts of the code is not unacceptable to anyone but you, while having the history intact and work load focused is viewed as valuable by the people who are working on this. The history provides documentation of what has happened to the code, also of the mistakes that are made. The history in this case also documents why the code differs from the Necessitas project, which might also be useful to some people. As we've said earlier, we're hoping to do the merge this week, which means tomorrow. With the comments in this thread so far, I don't see any justification to delay it. -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android: Merge or no merge?
On 02/21/2013 04:54 PM, Oswald Buddenhagen wrote: i'll simply block the merge, and i don't even need to resort to my pet process reasons for that. Ok, we will delay the merge/rebase until Lars is back and can resolve this conflict. -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On 21 February 2013 02:16, Corentin Jabot corentin.ja...@gmail.com wrote:
Hi. I'm the one Olivier mentioned :p
I didn't have time to pursue further the work I started, but I intend
to, someday.
The plan, as suggested by thiago was to have a QThread::run(functor)
method acting exactly like QtConcurrent::run, but using a new QThead.
A similar QThreadPool::run function would call a functor in a thread
allocated in its pool.
I think the the plan is good; QtConcurrent::run() always felt
out-of-place with the filter-map-reduce API. We just need to be
mindful of how we integrate it into Qt -- the solution should cover
all 3 of functors, QRunnable, and parallel event loops.
I notice you also have QThread::run(QRunnable*). Let's take into
consideration the existing methods QThreadPool::start() and
QThreadPool::tryStart(). It's inconsistent to have:
QThread::run(QRunnable*)
QThreadPool::start(QRunnable*)
(Look for static polymorphism in
http://doc.qt.digia.com/qq/qq13-apis.html) I think we should either
make the new functions match the old names, or rename the old
functions to match the new names. (rename = create new names,
deprecate old names)
Those function return QFuture and do not require event loop so this
silly snippet work:
int main() {
auto future = QThread::run( []() { qDebug() Hello world ; } );
future.waitForFinished();
}
My goal was to make it as simple as I could.
Sounds good
Anyway, I don't think we should returns a QThread*. the underlying
implementation does not mater and shouldn't mater.
What would you do with a QThread* you can't do with a QFuture ?
Apologies, I didn't realize that you had a version that returns
QFuture; I only saw the one that returned void. (Line 115,
https://codereview.qt-project.org/#patch,sidebyside,45297,5,src/corelib/thread/qthread.h)
I think returning QThread* is better than void. I still can't decide
if QThread* or QFuture is better for these new methods, however.
Technically, returning a QThread does hide the implementation. The
programmer only sees the QThread, and doesn't know that you've
implemented a QRunnableThread underneath. The programmer already knows
about QThread (since s/he called QThread::run()), so getting a
QThread* won't be a big deal.
About QThread vs. QFuture... QThread:
- Lets the programmer postpone starting the thread
- Lets the programmer query and manipulate the thread using
event-driven programming (signals and slots)
On the other hand, QFuture makes it easy to retrieve the function's
return value.
I leaned towards returning QThread* because QtConcurrent::run()
couldn't use most of QFuture's features anyway, and QThread* can be
returned from all 3 static functions:
static QThread* QThread::setupSimpleThread(QRunnable *runnable);
static QThread* QThread::setupSimpleThread(Function func, Args arg, ...);
static QThread* QThread::setupEventLoop(QObject* worker);
...but I'm not sure if losing the functor's return value is worth it.
The Thread is started right-away, you can't really interrupt the
function until its done, etc but you could delete the thread while
it's running, so yeah, I'd rather not a return a pointer to the
thread.
I don't think we have to worry about people deleting the QThread while
it's running. If we did, we'd have similar problems the
QAudioInput::start() (returns a QIODevice*) and
QNetworkAccessManager::get() (returns a QNetworkReply*).
I find the signature QThread::run(function), quite straightforward,
there is no confusion about what it does.
I don't think the fact there is also the static void run() method is
confusing, but maybe that's just me.
I agree that, by itself, run() is a good name for this feature. The
issue, however, is that QThread already has something completely
different, also called run(). Thus, our choices become more limited.
I disagree that calling them all run() is non-confusing. It produces
an inconsistent API. Imagine that a new user finds a class with these
functions:
public static QFutureT run(QFunction);
public static void run(QRunnable*);
protected void run();
Will this new user be reasonably able to guess their differences?
That said, there is no real reason to put these functions in QThread,
except the name.
These functions could be put elsewhere, I actually started to work
with a bunch of free functions before integrated them to QThread
I think we should try to keep it inside QThread if possible; creating
another class/namespace feels excessive
The implementation use the same sort of generator that QtConcurrent.
Thiago suggested making this feature only compatible C++11, which
would make it easier to maintain. I actually envisaged to send a mail
about that particular issue.
Can c++03 really be dropped for that particular feature ?
Also, I we were to make a c++11 only feature, what would be the
benefits over std::async ?
I would love to see an implementation using C++11. I think that
Re: [Development] Evolving Qt's multithreading API
On 21 February 2013 02:31, Ing. Reynier Pupo Gómez rgo...@uci.cu wrote: What about using of OpenMP standard? It could be very usefull and well known by the C/C++ comunity. Thanks for the suggestion. I had a quick look, but it seems to be on the low-level side. I'm not sure if we want to use #pragmas for regular code... Have you had experience with it? Is it easy to use? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On Friday 22 February 2013 00:07:28 Sze Howe Koh wrote:
On 21 February 2013 02:16, Corentin Jabot corentin.ja...@gmail.com wrote:
Hi. I'm the one Olivier mentioned :p
I didn't have time to pursue further the work I started, but I intend
to, someday.
The plan, as suggested by thiago was to have a QThread::run(functor)
method acting exactly like QtConcurrent::run, but using a new QThead.
A similar QThreadPool::run function would call a functor in a thread
allocated in its pool.
I think the the plan is good; QtConcurrent::run() always felt
out-of-place with the filter-map-reduce API. We just need to be
mindful of how we integrate it into Qt -- the solution should cover
all 3 of functors, QRunnable, and parallel event loops.
I notice you also have QThread::run(QRunnable*). Let's take into
consideration the existing methods QThreadPool::start() and
QThreadPool::tryStart(). It's inconsistent to have:
QThread::run(QRunnable*)
QThreadPool::start(QRunnable*)
(Look for static polymorphism in
http://doc.qt.digia.com/qq/qq13-apis.html) I think we should either
make the new functions match the old names, or rename the old
functions to match the new names. (rename = create new names,
deprecate old names)
Yes. We need to find good APIs.
Those function return QFuture and do not require event loop so this
silly snippet work:
int main() {
auto future = QThread::run( []() { qDebug() Hello world ; } );
future.waitForFinished();
}
My goal was to make it as simple as I could.
Sounds good
Anyway, I don't think we should returns a QThread*. the underlying
implementation does not mater and shouldn't mater.
What would you do with a QThread* you can't do with a QFuture ?
Apologies, I didn't realize that you had a version that returns
QFuture; I only saw the one that returned void. (Line 115,
https://codereview.qt-project.org/#patch,sidebyside,45297,5,src/corelib/thre
ad/qthread.h) I think returning QThread* is better than void. I still can't
decide if QThread* or QFuture is better for these new methods, however.
This has uses case, but i'm not sure it is the main use case.
Some more common use case would be (pseudo-code)
auto watcher = new QFutureWatcher;
QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff()));
watcher-setFuture(QThrerad::run([]() { return computeStuff(); } ));
// who deletes the watcher?
I think this pattern should be made easier
Something like:
QObject::connect(
QThread::runFunction([]() { return doSomethingComplicated(); }),
QThread::finished,
this,
MyObject::doStuff //cannot use lambda here because we want a
// QueuedConnection
);
Technically, returning a QThread does hide the implementation. The
programmer only sees the QThread, and doesn't know that you've
implemented a QRunnableThread underneath. The programmer already knows
about QThread (since s/he called QThread::run()), so getting a
QThread* won't be a big deal.
About QThread vs. QFuture... QThread:
- Lets the programmer postpone starting the thread
- Lets the programmer query and manipulate the thread using
event-driven programming (signals and slots)
On the other hand, QFuture makes it easy to retrieve the function's
return value.
I leaned towards returning QThread* because QtConcurrent::run()
couldn't use most of QFuture's features anyway, and QThread* can be
returned from all 3 static functions:
static QThread* QThread::setupSimpleThread(QRunnable *runnable);
static QThread* QThread::setupSimpleThread(Function func, Args arg,
...); static QThread* QThread::setupEventLoop(QObject* worker);
So then the caller is responsible on calling start() and also deleting the
thread ?
...but I'm not sure if losing the functor's return value is worth it.
The Thread is started right-away, you can't really interrupt the
function until its done, etc but you could delete the thread while
it's running, so yeah, I'd rather not a return a pointer to the
thread.
I don't think we have to worry about people deleting the QThread while
it's running. If we did, we'd have similar problems the
QAudioInput::start() (returns a QIODevice*) and
QNetworkAccessManager::get() (returns a QNetworkReply*).
I find the signature QThread::run(function), quite straightforward,
there is no confusion about what it does.
I don't think the fact there is also the static void run() method is
confusing, but maybe that's just me.
I agree that, by itself, run() is a good name for this feature. The
issue, however, is that QThread already has something completely
different, also called run(). Thus, our choices become more limited.
I disagree that calling them all run() is non-confusing. It produces
an inconsistent API. Imagine that a new user finds a class with these
functions:
public static QFutureT
Re: [Development] Android: Merge or no merge?
On Thursday, February 21, 2013 14:50:26 Eskil Abrahamsen Blomfeldt wrote: As far as I can gather from the attention this discussion is getting, having the code drop with amendments in the Android-specific parts of the code is not unacceptable to anyone but you, while having the history intact and work load focused is viewed as valuable by the people who are working on this. As a data point, I fully agree with everything ossi wrote. I didn't speak up before because I have already given up on several aspects of 'doing things right' in the QtProject. It's just too easy to do things wrong/lazily and then claim it is too late to fix (then repeat the next time lazy is faster than right). Why would you listen to me? What difference could it make? I can't block a merge. You already demonstrated your greater permissions on the repo when you direct-pushed the initial android commit. That surprised me greatly. Having useful and relevant history is important. Having messy history, which does nothing but preserve mistakes people made, style fixes and reverts (which are ordinarily caught at review-time) is not useful. Large commits where the the commit message is useless and the commit so large that nothing of relevance can be seen is also not useful or important history. I tried browsing the branch with gitk --first-parent, and noticed commit ae468e5cadc18189ba6d5e6716a1f3e37e118a7a 'Merge branch 'wip/android' into dev', but it doesn't appear to be on the dev branch. After that --first-parent is showing the wrong stuff. Any idea what's going on there? Was it a merge that you did locally into dev and then pushed as the new android branch? I notice this repeats in all other merges, which breaks --first-parent very effectively. The commit f42766c12b66450d6afe95e1256ec514fbeb28dc 'Compile fix when QT_NO_PRINTDIALOG is defined' obviously belongs on the stable branch, not the android branch. The commit 63ac2d3c32750c498fb10de8803f553c58d1e710 'Export QAbstractFileEngine[] classes.' is quite surprising and also belongs on the dev branch, not on the android branch. I also had a quick look at the commit 7f4a5e98ab6d146d46e4c40d17de9c725bb7bcef 'Say hello to Android.' Adding the 'assets' url scheme handling is deserving of a commit on its own at least (in dev). I have no idea how much of the branch made sense in necessitas/the branch, but was obsolete by the time of the merge (like https://codereview.qt-project.org/#change,46802 ). I can imagine that many of us who try to make use of repo history in the future will end up on that branch, and it won't be much fun, but we won't be able to do anything about it. It disapponts me that we'll have such a crap ball of history so recently in the repo if you merge as planned, but I don't feel that I can stop it. If ossi can and has the patience to try to explain the importance of good history, then more power to him :). 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] Qt 4.6.5 and 4.7.6 release candidates available
On quinta-feira, 21 de fevereiro de 2013 13.00.50, Turunen Tuukka wrote: - Digia did 4.6.4 and 4.7.5 releases for the needs of the commercial customers - Digia did similar releases for LGPL - These were not accepted for distribution at the time (by Nokia) - Source code is available in gitorious: http://qt.gitorious.org/qt/digia-qt/commits/4.7.5 and http://qt.gitorious.org/qt/digia-qt/commits/4.6.4 - Content is all in the Qt Project, releases contain fixes cherry picked from e.g. 4.8 branch - Unfortunately the releases have not been part of the official 4.6 and 4.7 branches In order to have these 'unforked' - at least to the extent practical. I would like to have 4.6.5 and 4.7.6 done in the way proposed (and for my viewpoint agreed) in December. These release packages contain a few security fixes as well as correct copyrights. They are created based on 4.6.4 and 4.7.5. It may be that some other way to make these is better, but these are now available, binary installers work fine, we have not found any regressions and so forth. Thanks for the summary, Tuukka. I personally agree that we should unfork and I'm inclined to believe everyone in the project wants that too. No one wants duplication of efforts and we all want what's best for our users. What we disagree on is how to achieve that goal. Git lists that the 4.x-digia branch has 141-145 commits in addition to the respective 4.x branch (in both cases). I don't want to give offence to the team that worked at Digia to prepare those releases, but I simply don't know who they are (all commits are by Qt Commercial Integration qtcommerc...@digia.com) and I do know that they did not have the benefit of talking to the people who today are approvers and maintainers. I can't even be sure that the backporting did not include a break of the backwards- and forwards-compatibility rule at this point. If the Qt Project is to approve those changes, we need a chance to review them. Because of the header changes, *every* *single* *file* shows up in the diff between those branches, so it's unreviewable. As unreviewable changes go, they are rejected at the outset. And then there's the shmget-fix question. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Qt 4.6.5 and 4.7.6 release candidates available
On quinta-feira, 21 de fevereiro de 2013 11.53.42, Turunen Tuukka wrote: On 21.2.2013 10.07, Peter Kümmel syntheti...@gmx.net wrote: On 19.02.2013 20:29, Turunen Tuukka wrote: We have the packages ready and tested with minor fixes compared to RC1 (21st Dec). If we re-do these packages it is a significant effort with very limited benefits. It seems to me this already happens before: you first do the packaging and then ask on the list for a go. I would say this is the wrong order, you should first coordinate with the qt-project and then invest Digia's time. This mainly saves YOUR time and budget. This is incorrect assumption as we have discussed this before making the RC1 - it just took a lot of time due to other release creation activities to continue the releasing work, so it seems that some persons (at least Thiago) just noticed it now when we are making RC2. I noticed the email and I was quite happy we were making new releases. I even referred to it when I wrote the shmget security fix announcement by looking at the version number we were preparing for 4.7. What I had not noticed was the actual *content* of the branch that the releases were coming from. It just seemed to me that the engineers were using a different repository to apply small fixes for the package creation (something we routinely do). It didn't occur to me to even think that the releases were not coming from the original branch, but instead from one with over 140 cherry-picked commits. That's what I'm objecting to now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Android: Merge or no merge?
On quinta-feira, 21 de fevereiro de 2013 16.54.09, Oswald Buddenhagen wrote: there is always something more important. that's not a free ticket to dump best practices. we have some people in the project who consistently think they can do it, and it shows in the quality of their code. Can you please send a link to the best practices of importing a third-party port? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Evolving Qt's multithreading API
On sexta-feira, 22 de fevereiro de 2013 00.15.19, Sze Howe Koh wrote: On 21 February 2013 02:31, Ing. Reynier Pupo Gómez rgo...@uci.cu wrote: What about using of OpenMP standard? It could be very usefull and well known by the C/C++ comunity. Thanks for the suggestion. I had a quick look, but it seems to be on the low-level side. I'm not sure if we want to use #pragmas for regular code... Have you had experience with it? Is it easy to use? OpenMP is completely out of scope. The most we can do is make Qt's own threading mechanisms work with OpenMP if the user wants to use it. But we can't dictate use of it because it requires compiler support. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Android: Merge or no merge?
On Thu, Feb 21, 2013 at 10:13:51AM -0800, Thiago Macieira wrote: On quinta-feira, 21 de fevereiro de 2013 16.54.09, Oswald Buddenhagen wrote: there is always something more important. that's not a free ticket to dump best practices. Can you please send a link to the best practices of importing a third-party port? this is a trick question (intended or not). it suggests that there is a (directly applicable) guide like that in the first place. also, it implies that we are actually importing a 3rd party work, which is simply not the case - the contributors are now active members of our community, and they are actively pushing their work under our CLA. there is absolutely no imperative to import necessitas verbatim, and therefore to deviate from the project's generally accepted best practices (or to be frank: policies). and as i already said, the merge of the qt creator part of necessitas proves this to be correct. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available
On 21.02.2013 14:00, Turunen Tuukka wrote: Unfortunately we do not have unlimited resources in the release team, so pointlessly redoing the packages is not something I want to do. I would release the already packaged versions as they are as a Digia-only release, and skip 4.8.5/4.7.6 in the official counting, like 4.7.5. Then we could start working on the qt-project version 4.8.6/4.7.7 without much pressure of time. Then we also have more time to discuss and adjust the processes on qt-project's and Digia's side (maybe the Qt Commercial Integration guys get more involved into the review process). There is still the announcement === This problem is solved in Qt 5.0.1 and the forthcoming 4.8.5, and the 4.7.6 patch releases. For other releases, apply the patch below: === But when qt-project never releases a 4.8.5/4.7.6 but 4.8.6/4.7.7 we still have released the fix with the next patch release, only the version number is different to the announced one. And nobody could use by accident a not security-fixed Qt version. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
