[Development] Qt 4.6.5 and 4.7.6 release candidates available

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130220/be955585/attachment.sig>