[Development] Qt 4.6.5 and 4.7.6 release candidates available

[Turunen Tuukka]

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.com at qt-project.org [development-bounces+tuukka.turunen=digia.com at qt-project.org] käyttäjän Thiago Macieira [thiago.macieira at intel.com] puolesta
Lähetetty: 21. helmikuuta 2013 20:07
Vastaanottaja: development at 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
<QtCommercial at digia.com>") 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