Re: [Development] Expiring old change reviews
Torsdag 26. juni 2014 18.14.49 skrev Thiago Macieira: I've just counted: I have 203 pending reviews for me. At least half of them haven't been updated in six months. Some of them are for the old master and api_changes branches and will never, ever be accepted unless resubmitted. Last we discussed this, we were waiting for Gerrit to be updated. It has now. Can we please expire old stuff? Ossi is working on it, so it's going to happen soon. @everyone: This means for everyone that open changes in gerrit that were untouched for ages will be moved to abandoned, you can unabandon them if you think they are still relevant (just check your gerrit mail). Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: All Qt modules must use the same version number
On Thursday, June 26, 2014 08:38:01 Thiago Macieira wrote: Em qui 26 jun 2014, às 09:52:20, Stephen Kelly escreveu: Therefore the major version must stay the same until Qt 6. Why is it not acceptable? Because Lars did not accept it. Well, the solution is that you can rename the module altogether. Quick 1 and Quick 2. That includes the requirement to namespace or rename all symbols, executables, libraries and environment variables. We talked about this at QtCS. It was not accepted as a solution. Now see the use of 'accept.*' above. I guess this is a subject for when and if the situation happens again. Make that suggestion next time too. The enginio situation happened because it was not actually discussed. Thanks, -- Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any way to mark reviews as read in the new Gerrit?
On Thu, Jun 26, 2014 at 04:34:39PM -0700, Thiago Macieira wrote: The new one appears to[*] mark with bold anything that has had comments since the last time you commented or voted on. While that's nice to remind people to read, there's no way to mark it as read, short of posting a comment. I don't want to start posting useless comments just to un-bold stuff. What's more, the entries are sorted by last activity, so all the bolds float to the top. Is there any way? apparently not. http://code.google.com/p/gerrit/issues/detail?id=2390 other than that, you need to rely on the notification mails. i tried to reduce the flood somewhat by denying the bots (including CI) the right to mail reviewers, so only the owner now gets the emails. on the downside, you now need to pay more attention in case you adopt a change from someone else, as you are still a reviewer as far as gerrit is concerned ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: All Qt modules must use the same version number
Hi, It seems that Jocelyn answered most of the questions, but I put my answers anyway :-) On Wednesday 25 of June 2014 15:42:36 Stephen Kelly wrote: (...) Conclusion 1) Even if a Qt module has a disparate version scheme, bumping its major version and changing its SONAME are not acceptable. Therefore the major version must stay the same until Qt 6. Proposal 1) All Qt modules must use the major version '5' for consistency. Technically it is possible and we should consider to do it if it is _really_ necessary. It is a matter of careful name-spacing in the new major module version. We should not get to a situation in which it is easier to abandon a module and create a new one then bump the major version number. qtenginio uses private QtCore API. $ git grep \-private src/ src/enginio_client/enginio_client.pro:QT += core-private network src/enginio_plugin/enginio_plugin.pro:QT += qml quick enginio enginio-private core-private That means that a particular version of qtenginio is tied to a particular version of QtCore. Conclusion 2) A disparate version scheme for something released 'as part of Qt 5.x.y' creates dll-hell. Furthermore, the version of qtenginio released with Qt 5.x.y is only tested with that 'distribution version' it was part of (that is qtenginio 1.0.5 was only tested with and a part of Qt 5.3.0). There is no way anyone is going to test any significant portion of the possible combination matrix. Enginio is using private API for QObjectPrivate creation. So it has to be re- compiled and tested per Qt patch release. I do not see how it creates dll hell as Enginio is keeping binary compatibility. Each new version is compiled and tested against specific QtCore (and friends) version, it would be 1 to 1 mapping. Conclusion 3) Using the version of qtenginio released with the version of Qt it was distributed with is the only sane thing to do. A requirement to make newer releases of qtenginio work with previous Qt releases would constrain qtenginio development. Conclusion 4) If multiple qtenginio releases are made between Qt 5.x.y and Qt 5.x.y+1, they can only reasonably be expected to work with Qt 5.x.y, not later or earlier releases. From binary compatibility perspective yes, it is a sensible assumption for modules using private api as enginio. From source code perspective it really depends. Proposal 2) All modules which are 'part of Qt 5.x.y' must use the version number '5.x.y'. If a module wants to make an out-of-band release, they must use a different version number such as 5.x.y.z or some other completely different number (1.0.5 would also be ok for an out of band release, but that could not be part of Qt 5.x.y). qtenginio is exempt from these proposals because it is a 'past mistake'. I disagree, then you would end-up with double version numbers which would confuse our users. Is version 1.5 newer then 5.4? How to advocate it? I do not see how 5.x.y.z is different than z.x.y as modules are shipped together with Qt. As far I understand past mistake of Enginio is not having Qt5 prefix, not that it has a different version number. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: All Qt modules must use the same version number
Em sex 27 jun 2014, às 10:57:14, Stephen Kelly escreveu: I guess this is a subject for when and if the situation happens again. Make that suggestion next time too. The enginio situation happened because it was not actually discussed. Because it was allowed under the previous guidelines. I'll re-read your proposal and address it as best as I can. -- 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] Expiring old change reviews
On Fri, Jun 27, 2014 at 10:22:38AM +0200, Frederik Gladhorn wrote: Torsdag 26. juni 2014 18.14.49 skrev Thiago Macieira: I've just counted: I have 203 pending reviews for me. At least half of them haven't been updated in six months. Some of them are for the old master and api_changes branches and will never, ever be accepted unless resubmitted. Last we discussed this, we were waiting for Gerrit to be updated. It has now. Can we please expire old stuff? Ossi is working on it, so it's going to happen soon. @everyone: This means for everyone that open changes in gerrit that were untouched for ages will be moved to abandoned, you can unabandon them if you think they are still relevant (just check your gerrit mail). Cheers, Frederik Did we agree on abandon, not on defer? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: All Qt modules must use the same version number
On Fri, Jun 27, 2014 at 11:28:14AM +, Koehne Kai wrote: -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [...] We'll always have a 1-to-1 mapping of QtWebEngine and Qt versions and we'll always distribute/test them together. If we release QtWebEngine 1.u.v with Qt 5.x.y, then QtWebEngine 1.u+1.v will also depend on Qt 5.x.y. The two advantages that this gives us is that we can release QtWebEngine more often than Qt, if we want to, and that we can have a version number that reflects our maturity and not the maturity of Qt as a whole. My 2 cents from the packaging/installer side: Any artifact that is heavily bound to a specific Qt build / release, but isn't part of the Qt package itself, is making things complicated. One example: We used to have the Qt packages split up into 'essentials' and 'addons' ... only that Qt Assistant, as part of 'essentials', did depend on the 'addon' QtWebKit, and didn't start if QtWebKit was missing. In practice, we got almost no complains about this, which probably means that nobody bothered to install essentials without addons, in the first place :) As a result we're nowadays shipping one Qt binary package, including all prebuilt essentials addons together. I'm not sure whether this exact problem will be an issue with QtWebEngine too, or for how long Qt Assistant will continue to use QtWebKit. But keeping interdependent packages in sync is certainly not a free ride. That's of course only the binary installer ... I can't judge whether e.g. distributions would appreciate separate releases of QtWebEngine. But given that we're planning to hand out Qt patch level releases more often I'd like to lobby for KISS in this case. That is, if it's an integral part of Qt, shares the BC promises of Qt, ... I think it should share the version number, too. This pretty much sounds like If a module uses private API it should follow Qt Core numbering, if it doesn't it's free to pick anything. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: All Qt modules must use the same version number
Em sex 27 jun 2014, às 21:28:41, André Pönitz escreveu: This pretty much sounds like If a module uses private API it should follow Qt Core numbering, if it doesn't it's free to pick anything. Sounds like a good compromise to me. If a module wants to release out-of-schedule, it will need to use an extra version number, like 5.4.0.1. This also implies that no module that uses private API can be compiled against different versions of Qt. So don't do QT_VERSION checks. If someone has a bug they need fixed, they will just need to upgrade the entire Qt. -- 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] Proposal: All Qt modules must use the same version number
On 27 June 2014 22:10, Thiago Macieira thiago.macie...@intel.com wrote: Sounds like a good compromise to me. If a module wants to release out-of-schedule, it will need to use an extra version number, like 5.4.0.1. The problem with such scheme is that it doesn't make it obvious that there might be a huge difference between the 5.4.0 and 5.4.0.1 releases. Maybe reverse it? As in 1.0.0.540 and 2.0.0.540. My 2 cents, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
