[Development] Qt 4.6.5 and 4.7.6 release candidates available

[Salovaara Akseli]

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 at 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.com at qt-project.org
> [mailto:development-bounces+akseli.salovaara=digia.com at qt-project.org]
> On Behalf Of Turunen Tuukka
> Sent: 21. helmikuuta 2013 15:01
> To: Thiago Macieira; development at 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.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
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development