[Releasing] brown paper bag issue in Qt 5.6.1 packages

[Jani Heikkinen]

Hi,


Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is actually a brown paper bag issue for Qt 5.6.1 release. That's why we need to update release packages with change https://codereview.qt-project.org/#/c/162677/ . We will "release" new packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and tested the packages from new content. It is much easier and safer to select that option instead of releasing Qt 5.6.2 before summer vacations.


br,

Jani


[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]<http://qt.io/>

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]<http://www.facebook.com/Qt> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] <http://www.twitter.com/qtproject> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] <https://www.linkedin.com/company/the-qt-company/> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] <https://plus.google.com/104580575722059274792> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] <https://www.youtube.com/QtStudios>

[Thiago Macieira]

On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote:
> Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is
> actually a brown paper bag issue for Qt 5.6.1 release. That's why we need
> to update release packages with change
> https://codereview.qt-project.org/#/c/162677/ . We will "release" new
> packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and
> tested the packages from new content. It is much easier and safer to select
> that option instead of releasing Qt 5.6.2 before summer vacations.

I've just noticed this email.

QTBUG-53761 is not P0, so it did not warrant new packages.

The naming for the new tag is totally unacceptable. It should have been
v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then
we release v5.6.2 immediately after.

And if for some reason it was too difficult to bump everything that was
scheduled for 5.6.2 to 5.6.3, then at the very least we should have used
v5.6.1.1, which is probably what everyone making Qt packages will need to use
since a dash is completely unacceptable in release versions.

I propose that we delete the bad tag, retag and rerelease with a better name.

Let's not make rash decisions again.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Jani Heikkinen]

Hi!


Actually https://bugreports.qt.io/browse/QTBUG-53761 is a blocker. Priority isn't correct at the moment but in reality the bug is preventing any bigger and a bit complex applications working correctly. Unfortunately bug isn't describing that well enough :(


That's why we need to update the packages just with that one fix. And that's why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix. There was already request 'because you are doing new release please include this fixes' etc :) and that is unfortunately impossible now, just before summer holidays, sorry.


And what comes to tag: we have used '-1' tag earlier (in enterprise repositories) and we didn't see any reason to change that 'hotfix' tagging scheme. It was discussed in irc as well but at least for me no-one really says why '-1' pattern is wrong. There was just opinions for and against and because we have used '-1' tag earlier it was selected this time as well. Another reason was the package naming: We have some tools which cannot handle 5.6.1.1 but can handle 5.6.1-1 in package names and it is better to use same format in the tag what is used in package names.


But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1 would work then it is really ok for me to change the tag. But let's don't change that just because of opinions...


br,

Jani





________________________________
From: Development <development-bounces+jani.heikkinen=***@qt-project.org> on behalf of Thiago Macieira <***@intel.com>
Sent: Wednesday, June 22, 2016 2:42 AM
To: ***@qt-project.org
Cc: ***@qt-project.org
Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote:
> Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is
> actually a brown paper bag issue for Qt 5.6.1 release. That's why we need
> to update release packages with change
> https://codereview.qt-project.org/#/c/162677/ . We will "release" new
> packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and
> tested the packages from new content. It is much easier and safer to select
> that option instead of releasing Qt 5.6.2 before summer vacations.

I've just noticed this email.

QTBUG-53761 is not P0, so it did not warrant new packages.

The naming for the new tag is totally unacceptable. It should have been
v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then
we release v5.6.2 immediately after.

And if for some reason it was too difficult to bump everything that was
scheduled for 5.6.2 to 5.6.3, then at the very least we should have used
v5.6.1.1, which is probably what everyone making Qt packages will need to use
since a dash is completely unacceptable in release versions.

I propose that we delete the bad tag, retag and rerelease with a better name.

Let's not make rash decisions again.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On quarta-feira, 22 de junho de 2016 05:03:28 PDT Jani Heikkinen wrote:
> That's why we need to update the packages just with that one fix. And that's
> why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix.

That's still "the next release after 5.6.1 without new features", so it's
5.6.2.

> And what comes to tag: we have used '-1' tag earlier (in enterprise
> repositories) and we didn't see any reason to change that 'hotfix' tagging

