[Development] Qt 4.6.5 and 4.7.6 release candidates available

[Turunen Tuukka]

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.turunen at 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.macieira at 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 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