Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available
On Tuesday 26 February 2013 10:22:27 Thiago Macieira wrote: > On domingo, 24 de fevereiro de 2013 09.34.43, Thiago Macieira wrote: > The backport of 8afc6773067bb878020c29b3bebfe8662e3fbfdd (as > 2fd21f04d23d5dd87ca0f6db238ae268492f5528) to add support for signed char as > a metatype is dubious. It's a behaviour change, but it might be one that's > acceptable in a patch release to fix a bug. Olivier, can you give me your > opinion? The change is yours. That change was made in August 2010, before the release of Qt 4.7. It was not submited in the stable branch because 4.7 was already feature frozen, and that fix is not a regression, and not critical. My opinion is that Qt 4.7 is old and I don't really care about it at this point. If someone want bug fixes, they should get the latest Qt 4.8.x instead. /me remembers a joke he did in the Nokia's dev mailinglist proposing to merge the master branch (4.8) into Qt 4.7.4 as Qt 4.7.4 was getting more and more features. -- 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] Qt 4.6.5 and 4.7.6 release candidates available
On domingo, 24 de fevereiro de 2013 09.34.43, Thiago Macieira wrote: > However, I can't be sure because the diff between the two branches is > unreviewable, since every header is modified. Someone needs to produce a > clean diff we can review and post to the list. Tuukka told me in an email probably mistakenly sent privately only that I could compare 4.7.4 and 4.7.5. I was waiting for the email to show up on the ML before I would reply. It backports 98d51e42c81c0674bc724eccbdf8521d9317998a to make QtConcurrent support handling exceptions. That's two mistakes in one: first, it's a new feature in a patch release. Second, it misses backporting 451c3e973a49c8b467cc865f6d1f4a2c21902dc7, which removed a stray qDebug that was printed whenever an exception was caught. The backport of 8afc6773067bb878020c29b3bebfe8662e3fbfdd (as 2fd21f04d23d5dd87ca0f6db238ae268492f5528) to add support for signed char as a metatype is dubious. It's a behaviour change, but it might be one that's acceptable in a patch release to fix a bug. Olivier, can you give me your opinion? The change is yours. The rest of the changes to QtCore and QtDBus do not seem harmful, though. There are certainly a few that I find questionable, like backporting changes to the Symbian codepaths. As for a full public header review, I have found something that shouldn't be there. bed275599ff44809372af99b9b6cbe492f5fdec8, an improperly-marked backport of 83ad5ebb033799352723a9d968b31a9cef61396c, adds a new public symbol. That change de-inlines a function in a public header, to the effect of breaking the forwards- and backwards-compatibility requirement of a patch release, despite what its changes file says. What do we do now? 1) Disavow that release, claiming it was never official and revert the change to 4.7.6? Anyone who compiled code with 4.7.5 will need to recompile. 2) Acknowledge the mistake, keep it for 4.7.6 and just add a note to the changes file? -- 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 domingo, 24 de fevereiro de 2013 06.43.24, Turunen Tuukka wrote: > Getting back to the topic of these releases - what is our decision? > > Shall we do the RC2 as proposed, but with shmget fix in 4.7.6, and later go > to release unless problems are found? This would mean we accept that there > is not perfect history available and that we trust the way changes were > cherry-picked to 4.6.4 and 4.7.5. > > Or shall we leave the history as it is and not release these? I think that the contents that you were proposing to release are *probably* fine, provided that we add the shmget fix. However, I can't be sure because the diff between the two branches is unreviewable, since every header is modified. Someone needs to produce a clean diff we can review and post to the list. -- 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
Getting back to the topic of these releases - what is our decision? Shall we do the RC2 as proposed, but with shmget fix in 4.7.6, and later go to release unless problems are found? This would mean we accept that there is not perfect history available and that we trust the way changes were cherry-picked to 4.6.4 and 4.7.5. Or shall we leave the history as it is and not release these? Yours, Tuukks Lähettäjä: development-bounces+tuukka.turunen=digia@qt-project.org [development-bounces+tuukka.turunen=digia@qt-project.org] käyttäjän Thiago Macieira [thiago.macie...@intel.com] puolesta Lähetetty: 21. helmikuuta 2013 20:07 Vastaanottaja: development@qt-project.org Aihe: 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 ") 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 ___ 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 February 2013 12:53, Turunen Tuukka wrote: > > > 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. The problem is that you never announced the SHA1 of the commits of the RC releases, and thus nobody immediately figured out that you were going to release from the digia branches, not the official ones. (You didn't even push the tags on the repository -- there are no v4.7.6-rc* or v4.6.5-rc* around.) What I do see instead that you *already pushed* the v4.7.6 and v4.6.5 tags without telling anyone, and those tags were created *more than one week* before the first message of this thread (in which you announced that you wanted to create release candidates): > $ git show v4.7.6 > tag v4.7.6 > Tagger: Marko Valtanen > Date: Wed Dec 12 17:04:36 2012 +0200 > > Qt 4.7.6 opensource release > > commit 41d648720d9bd87381b85ade3da0d91456ff31e0 (tag: refs/tags/v4.7.6) > > $ git show v4.6.5 > tag v4.6.5 > Tagger: Marko Valtanen > Date: Wed Dec 12 12:27:38 2012 +0200 > > Qt 4.6.5 opensource release > > commit 63eb2e6a39c1a5bee6551cd6a7749a85856d5393 (tag: refs/tags/v4.6.5, > refs/remotes/origin/4.6-digia) I don't have access to the reflog, but according to gitorious, they have been pushed the same day at 15:04 / 15:07 CET. Also, v4.7.6 seems to point at the wrong commit, as it's a commit outside any branch: > $ git log --graph --oneline --decorate origin/4.7-digia v4.7.6 > * 41d6487 (tag: v4.7.6) Changes-4.7.6 file updated > * 436cf69 Fix binary incompatibility between openssl versions > | * 090ca16 (origin/4.7-digia) Changes-4.7.6 file updated > | * 7ce4690 Fix binary incompatibility between openssl versions > |/ > * b67ee40 updated LICENSE.PREVIEW.COMMERCIAL > * cba3ada Nokia to Digia for LGPL-exception file So at the very least (no matter what we decide to do with the version numbering) that tag needs to be deleted and recreated. man git-tag at "On Re-tagging" offers a nice email template you could use for the purpose. Cheers, -- Giuseppe D'Angelo ___ 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
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" 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] 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 ") 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
Hi, Sorry about top posting.. I think Tuukka forgot to mention\highlight that on alternative > 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 there can be effect on release content from the decision on "The shmget security fix" - thread as he earlier wrote today on this same email thread > From: Turunen Tuukka > Sent: 21. helmikuuta 2013 9:26 > To: Thiago Macieira; development@qt-project.org > Subject: Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available [...] > Ok. Including or not including this fix to the 4.7.6 is anyways a > judgement call, so lets see what is said in the other thread. Br, Akseli > -Original Message- > From: development-bounces+akseli.salovaara=digia@qt-project.org > [mailto:development-bounces+akseli.salovaara=digia@qt-project.org] > On Behalf Of Turunen Tuukka > Sent: 21. helmikuuta 2013 15:01 > To: Thiago Macieira; development@qt-project.org > Subject: Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available > Importance: High > > > 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, R&D > 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" 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 >
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, R&D 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" 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 af
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
On 21.2.2013 10.07, "Peter Kümmel" 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
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] Qt 4.6.5 and 4.7.6 release candidates available
On 21.2.2013 2.43, "Thiago Macieira" wrote: >On quarta-feira, 20 de fevereiro de 2013 16.34.19, Thiago Macieira wrote: >> You cannot make that call alone. What's more, we discussed the problem >>and >> the solution for two months in the security mailing list, which you're >>a >> part of. If there's a problem, please start a new thread on this mailing >> list so we can discuss it. >> >> Meanwhile, either include the fix in the release or don't release. > >Let me make it even more plain: the security announcement (which you had >a >month to review from draft to publication) said: > >=== >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: >=== > >So we have to include the fix in 4.7.6 or we have to issue another >security >advisory. > >Please see the other thread I've just started. Ok. Including or not including this fix to the 4.7.6 is anyways a judgement call, so lets see what is said in the other thread. I'll answer a bit later to your other mail related making the releases. I still think we are best off issuing the releases as agreed in December. The other options are not that good either, so we have to compromise. Yours, Tuukka > >-- >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] Qt 4.6.5 and 4.7.6 release candidates available
On quarta-feira, 20 de fevereiro de 2013 16.34.19, Thiago Macieira wrote: > You cannot make that call alone. What's more, we discussed the problem and > the solution for two months in the security mailing list, which you're a > part of. If there's a problem, please start a new thread on this mailing > list so we can discuss it. > > Meanwhile, either include the fix in the release or don't release. Let me make it even more plain: the security announcement (which you had a month to review from draft to publication) said: === 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: === So we have to include the fix in 4.7.6 or we have to issue another security advisory. Please see the other thread I've just started. -- 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 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 included. If there's a problem with the fix, please raise it. > And if we start re-do packages and release content we will delay work with > 5.0.x and 5.1.x releases, which I am sure no-one wants. Then we delay the 4.6 and 4.7 packages, which also gives us time to the review I'm asking for and even do the merge of the branches. > >Let's compromise then: we release the 4.7-digia branch provided that the > >4.7 > >branch also gets released within six months. Plan: > > > >1) the security fix is backported into the 4.x-digia branches > > The fixes included should be the ones also in the RC1 in my opinion as the > shmget contains functionality change prone to cause problems. Well, then we have a problem because in my opinion, as the maintainer of the code in question, the chance of causing problems is outweighed by the security fix itself. If there's a problem with the security fix, then we need to deal with it immediately, not arbitrarily decide to exclude it from a release after announcing it. You cannot make that call alone. What's more, we discussed the problem and the solution for two months in the security mailing list, which you're a part of. If there's a problem, please start a new thread on this mailing list so we can discuss it. Meanwhile, either include the fix in the release or don't release. > >2) we review all changes made to those branches that aren't in the > >respective > >4.x branch, with silent approval: if no one objects, the change is > >approved > > There is none of such to my knowledge. You said above that there are (the 4.8 backports). If there weren't any, then the 4.x-digia branch would a subset of the corresponding 4.x branch and, so, the release would be made out of the 4.x branch instead. > >3) we release from the 4.x-digia branch, with the public note of the > >mistake > >in the 4.7 version number > > We can omit the -digia as it causes confusion. Sorry, to be specific: we release 4.6.5 from the 4.6-digia branch and 4.7.6 from the 4.7-digia branch. The releases themselves won't have the "-digia" suffix in their version numbers. > >4) we merge the 4.x-digia branch into the 4.x branch and close the > >4.x-digia > >branch > > > >5) we release Qt 4.7.7 within six months > > > >I'd like to hear that there will be people allocated to doing the release > >work > >for the changes that went into the Qt 4.7 branch in the past year since > >the > >two branches diverged. > > As mentioned these are already done when the original contributions have > been made. We've established that there are changes that are in those branches that were not approved to be in those branches, and that there are changes approved for the 4.7 release that are not getting included in the release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. _
Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available
On 19.2.2013 22.02, "Thiago Macieira" wrote: >On terça-feira, 19 de fevereiro de 2013 19.29.50, Turunen Tuukka wrote: >> Hi Thiago, >> >> Due to the way earlier releases are done it is not possible to have >> perfectly clean history. This has been discussed in December and after >>the >> different options were analysed it was seen the best one to do as it now >> is. End result is the same, we have 4.6.5 and 4.7.6 releases available >>in a >> way closer to where they should be. > >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. 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. And if we start re-do packages and release content we will delay work with 5.0.x and 5.1.x releases, which I am sure no-one wants. > >Let's compromise then: we release the 4.7-digia branch provided that the >4.7 >branch also gets released within six months. Plan: > >1) the security fix is backported into the 4.x-digia branches The fixes included should be the ones also in the RC1 in my opinion as the shmget contains functionality change prone to cause problems. > >2) we review all changes made to those branches that aren't in the >respective >4.x branch, with silent approval: if no one objects, the change is >approved There is none of such to my knowledge. > >3) we release from the 4.x-digia branch, with the public note of the >mistake >in the 4.7 version number We can omit the -digia as it causes confusion. > >4) we merge the 4.x-digia branch into the 4.x branch and close the >4.x-digia >branch > >5) we release Qt 4.7.7 within six months > >I'd like to hear that there will be people allocated to doing the release >work >for the changes that went into the Qt 4.7 branch in the past year since >the >two branches diverged. As mentioned these are already done when the original contributions have been made. -- Tuukka > >-- >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] Qt 4.6.5 and 4.7.6 release candidates available
On terça-feira, 19 de fevereiro de 2013 19.29.50, Turunen Tuukka wrote: > Hi Thiago, > > Due to the way earlier releases are done it is not possible to have > perfectly clean history. This has been discussed in December and after the > different options were analysed it was seen the best one to do as it now > is. End result is the same, we have 4.6.5 and 4.7.6 releases available in a > way closer to where they should be. 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. > It is very difficult for me to see why this should be done more difficult > way that brings little to none practical benefits? These packages are > valuable for the users and since the currently distributed packages contain > wrong copyrights, they should not be distributed at all. No-one wants that. > Thus we should just move ahead with this one as already agreed in December > as no-one raised any objections back then. I know. I failed to see that they were coming from the wrong branch. I was simply happy that someone was taking care of the older releases. This was recently brought to my attention, so I am now taking action. > 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. If we're releasing 4.6 too, I'll backport the fix to the 4.6 branch. Let's compromise then: we release the 4.7-digia branch provided that the 4.7 branch also gets released within six months. Plan: 1) the security fix is backported into the 4.x-digia branches 2) we review all changes made to those branches that aren't in the respective 4.x branch, with silent approval: if no one objects, the change is approved 3) we release from the 4.x-digia branch, with the public note of the mistake in the 4.7 version number 4) we merge the 4.x-digia branch into the 4.x branch and close the 4.x-digia branch 5) we release Qt 4.7.7 within six months I'd like to hear that there will be people allocated to doing the release work for the changes that went into the Qt 4.7 branch in the past year since the two branches diverged. -- 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
Hi Thiago, Due to the way earlier releases are done it is not possible to have perfectly clean history. This has been discussed in December and after the different options were analysed it was seen the best one to do as it now is. End result is the same, we have 4.6.5 and 4.7.6 releases available in a way closer to where they should be. It is very difficult for me to see why this should be done more difficult way that brings little to none practical benefits? These packages are valuable for the users and since the currently distributed packages contain wrong copyrights, they should not be distributed at all. No-one wants that. Thus we should just move ahead with this one as already agreed in December as no-one raised any objections back then. 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. Yours, Tuukka Lähettäjä: development-bounces+tuukka.turunen=digia@qt-project.org [development-bounces+tuukka.turunen=digia@qt-project.org] käyttäjän Thiago Macieira [thiago.macie...@intel.com] puolesta Lähetetty: 19. helmikuuta 2013 20:16 Vastaanottaja: development@qt-project.org Aihe: Re: [Development] Qt 4.6.5 and 4.7.6 release candidates available On terça-feira, 19 de fevereiro de 2013 16.42.44, Turunen Tuukka wrote: > Hi Thiago, > > The whole idea of 4.6.5 and 4.7.6 is to unfork these and unify. It has > never been about making a Digia specific release. We have no intention to > make any Digia specific 4.6 and 4.7 release - quite the opposite - we wish > to unify those releases that have been done earlier (and even then we > actually preferred in having the 4.6.4 and 4.7.5 release to be in the > right place, which was not possible at the time). That's a great plan. But the plan does not seem to match reality. > It is hard to change history, but we can at least come up with such a > solution that where 4.6 and 4.7 branches end things are somewhat aligned. > > As discussed earlier the rationale for making 4.6.5 and 4.7.6 releases is: > > -> Do the copyrights change also in packages > -> Address important security vulnerabilities > -> "Unfork" 4.6 and 4.7 branches > > Š and all this done in such a way that does not take overwhelmingly high > amount of time as it is away from Qt 5 and 4.8 work. > > What we are proposing is somewhat the same as you listed as 'Plan II'. Plan II is fine. But note what I said about the branch: > >Alternative plan (Plan II): > >1) release Qt Project's 4.7.6 and announce that we're skipping one > >version > >number to align with a past commercial release by Digia, but that it > >won't > >happen again. This release must come from the 4.7 branch, not the > >4.7-digia > >branch. > > > >2) after that, Digia is allowed to release 4.7.6-digia. If we want to unify, then we need to merge the 4.7-digia branch into 4.7. If that's the plan, I will carefully review all the changes in that merge that apply to the modules I maintain. Whether we do that before or after the release, I don't care. What I care about is that the Qt Project's 4.7.5 or 4.7.6 release come from the 4.7 branch. Ditto for the 4.6.5 release and the 4.6 branch. -- 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] Qt 4.6.5 and 4.7.6 release candidates available
On terça-feira, 19 de fevereiro de 2013 16.42.44, Turunen Tuukka wrote: > Hi Thiago, > > The whole idea of 4.6.5 and 4.7.6 is to unfork these and unify. It has > never been about making a Digia specific release. We have no intention to > make any Digia specific 4.6 and 4.7 release - quite the opposite - we wish > to unify those releases that have been done earlier (and even then we > actually preferred in having the 4.6.4 and 4.7.5 release to be in the > right place, which was not possible at the time). That's a great plan. But the plan does not seem to match reality. > It is hard to change history, but we can at least come up with such a > solution that where 4.6 and 4.7 branches end things are somewhat aligned. > > As discussed earlier the rationale for making 4.6.5 and 4.7.6 releases is: > > -> Do the copyrights change also in packages > -> Address important security vulnerabilities > -> "Unfork" 4.6 and 4.7 branches > > Š and all this done in such a way that does not take overwhelmingly high > amount of time as it is away from Qt 5 and 4.8 work. > > What we are proposing is somewhat the same as you listed as 'Plan II'. Plan II is fine. But note what I said about the branch: > >Alternative plan (Plan II): > >1) release Qt Project's 4.7.6 and announce that we're skipping one > >version > >number to align with a past commercial release by Digia, but that it > >won't > >happen again. This release must come from the 4.7 branch, not the > >4.7-digia > >branch. > > > >2) after that, Digia is allowed to release 4.7.6-digia. If we want to unify, then we need to merge the 4.7-digia branch into 4.7. If that's the plan, I will carefully review all the changes in that merge that apply to the modules I maintain. Whether we do that before or after the release, I don't care. What I care about is that the Qt Project's 4.7.5 or 4.7.6 release come from the 4.7 branch. Ditto for the 4.6.5 release and the 4.6 branch. -- 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
Hi Thiago, The whole idea of 4.6.5 and 4.7.6 is to unfork these and unify. It has never been about making a Digia specific release. We have no intention to make any Digia specific 4.6 and 4.7 release - quite the opposite - we wish to unify those releases that have been done earlier (and even then we actually preferred in having the 4.6.4 and 4.7.5 release to be in the right place, which was not possible at the time). It is hard to change history, but we can at least come up with such a solution that where 4.6 and 4.7 branches end things are somewhat aligned. As discussed earlier the rationale for making 4.6.5 and 4.7.6 releases is: -> Do the copyrights change also in packages -> Address important security vulnerabilities -> "Unfork" 4.6 and 4.7 branches Š and all this done in such a way that does not take overwhelmingly high amount of time as it is away from Qt 5 and 4.8 work. What we are proposing is somewhat the same as you listed as 'Plan II'. Yours, -- Tuukka Turunen Director, R&D 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 19.2.2013 18.14, "Thiago Macieira" wrote: >On sexta-feira, 21 de dezembro de 2012 16.11.08, Salovaara Akseli wrote: >> We have created Qt 4.6.5 and 4.7.6 release candidates that bring the >> following changes over the previous ones in their series: > >$ ncftpls ftp://ftp.qt-project.org/qt/source/*4.7.*.tar.gz >qt-everywhere-opensource-src-4.7.0.tar.gz >qt-everywhere-opensource-src-4.7.1.tar.gz >qt-everywhere-opensource-src-4.7.2.tar.gz >qt-everywhere-opensource-src-4.7.3.tar.gz >qt-everywhere-opensource-src-4.7.4.tar.gz > >What happened to 4.7.5? > >Answer: it was a Digia release. (cf discussion in https://codereview.qt- >project.org/48232) > >The next Qt 4.7 release from the Qt Project is 4.7.5. I am fine still >with the >plan as posted: > >> We do not want to add other than important security fixes and mandatory >> copyright changes in order not to cause regressions. > >But the content (the 4.6-digia and 4.7-digia branches) is not following >the >plan. They include a lot of unrelated changes that aren't the copyright >changes and security fixes. And there has been an extra security fix >since then >that isn't in those vendor branches. > >I propose therefore the following plan (Plan I): > >1) release Qt Project's Qt 4.6.5 and 4.7.5 following the plan above, by >branching off the latest tags (4.6.4 and 4.7.4), applying the security >fixes and >the copyright changes > >2) release again Qt Project's 4.7.6 that includes those plus all the >other >fixes > >3) after that, Digia is allowed to release 4.7.6-digia. > > >Alternative plan (Plan II): >1) release Qt Project's 4.7.6 and announce that we're skipping one >version >number to align with a past commercial release by Digia, but that it >won't >happen again. This release must come from the 4.7 branch, not the >4.7-digia >branch. > >2) after that, Digia is allowed to release 4.7.6-digia. > > >And Plan III: >1) Digia releases 4.7.4-digia2 or 4.7.5-digia2, without increasing the >main Qt >version number again. That is not a Qt Project release. > >Remember: only the Qt Project can create a new Qt version number. > >-- >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] Qt 4.6.5 and 4.7.6 release candidates available
On sexta-feira, 21 de dezembro de 2012 16.11.08, Salovaara Akseli wrote: > We have created Qt 4.6.5 and 4.7.6 release candidates that bring the > following changes over the previous ones in their series: $ ncftpls ftp://ftp.qt-project.org/qt/source/*4.7.*.tar.gz qt-everywhere-opensource-src-4.7.0.tar.gz qt-everywhere-opensource-src-4.7.1.tar.gz qt-everywhere-opensource-src-4.7.2.tar.gz qt-everywhere-opensource-src-4.7.3.tar.gz qt-everywhere-opensource-src-4.7.4.tar.gz What happened to 4.7.5? Answer: it was a Digia release. (cf discussion in https://codereview.qt- project.org/48232) The next Qt 4.7 release from the Qt Project is 4.7.5. I am fine still with the plan as posted: > We do not want to add other than important security fixes and mandatory > copyright changes in order not to cause regressions. But the content (the 4.6-digia and 4.7-digia branches) is not following the plan. They include a lot of unrelated changes that aren't the copyright changes and security fixes. And there has been an extra security fix since then that isn't in those vendor branches. I propose therefore the following plan (Plan I): 1) release Qt Project's Qt 4.6.5 and 4.7.5 following the plan above, by branching off the latest tags (4.6.4 and 4.7.4), applying the security fixes and the copyright changes 2) release again Qt Project's 4.7.6 that includes those plus all the other fixes 3) after that, Digia is allowed to release 4.7.6-digia. Alternative plan (Plan II): 1) release Qt Project's 4.7.6 and announce that we're skipping one version number to align with a past commercial release by Digia, but that it won't happen again. This release must come from the 4.7 branch, not the 4.7-digia branch. 2) after that, Digia is allowed to release 4.7.6-digia. And Plan III: 1) Digia releases 4.7.4-digia2 or 4.7.5-digia2, without increasing the main Qt version number again. That is not a Qt Project release. Remember: only the Qt Project can create a new Qt version number. -- 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