I don't care what you've done in enterprise repositories since they are not
visible and the Qt community wasn't consulted. We also have a rule that only
the Qt Project can create new version numbers, so enterprise releases need to
have a field to annotate differentiations: that's the part after the dash.

The binary packages also don't count. That's again exactly what the part after
the dash is for: it notes what the different build (release) of that
particular source code version is.

But the source packages cannot have a dash. There's no discussion to be had
here.

See also what QVersionNumber does:
QVersionNumber::fromString("5.6.1") < QVersionNumber::fromString("5.6.1-1')
is false

> scheme. It was discussed in irc as well but at least for me no-one really
> says why '-1' pattern is wrong. There was just opinions for and against and
> because we have used '-1' tag earlier it was selected this time as well.

We have never used a dash in the version number itself. Separation for "rc"
and "beta" has never been a problem, though I'm sure many of our downstream
would have liked us to use version numbers like 5.7.90, 5.7.99, etc. in the
source for those.

> Another reason was the package naming: We have some tools which cannot
> handle 5.6.1.1 but can handle 5.6.1-1 in package names and it is better to
> use same format in the tag what is used in package names.

We have tools that can't handle 5.6.1-1, but can handle 5.6.1.1. More
importantly, we have tools that can't handle either, like the configure script,
which produces QT_VERSION.

Conclusion: both 5.6.1.1 and 5.6.1-1 are bad ideas. Let's use the correct
version number: 5.6.2.

> But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1
> would work then it is really ok for me to change the tag. But let's don't
> change that just because of opinions...

5.6.1-1 does not work in Linux packages. The part after the dash is reserved
for the distribution packages themselves, like the our binary packages as
discussed above. For example, OpenSUSE Tumbleweed currently has Qt packages
with version 5.6.0-1.1, the KDE::Qt56 repositories are providing 5.6.2-5.1,
KDE:Qt57 has 5.7.0-35.1.

That means release 1.1 of Qt's 5.6.0 source code. Traditionally, the release
number resets to 1 when a source version number changes, but is rev'ved up
whenever you make changes to the scripts that produce the packages. Like our
binaries.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Jani Heikkinen]

Hi,


To be clear: There isn't version bump in qt, it is still 5.6.1. We just re-packed the release from '5.6.1' branch with that new change for fixing QTBUG-53761 included (https://codereview.qt-project.org/#/c/162677/). In tags & packages we used 5.6.1-1 to make difference with original and updated ones & to be able to identify if user has original or re-packed version in the use. Of course we could just move v5.6.1 tag in declarative and ignore v5.6.1-1 and that's it...


But It has done this way now. Ok, if tag or something is really broken let's just correct that but otherwise just live with this now. And for the future lets just agree the way to work with this kind of 'brown paper bug issue'. In my opinion bumping version numbers and doing totally new release because of just one fix is too heavy. I think we should have a way to produce this kind of update with 'simple hot fix ' easily and quickly without re-doing whole release in case of this kind of blocker.


br,

Jani

________________________________
From: Releasing <releasing-bounces+jani.heikkinen=***@qt-project.org> on behalf of Thiago Macieira <***@intel.com>
Sent: Wednesday, June 22, 2016 8:50 AM
To: ***@qt-project.org
Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages

On quarta-feira, 22 de junho de 2016 05:03:28 PDT Jani Heikkinen wrote:
> That's why we need to update the packages just with that one fix. And that's
> why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix.

That's still "the next release after 5.6.1 without new features", so it's
5.6.2.

> And what comes to tag: we have used '-1' tag earlier (in enterprise
> repositories) and we didn't see any reason to change that 'hotfix' tagging

I don't care what you've done in enterprise repositories since they are not
visible and the Qt community wasn't consulted. We also have a rule that only
the Qt Project can create new version numbers, so enterprise releases need to
have a field to annotate differentiations: that's the part after the dash.

The binary packages also don't count. That's again exactly what the part after
the dash is for: it notes what the different build (release) of that
particular source code version is.

But the source packages cannot have a dash. There's no discussion to be had
here.

