Re: [Development] Setting up time-based releases for the project
On Tue, 7 Aug 2012 18:59:28 Abecasis Joao wrote: On 7. aug. 2012, at 02:45, Alan Alpert wrote: On Mon, 6 Aug 2012 22:13:30 ext joao.abeca...@nokia.com wrote: Fire-hose is a development branch, things may be variously broken at all times. Typically, developers in this mailing list will be tracking that branch. Leaky-faucet is deemed beta quality and somewhat more stable. At the very least it shouldn't break as often. We can expect that more people will be willing to track this branch with their own development. This is the part that I don't quite understand. This makes it sound like Fire- hose is the branch for destabilizing changes. Particularly destabilizing change sets are of course in their own branch, but the large numbers of normally destabilizing changes will make fire-hose mere Alpha quality at best. But then Thiago's email then said that fire-hose should be 'always ready for beta', which seems contradictory. Given that these are all common shared branches they should not be getting half-baked features in. For small features it's feasible to allow that they'll be built incrementally over a couple of commits. Anything beyond that is a good candidate for feature development in a separate branch. These should only hit the shared branch when they are ready for prime-time, admittedly this is also when those features get wider exposure and more issues are found. When you mention destabilizing changes the truth is most of the time we don't know which ones those are. Here, we try to increase stability by limiting the type of changes that go into each branch: only regressions should be fixed in the leaky-faucet branch, which is similar to the patch release policy we tried to keep in the past. Bug fixes and regressions, I presume you mean. The fact that we build up a predictable release schedule means there is less pressure to rush changes in. You know exactly when your feature will make it to a release, as long as you get it in good shape and into fire-hose. As I interpret it, the bump in quality comes from merging fire-hose to leaky- faucet some time before the release. Unfortunately, I didn't get any extra detail when I zoomed in on your ascii art. Here's my zoomed in version of the diagram: --+- fire-hose \ --+-+--- leaky-faucet \ +--+ dripping-bucket \ 5.1.0 ~2 Months |-| That's not the zoomed version, and you don't need it. Admittedly the original graph had a bug by showing '+' on both sides of the merge, where only the destination should have them. Here's a fixed, stripped down (non-zoomed) version: fire-hose \ ---+ leaky-faucet \\\\ --++++-- dripping-bucket \\\\ 5.1.05.1.15.1.25.2.0 (does it help?) Notice how merges coming from the branch above happen after a merge to the branch below. This gives a lower bound of 4 months for a change to make it from fire-hose to a release and an upper bound of 10 months, depending on when the change gets into fire-hose to begin with. Let me try again then, zoomed-in on the 5.1.1 section. Because reading ascii art just doesn't seem to be my specialty. fire-hose | --+- leaky-faucet | +--- dripping-bucket \ 5.1.1 ~2 Minutes |-| So the 5.1.1 release is tagged before leaky-faucet merges to beging 5.1.2, and that merge happens before fire-hose merges into leaky-faucet? And that merge from fire-hose - leaky-faucet around the time of the 5.1.1 release doesn't reach dripping-bucket until the 5.2.0 release? If so, I might finally have figured it out. Note that we also seem to disagree on the time scale, but that's what '~' is for ;) . Am I correct in assuming that merging fire-hose to leaky-faucet drops the quality of leaky-faucet to whatever fire-hose may be, and then developer focus shifts to leaky-faucet for stabilization (while destabilizing elements continue to flow rapidly into fire-hose for the next release)? How much lead time do we allocate per release? And what happens if we slip, because we couldn't get it to beta quality in time? The goal here is to get to strict time-based releases, which means we don't slip the schedule. If we make a lower quality 5.x.0 release, quality will improve for the 5.x.1 and 5.x.2 releases. This is all assuming we *want* to have a minor release out every 6 months. If we
[Development] Proposing Orgad Shaneh for Approver status
Hello Everyone, I am hereby proposing Orgad as an approver for Qt project. As anybody active on Qt Creator will already know, Orgad is helping a lot with bug reports, feature requests, many bug fixes all over the code base, new feature (e.g. in the version management area and other places) as well as lots of code reviews. Please check his gerrit dashboard https://codereview.qt-project.org/#dashboard,1000534 for an overview of his work. You might also want to check any of the over 300 high quality bug reports he created in JIRA, many of which he followed up with patches. Best Regards, Tobias Tobias Hunger Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Two bugs in the QIcon which broke my life.
On Wednesday, August 08, 2012 10:35:15 André Somers wrote: Op 8-8-2012 10:30, Stephen Kelly schreef: On Wednesday, August 08, 2012 12:03:34 ? ??? wrote: In the QIcon/QIconLoader there are 2 old bugs with patches. - https://bugreports.qt-project.org/browse/QTBUG-17953 - https://bugreports.qt-project.org/browse/QTBUG-12874 Fixes are trivial, and are available for many years. Merging of them will take only an hour. You need to submit patches to Qt through gerrit. Patches attached in JIRA can't be applied. Note also that patches have to be applied to Qt 5 first and unit tested. Nice, but these patches were submitted way before Gerrit was available. Are you saying we should just disgard any fixes that can be found in JIRA? They are not covered by the CLA. Whether they are 'trivial' enough to 'not be copyrightable' isn't for me to decide. I didn't look at them. Even when gerrit was not available, gitorious was available for all the time that JIRA was available. JIRA has never been 'the way to submit patches'. 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] Proposing Orgad Shaneh for Approver status
Tobias wrote: Hello Everyone, I am hereby proposing Orgad as an approver for Qt project. As anybody active on Qt Creator will already know, Orgad is helping a lot with bug reports, feature requests, many bug fixes all over the code base, new feature (e.g. in the version management area and other places) as well as lots of code reviews. Seconded. [Obviously...] Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Two bugs in the QIcon which broke my life.
On 08/08/2012 04:12, ext André Somers wrote: Op 8-8-2012 10:49, Stephen Kelly schreef: On Wednesday, August 08, 2012 10:35:15 André Somers wrote: Op 8-8-2012 10:30, Stephen Kelly schreef: On Wednesday, August 08, 2012 12:03:34 ? ??? wrote: In the QIcon/QIconLoader there are 2 old bugs with patches. - https://bugreports.qt-project.org/browse/QTBUG-17953 - https://bugreports.qt-project.org/browse/QTBUG-12874 Fixes are trivial, and are available for many years. Merging of them will take only an hour. You need to submit patches to Qt through gerrit. Patches attached in JIRA can't be applied. Note also that patches have to be applied to Qt 5 first and unit tested. Nice, but these patches were submitted way before Gerrit was available. Are you saying we should just disgard any fixes that can be found in JIRA? They are not covered by the CLA. Are you sure about that? Yes, Stephen is correct, the CLA covers only patches which has been submitted through Codereview.qt-project.org, so patches in Jira/Wiki/email cannot be applied. Even if the author gives you copyright to submit it to codereview as yourself (which is not allowed in many countries), _you_ would then be personally responsible for granting the license to use any patents his/her code might be infringing on. So, *don't* do that. Only submit code you have written yourself and where you can stand by the implementation. Whether they are 'trivial' enough to 'not be copyrightable' isn't for me to decide. I didn't look at them. Even when gerrit was not available, gitorious was available for all the time that JIRA was available. JIRA has never been 'the way to submit patches'. One of these had a MR on gitorious, actually. That got closed some time later because Gerrit got introduced in the meantime. So, I bet the contributor signed the agreement. I guess the submitter did not want to jump through the hoops again, in the hope that this time his patch *would* get accepted. A codereview can be done without using Gerrit of course, through email, IRC or any other means which reaches the author. However, the CLA has changed in several points since the Gitorious MR days (to the better, after discussions with multiple parties active on codereview today). This means that the old patches which were stuck or hadn't passed through the Gitorious MR system before we switched will need to be submitted again under the new terms. Frankly, the hurdle for doing so is not big, and if you have agreed to the terms before, I'm sure the new term as just as good as the previous ones. To reiterate what Stephen said, please submit patches through http://codereview.qt-project.org, it's the only way we can properly apply them. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Two bugs in the QIcon which broke my life.
On Wed, Aug 8, 2012 at 12:43 PM, marius.storm-ol...@nokia.com wrote: On 08/08/2012 04:12, ext André Somers wrote: Op 8-8-2012 10:49, Stephen Kelly schreef: On Wednesday, August 08, 2012 10:35:15 André Somers wrote: Op 8-8-2012 10:30, Stephen Kelly schreef: On Wednesday, August 08, 2012 12:03:34 ? ??? wrote: In the QIcon/QIconLoader there are 2 old bugs with patches. - https://bugreports.qt-project.org/browse/QTBUG-17953 - https://bugreports.qt-project.org/browse/QTBUG-12874 Fixes are trivial, and are available for many years. Merging of them will take only an hour. You need to submit patches to Qt through gerrit. Patches attached in JIRA can't be applied. Note also that patches have to be applied to Qt 5 first and unit tested. Nice, but these patches were submitted way before Gerrit was available. Are you saying we should just disgard any fixes that can be found in JIRA? They are not covered by the CLA. Are you sure about that? Yes, Stephen is correct, the CLA covers only patches which has been submitted through Codereview.qt-project.org, so patches in Jira/Wiki/email cannot be applied. Even if the author gives you copyright to submit it to codereview as yourself (which is not allowed in many countries), _you_ would then be personally responsible for granting the license to use any patents his/her code might be infringing on. So, *don't* do that. Only submit code you have written yourself and where you can stand by the implementation. Whether they are 'trivial' enough to 'not be copyrightable' isn't for me to decide. I didn't look at them. Even when gerrit was not available, gitorious was available for all the time that JIRA was available. JIRA has never been 'the way to submit patches'. One of these had a MR on gitorious, actually. That got closed some time later because Gerrit got introduced in the meantime. So, I bet the contributor signed the agreement. I guess the submitter did not want to jump through the hoops again, in the hope that this time his patch *would* get accepted. A codereview can be done without using Gerrit of course, through email, IRC or any other means which reaches the author. However, the CLA has changed in several points since the Gitorious MR days (to the better, after discussions with multiple parties active on codereview today). This means that the old patches which were stuck or hadn't passed through the Gitorious MR system before we switched will need to be submitted again under the new terms. Frankly, the hurdle for doing so is not big, and if you have agreed to the terms before, I'm sure the new term as just as good as the previous ones. To reiterate what Stephen said, please submit patches through http://codereview.qt-project.org, it's the only way we can properly apply them. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development As for the second bug report (https://bugreports.qt-project.org/browse/QTBUG-12874) shouldn't the standard icon paths be defined in the new class QStandardPaths? Then QIcon can use QStandardPaths to find icons - obviously. Right now i don't see any icon related thing in http://doc-snapshot.qt-project.org/5.0/qstandardpaths.html Since the icon stuff is defined by freedesktop (http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout) it might as well be added in there. Adding David Faure to the cc since he invented QStandardPaths. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposed solution to the ICU problem
Yes. We don't want to continue or begin to carry our own Unicode data, CLDR and timezone database. ICU provides all of that. So, does this mean I should abandon my QUnicode* and QText* changes/branches? Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Orgad Shaneh for Approver status
On 8 Aug 2012, at 10:46, ext tobias.hun...@nokia.com wrote: Hello Everyone, I am hereby proposing Orgad as an approver for Qt project. [...] +2 -- Eike Ziller Principal Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: Two bugs in the QIcon which broke my life.
If I understand you correctly, you propose to move the paths from QIcon::themeSearchPaths to QStandardPaths. /usr/share/pixmaps differs from the dirs with the icon themes. Theme directory contain the structure like: 1_theme_name |--actions ||--16 ||--22 ||--32 |--apps ||--16 ||--22 ||--32 ... But /usr/share/pixmaps just dump of the images, without any subdirs. So we should to process it other way. 2012/8/8 Mark mark...@gmail.com On Wed, Aug 8, 2012 at 12:43 PM, marius.storm-ol...@nokia.com wrote: On 08/08/2012 04:12, ext André Somers wrote: Op 8-8-2012 10:49, Stephen Kelly schreef: On Wednesday, August 08, 2012 10:35:15 André Somers wrote: Op 8-8-2012 10:30, Stephen Kelly schreef: On Wednesday, August 08, 2012 12:03:34 ? ??? wrote: In the QIcon/QIconLoader there are 2 old bugs with patches. - https://bugreports.qt-project.org/browse/QTBUG-17953 - https://bugreports.qt-project.org/browse/QTBUG-12874 Fixes are trivial, and are available for many years. Merging of them will take only an hour. You need to submit patches to Qt through gerrit. Patches attached in JIRA can't be applied. Note also that patches have to be applied to Qt 5 first and unit tested. Nice, but these patches were submitted way before Gerrit was available. Are you saying we should just disgard any fixes that can be found in JIRA? They are not covered by the CLA. Are you sure about that? Yes, Stephen is correct, the CLA covers only patches which has been submitted through Codereview.qt-project.org, so patches in Jira/Wiki/email cannot be applied. Even if the author gives you copyright to submit it to codereview as yourself (which is not allowed in many countries), _you_ would then be personally responsible for granting the license to use any patents his/her code might be infringing on. So, *don't* do that. Only submit code you have written yourself and where you can stand by the implementation. Whether they are 'trivial' enough to 'not be copyrightable' isn't for me to decide. I didn't look at them. Even when gerrit was not available, gitorious was available for all the time that JIRA was available. JIRA has never been 'the way to submit patches'. One of these had a MR on gitorious, actually. That got closed some time later because Gerrit got introduced in the meantime. So, I bet the contributor signed the agreement. I guess the submitter did not want to jump through the hoops again, in the hope that this time his patch *would* get accepted. A codereview can be done without using Gerrit of course, through email, IRC or any other means which reaches the author. However, the CLA has changed in several points since the Gitorious MR days (to the better, after discussions with multiple parties active on codereview today). This means that the old patches which were stuck or hadn't passed through the Gitorious MR system before we switched will need to be submitted again under the new terms. Frankly, the hurdle for doing so is not big, and if you have agreed to the terms before, I'm sure the new term as just as good as the previous ones. To reiterate what Stephen said, please submit patches through http://codereview.qt-project.org, it's the only way we can properly apply them. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development As for the second bug report (https://bugreports.qt-project.org/browse/QTBUG-12874) shouldn't the standard icon paths be defined in the new class QStandardPaths? Then QIcon can use QStandardPaths to find icons - obviously. Right now i don't see any icon related thing in http://doc-snapshot.qt-project.org/5.0/qstandardpaths.html Since the icon stuff is defined by freedesktop ( http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout ) it might as well be added in there. Adding David Faure to the cc since he invented QStandardPaths. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Best regards, Alexander. -- Best regards, Alexander. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposed solution to the ICU problem
On Aug 8, 2012, at 2:35 PM, ext Konstantin Ritt ritt...@gmail.com wrote: Yes. We don't want to continue or begin to carry our own Unicode data, CLDR and timezone database. ICU provides all of that. So, does this mean I should abandon my QUnicode* and QText* changes/branches? Depends on what they do. I e.g. do not see a lot of value in us maintaining our own copy of the CLDR data. For basic Unicode data that we need to render text, it might however make sense to keep a copy if this makes a big enough difference in performance. Let's just go through things and decide together where to best use ICU and where it makes sense to do our own stuff. But I'd like to see a decent justification for the places we want to keep our own data and/or implementation. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] sslErrors signal in qnetworkaccessmanager.cpp (Qt5, WebKit2)
Hi Guys, I was debugging a QML API failure in qtwebkit. The top level idea of the problem is this API is not working because QtNetworkAccessManager::onSslErrors function in a custom class derived from QNetworkAccessManager API is not getting triggered. This is connected to sslErrors of QNetworkAccessManager via connect(this, SIGNAL(sslErrors(QNetworkReply*, QListQSslError)), SLOT(onSslErrors(QNetworkReply*, QListQSslError))); in QtNetworkAccessManager constructor. So, i observed that sslErrors is not getting generated even though i am feeding a suitable url( https://lists.webkit.org/pipermail/webkit-changes/attachments/20111212/2e204be9/attachment.html) to generate sllErrors signal of QNetworkAccessManager. I figured out from qnetworkaccessmanager.cpp that sslErros signal will get emitted in function void QNetworkAccessManagerPrivate::_q_replySslErrors(const QListQSslError errors). But in the same file i see that _q_replySslErrors is connected to sslErros via q-connect(reply, SIGNAL(sslErrors(QListQSslError)), SLOT(_q_replySslErrors(QListQSslError))); I have two questions here. 1. SInce sslErros depend on _q_replySslErrors and _q_replySslErrors depends on sslErrors i dont understand who will be triggered first and how? 2. If sslErrors signal does'nt get generated it cant trigger onSslErrors(in WEBKIT), how to check if sslErrors signal is getting generated or not? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting up time-based releases for the project
I just put it here GNOME#Past_releases http://en.wikipedia.org/wiki/GNOME#Past_releases List_of_Ubuntu_releases#Table_of_versions http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Table_of_versions Ubuntu (and other distros) maintainers should have at least one month, i guess. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
