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; [email protected] > 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: [email protected] > [mailto:[email protected]] > On Behalf Of Turunen Tuukka > Sent: 21. helmikuuta 2013 15:01 > To: Thiago Macieira; [email protected] > 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: [email protected] > 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" <[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