See also what QVersionNumber does:
QVersionNumber::fromString("5.6.1") < QVersionNumber::fromString("5.6.1-1')
is false

> scheme. It was discussed in irc as well but at least for me no-one really
> says why '-1' pattern is wrong. There was just opinions for and against and
> because we have used '-1' tag earlier it was selected this time as well.

We have never used a dash in the version number itself. Separation for "rc"
and "beta" has never been a problem, though I'm sure many of our downstream
would have liked us to use version numbers like 5.7.90, 5.7.99, etc. in the
source for those.

> Another reason was the package naming: We have some tools which cannot
> handle 5.6.1.1 but can handle 5.6.1-1 in package names and it is better to
> use same format in the tag what is used in package names.

We have tools that can't handle 5.6.1-1, but can handle 5.6.1.1. More
importantly, we have tools that can't handle either, like the configure script,
which produces QT_VERSION.

Conclusion: both 5.6.1.1 and 5.6.1-1 are bad ideas. Let's use the correct
version number: 5.6.2.

> But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1
> would work then it is really ok for me to change the tag. But let's don't
> change that just because of opinions...

5.6.1-1 does not work in Linux packages. The part after the dash is reserved
for the distribution packages themselves, like the our binary packages as
discussed above. For example, OpenSUSE Tumbleweed currently has Qt packages
with version 5.6.0-1.1, the KDE::Qt56 repositories are providing 5.6.2-5.1,
KDE:Qt57 has 5.7.0-35.1.

That means release 1.1 of Qt's 5.6.0 source code. Traditionally, the release
number resets to 1 when a source version number changes, but is rev'ved up
whenever you make changes to the scripts that produce the packages. Like our
binaries.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

_______________________________________________
Releasing mailing list
***@qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing
Releasing Info Page - Qt<http://lists.qt-project.org/mailman/listinfo/releasing>
lists.qt-project.org
To see the collection of prior postings to the list, visit the Releasing Archives. Using Releasing: To post a message to all the list members, send ...

[Giuseppe D'Angelo]

On Wed, Jun 22, 2016 at 8:28 AM, Jani Heikkinen <***@qt.io>
wrote:

> In my opinion bumping version numbers and doing totally new release
> because of just one fix is too heavy. I think we should have a way to
> produce this kind of update with 'simple hot fix ' easily and quickly
> without re-doing whole release in case of this kind of blocker.


This reopens a question which is still very obscure to the community (or at
least to me), which is: what is the complexity of creating packages? Why is
redoing packages with a different version number (say, by branching 5.6.1
into 5.6.2) "too heavy"? Could you please share some insights on what
happens behind the scenes?

Thank you,
--
Giuseppe D'Angelo

[Jani Heikkinen]

Hi!


Actually there is quite many things to do for the new release (agree the content, get the agreed content in etc.) but if we are assuming content is agreed to be one change + version bumps then the flow is pretty much as follows:


1. Create new branch for the release (not needed if updating existing release)

2. Do version bumps for submodules in that new branch + create a fix in that new branch (not needed if updating existing release)

3. Integrate fix + version bumps. When we are doing new release we need to bump version in each submodule as well. Knowing our CI stability it will take a while when all version bumps are in submodules. Without version bump we just need to integrate that one change in one submodule

4. Integrate submodule changes in qt5.git. If all modules are changed this step will most probably fail few times because of CI instability (flaky tests, network issues etc). With change in one submodule this is most probably much easier & will go through much quicker

5. Merge qt5.git in our super repository containing qt5.git + enterprise features.

6. Run packaging tools for src and binary packages (patch content, package content in suitable form for installers).

7. Update packaging configurations. If we are doing new release we need to create all new packaging configurations for that. When updating existing release we don't need to change configurations at all. We just need to update package version number for online repository configurations.

8. Update release test automation configurations and tests. (not needed if updating existing release)

9. Create packages for the release (Online repository and offline inataller packages, LGPL and commercial ones)

10. Test the release. If we update existing release with one change it is much easier to test. We need just test that the fix is in and fixes the issue + don't break anything else. And of course test that packaging went ok. So we can rely on RTA in this case pretty much but with totally new release we need significantly more manual test effort in addition and that takes time (testing + collecting results).

11. Publish the release. There is also more configuration changes in delivery tools if doing new release instead of updating old one.


All these take considerable amount of time and Effort. Doing new release instead of updating old one is much harder and here is also more places where something might go wrong. That's why updating old release is much safer.


br,
jani



________________________________
From: Giuseppe D'Angelo <***@gmail.com>
Sent: Wednesday, June 22, 2016 11:04 AM
To: Jani Heikkinen
Cc: Thiago Macieira; ***@qt-project.org
Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages


On Wed, Jun 22, 2016 at 8:28 AM, Jani Heikkinen <***@qt.io<mailto:***@qt.io>> wrote:
In my opinion bumping version numbers and doing totally new release because of just one fix is too heavy. I think we should have a way to produce this kind of update with 'simple hot fix ' easily and quickly without re-doing whole release in case of this kind of blocker.

This reopens a question which is still very obscure to the community (or at least to me), which is: what is the complexity of creating packages? Why is redoing packages with a different version number (say, by branching 5.6.1 into 5.6.2) "too heavy"? Could you please share some insights on what happens behind the scenes?

Thank you,
--
Giuseppe D'Angelo

[Giuseppe D'Angelo]

Hi,

On Wed, Jun 22, 2016 at 12:20 PM, Jani Heikkinen <***@qt.io> wrote:
> Actually there is quite many things to do for the new release (agree the
> content, get the agreed content in etc.) but if we are assuming content is
> agreed to be one change + version bumps then the flow is pretty much as
> follows:

thank you for the extensive description. Some follow up questions: how
much of this is automated today? From just this high level
description, it looks like that most steps can be scripted. Also, what
are the real bottlenecks? Getting the content to integrate cleanly?
Testing the packages on all the platforms?

Cheers,
--
Giuseppe D'Angelo

[Thiago Macieira]

On quarta-feira, 22 de junho de 2016 10:20:15 PDT Jani Heikkinen wrote:
> 10. Test the release. If we update existing release with one change it is
> much easier to test. We need just test that the fix is in and fixes the
> issue + don't break anything else. And of course test that packaging went
> ok. So we can rely on RTA in this case pretty much but with totally new
> release we need significantly more manual test effort in addition and that
> takes time (testing + collecting results).

What (or who) is RTA?

Rapid Testing Automation?

Release Testing Automation?

Release Testing Authority?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Sergio Ahumada]

On 23.06.2016 01:07, Thiago Macieira wrote:
> On quarta-feira, 22 de junho de 2016 10:20:15 PDT Jani Heikkinen wrote:
>> 10. Test the release. If we update existing release with one change it is
>> much easier to test. We need just test that the fix is in and fixes the
>> issue + don't break anything else. And of course test that packaging went
>> ok. So we can rely on RTA in this case pretty much but with totally new
>> release we need significantly more manual test effort in addition and that
>> takes time (testing + collecting results).
>
> What (or who) is RTA?
>
> Rapid Testing Automation?
>
> Release Testing Automation?
>
> Release Testing Authority?
>

http://lists.qt-project.org/pipermail/releasing/2013-November/001502.html

--
Sergio Ahumada
***@texla.cl

[Tuukka Turunen]

> -----Original Message-----
> From: Releasing [mailto:releasing-bounces+tuukka.turunen=***@qt-
> project.org] On Behalf Of Sergio Ahumada
> Sent: torstaina 23. kesäkuuta 2016 8.22
> To: ***@qt-project.org
> Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1
> packages
>
> On 23.06.2016 01:07, Thiago Macieira wrote:
> > On quarta-feira, 22 de junho de 2016 10:20:15 PDT Jani Heikkinen wrote:
> >> 10. Test the release. If we update existing release with one change
> >> it is much easier to test. We need just test that the fix is in and
> >> fixes the issue + don't break anything else. And of course test that
> >> packaging went ok. So we can rely on RTA in this case pretty much but
> >> with totally new release we need significantly more manual test
> >> effort in addition and that takes time (testing + collecting results).
> >
> > What (or who) is RTA?
> >
> > Rapid Testing Automation?
> >
> > Release Testing Automation?
> >
> > Release Testing Authority?
> >
>
> http://lists.qt-project.org/pipermail/releasing/2013-November/001502.html
>

Release Test Automation (RTA) is a system that automatically installs binary packages and runs a series of tests in multiple platforms using Froglogic Squish and various Qt applications. It is currently a separate system, commanded by Jenkins. The system can run a quick smoke test set before manual testing of a snapshot starts, and it can also run a more complete set, which is especially beneficial for patch releases.

It of course does not have to be separate, it could be part of the same CI system as other tests are. But for the while being it is not connected to the CI.

People operating the RTA are working in the release & qa team, it is not a separate organization.

Yours,

Tuukka

> --
> Sergio Ahumada
> ***@texla.cl
>
> _______________________________________________
> Releasing mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing

[Johanna Äijälä]

Hi Thiago & all,

In addition what Tuukka wrote about RTA, currently I'm mainly responsible of the RTA tests for offline and online installers. The goal of the RTA is to minimize the need of manual testing, but everything can't be tested automatically, manual tests are always needed.

RTA tests installer functionality and the packages that are installed, it does not test the content in git repositories.

There are two level of tests, RTA smoke and RTA full tests.
- Smoke test set takes couple of hours to run and analyze. RTA smoke is done before manual test requests are send out, it does a sanity check for the installer by verifying that installer installs correct content with default settings and builds all examples to verify that the content works, also light QtCreator testing is included.
- Full test round takes about 48 hours. It is done parallel with manual testing. Tests include installing with different options, license checking, source package tests (content and licenses check and building Qt with different configure options) and some iOS and Android deployment tests.

Test execution times depends on the number of available machines, RTA uses same build machines as coin.

Br,
Johanna

-----Original Message-----
From: Releasing [mailto:releasing-bounces+johanna.aijala=***@qt-project.org] On Behalf Of Tuukka Turunen
Sent: 23. kesäkuuta 2016 12:38
To: Sergio Ahumada; ***@qt-project.org
Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages



> -----Original Message-----
> From: Releasing [mailto:releasing-bounces+tuukka.turunen=***@qt-
> project.org] On Behalf Of Sergio Ahumada
> Sent: torstaina 23. kesäkuuta 2016 8.22
> To: ***@qt-project.org
> Subject: Re: [Releasing] [Development] brown paper bag issue in Qt
> 5.6.1 packages
>
> On 23.06.2016 01:07, Thiago Macieira wrote:
> > On quarta-feira, 22 de junho de 2016 10:20:15 PDT Jani Heikkinen wrote:
> >> 10. Test the release. If we update existing release with one change
> >> it is much easier to test. We need just test that the fix is in and
> >> fixes the issue + don't break anything else. And of course test
> >> that packaging went ok. So we can rely on RTA in this case pretty
> >> much but with totally new release we need significantly more manual
> >> test effort in addition and that takes time (testing + collecting results).
> >
> > What (or who) is RTA?
> >
> > Rapid Testing Automation?
> >
> > Release Testing Automation?
> >
> > Release Testing Authority?
> >
>
> http://lists.qt-project.org/pipermail/releasing/2013-November/001502.h
> tml
>

Release Test Automation (RTA) is a system that automatically installs binary packages and runs a series of tests in multiple platforms using Froglogic Squish and various Qt applications. It is currently a separate system, commanded by Jenkins. The system can run a quick smoke test set before manual testing of a snapshot starts, and it can also run a more complete set, which is especially beneficial for patch releases.

It of course does not have to be separate, it could be part of the same CI system as other tests are. But for the while being it is not connected to the CI.

People operating the RTA are working in the release & qa team, it is not a separate organization.

Yours,

Tuukka

> --
> Sergio Ahumada
> ***@texla.cl
>
> _______________________________________________
> Releasing mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing

[Tuukka Turunen]

Hi,

The more there are changes, the more we need to test and the higher the probability of some other things going wrong. If there is only one (or few enough) change to an existing version, we can release binaries in a couple of days e.g. to address a vulnerability or like this case a bad bug.

Yours,

Tuukka

From: Releasing [mailto:releasing-bounces+tuukka.turunen=***@qt-project.org] On Behalf Of Giuseppe D'Angelo
Sent: keskiviikkona 22. kesÀkuuta 2016 11.04
To: Jani Heikkinen <***@qt.io>
Cc: Thiago Macieira <***@intel.com>; ***@qt-project.org
Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages


On Wed, Jun 22, 2016 at 8:28 AM, Jani Heikkinen <***@qt.io<mailto:***@qt.io>> wrote:
In my opinion bumping version numbers and doing totally new release because of just one fix is too heavy. I think we should have a way to produce this kind of update with 'simple hot fix ' easily and quickly without re-doing whole release in case of this kind of blocker.

This reopens a question which is still very obscure to the community (or at least to me), which is: what is the complexity of creating packages? Why is redoing packages with a different version number (say, by branching 5.6.1 into 5.6.2) "too heavy"? Could you please share some insights on what happens behind the scenes?

Thank you,
--
Giuseppe D'Angelo

[Thiago Macieira]

On quarta-feira, 22 de junho de 2016 11:33:38 PDT Tuukka Turunen wrote:
> The more there are changes, the more we need to test and the higher the
> probability of some other things going wrong. If there is only one (or few
> enough) change to an existing version, we can release binaries in a couple
> of days e.g. to address a vulnerability or like this case a bad bug.

No is disputing that.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On quarta-feira, 22 de junho de 2016 06:28:12 PDT Jani Heikkinen wrote:
> Hi,
>
>
> To be clear: There isn't version bump in qt, it is still 5.6.1.

Are the source packages the same? No? Then it's a new version.

> We just
> re-packed the release from '5.6.1' branch with that new change for fixing
> QTBUG-53761 included (https://codereview.qt-project.org/#/c/162677/). In
> tags & packages we used 5.6.1-1 to make difference with original and
> updated ones & to be able to identify if user has original or re-packed
> version in the use. Of course we could just move v5.6.1 tag in declarative
> and ignore v5.6.1-1 and that's it...

We could do that, yes:
* no new qtdeclarative source package
* cherry-pick the patch to the tree used for the binaries, release
* update the binary relase version

I just think it's a bad idea and would cause confusion too.

But I'm asking that we Do The Right Thing, instead of trying to find the
solution with the least amount of effort. We own up to our mistakes and then
we fix the correctly.

> But It has done this way now. Ok, if tag or something is really broken let's
> just correct that but otherwise just live with this now. And for the future
> lets just agree the way to work with this kind of 'brown paper bug issue'.

Let's agree on no more "brown paper bag fixes". Let's not rush into more
mistakes. This only happened because we tried to find the solution with the
least amount of effort instead of doing the proper, established way of
creating new releases.

> In my opinion bumping version numbers and doing totally new release because
> of just one fix is too heavy. I think we should have a way to produce this
> kind of update with 'simple hot fix ' easily and quickly without re-doing
> whole release in case of this kind of blocker.

If we have a light-weight procedure, great, let's use it.

But we don't. And creating one the moment we need a quick fix is a bad idea,
because we're going down untested paths and creating more problems in the
process, as the current case has shown.

I think we should have a light-weight procedure. Let's investigate it when we
have the time to do it.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On quarta-feira, 22 de junho de 2016 06:28:12 PDT Jani Heikkinen wrote:
> Hi,
>
>
> To be clear: There isn't version bump in qt, it is still 5.6.1.

Are the source packages the same? No? Then it's a new version.

> We just
> re-packed the release from '5.6.1' branch with that new change for fixing
> QTBUG-53761 included (https://codereview.qt-project.org/#/c/162677/). In
> tags & packages we used 5.6.1-1 to make difference with original and
> updated ones & to be able to identify if user has original or re-packed
> version in the use. Of course we could just move v5.6.1 tag in declarative
> and ignore v5.6.1-1 and that's it...

We could do that, yes:
* no new qtdeclarative source package
* cherry-pick the patch to the tree used for the binaries, release
* update the binary relase version

I just think it's a bad idea and would cause confusion too.

But I'm asking that we Do The Right Thing, instead of trying to find the
solution with the least amount of effort. We own up to our mistakes and then
we fix the correctly.

> But It has done this way now. Ok, if tag or something is really broken let's
> just correct that but otherwise just live with this now. And for the future
> lets just agree the way to work with this kind of 'brown paper bug issue'.

Let's agree on no more "brown paper bag fixes". Let's not rush into more
mistakes. This only happened because we tried to find the solution with the
least amount of effort instead of doing the proper, established way of
creating new releases.

> In my opinion bumping version numbers and doing totally new release because
> of just one fix is too heavy. I think we should have a way to produce this
> kind of update with 'simple hot fix ' easily and quickly without re-doing
> whole release in case of this kind of blocker.

If we have a light-weight procedure, great, let's use it.

But we don't. And creating one the moment we need a quick fix is a bad idea,
because we're going down untested paths and creating more problems in the
process, as the current case has shown.

I think we should have a light-weight procedure. Let's investigate it when we
have the time to do it.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Oswald Buddenhagen]

On Wed, Jun 22, 2016 at 06:48:39AM +0000, Lars Knoll wrote:
> The only thing that changes when the Linux distributions do such an
> update is the version number of the package, not of the .so’s inside.
>
> We basically do the same here.
>
but we can't, because we are upstream. if the qt company's release team
does not act directly on behalf of the qt project, then this must be
reflected in the version control system, as explicitly stated in the
branch policy: the tag is v5.6.1-tqtc-1, and it is *not* forward-merged
to 5.6.


On Wed, Jun 22, 2016 at 06:54:54AM +0000, Tuukka Turunen wrote:
> Users need it and it is ready, so we really need to release this now.
>
it's undoubtedly necessary, but the fact that it is ready does not
authorize us as a company to violate the agreed upon rules.


the rest of the mail dissects the technicalities. it's unnecessary to
read it if you accept the conclusions reached so far.


On Wed, Jun 22, 2016 at 06:28:12AM +0000, Jani Heikkinen wrote:
> To be clear: There isn't version bump in qt, it is still 5.6.1. We
> just re-packed the release from '5.6.1' branch with that new change
> for fixing QTBUG-53761 included.
>
you're kinda trying to make the argument that the packages are a patched
downstream version, but that seems quite unconvincing: we *are*
upstream. this is reinforced by the fact that our installers are the
primary advertized distribution medium. and it's sealed by you creating
an upstream tag in the mainline repository.

> In my opinion bumping version numbers and doing totally new release
> because of just one fix is too heavy. I think we should have a way to
> produce this kind of update with 'simple hot fix' easily and quickly
> without re-doing whole release in case of this kind of blocker.
>
you're trying to both eat the cake and have it.

it has different contents (which is reflected by a different tag), so it
*is* a different version. it doesn't matter how small the difference is.

On Wed, Jun 22, 2016 at 10:20:15AM +0000, Jani Heikkinen wrote:
> Actually there is quite many things to do for the new release (agree
> the content, get the agreed content in etc.) but if we are assuming
> content is agreed to be one change + version bumps then the flow is
> pretty much as follows:
>
> 1. Create new branch for the release (not needed if updating existing
> release)
>
not necessary, as already pointed out. the existence of a release branch
is a convenience, not a requirement. the name matching the released
version is luxury (we could have release and release-lts branches just
as well).

> 2. Do version bumps for submodules in that new branch + create a fix
> in that new branch (not needed if updating existing release)
>
while it would be somewhat weird, we could bump only qtdeclarative and
qt5, keeping the version number of the other modules the same. but
anyway, see next point.

> 3. Integrate fix + version bumps. When we are doing new release we
> need to bump version in each submodule as well. Knowing our CI
> stability it will take a while when all version bumps are in
> submodules. Without version bump we just need to integrate that one
> change in one submodule
>
as you could have figured out by just looking at the commits, version
bumps are direct-pushed by my script (except repos that happen to be
busy for extended periods of time while i do the bumping, typically
qtbase). so this is a non-argument.

> 4. Integrate submodule changes in qt5.git. If all modules are changed
> this step will most probably fail few times because of CI instability
> (flaky tests, network issues etc). With change in one submodule this
> is most probably much easier & will go through much quicker
>
i don't see how changing at most the version number in all other modules
could delay the integration.

> 5. Merge qt5.git in our super repository containing qt5.git +
> enterprise features.
>
> 6. Run packaging tools for src and binary packages (patch content,
> package content in suitable form for installers).
>
> 7. Update packaging configurations. If we are doing new release we
> need to create all new packaging configurations for that.
>
i'll buy that, but this indicates just how broken the system is. cloning
a branch config should be a matter of a single near-trivial commit.

the previous two points also just show how bad our system is. luckily,
this is finally being worked on.

> 8. Update release test automation configurations and tests. (not
> needed if updating existing release)
>
> 9. Create packages for the release (Online repository and offline
> inataller packages, LGPL and commercial ones)
>
same again. broken infrastructure.

> 10. Test the release. If we update existing release with one change it
> is much easier to test.
>
see point 4.