[Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages

[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.