[Releasing] Duplication of packaging effort

[jason.mcdonald at nokia.com]

>We are also trying to get a CI system up and running which transcends a
>single organization, by moving the support for certain platforms in the
>hands of those interested in maintaining those platforms. (QNX, BB10,
>for example?)
>
>Being able to produce packages for those platforms has the same
>qualifications. We cannot add additional T1 platforms if we cannot
>generate installation packages for those platforms.
>
>So, we need this infrastructure in place anyways, and there's no need to
>stop that right now. And it _is_ useful to have two setups right now, as
>we more clearly see what needs to be done to bring the two together.

The problem is that we are testing two sets of opensource Qt5 packages, even though we are presumably only going to release one of those.

This testing takes almost twice the time of testing one set of packages, and some (most?) of us who are doing this testing are already struggling to muster the motivation for this task as we're leaving Nokia in less than three weeks time and are uncertain of how much (if any) time we'll be able to devote to Qt5 after that, or even whether we'll be able to keep earning a living somewhere within Qt's ecosystem.

The two sets of packages are still being generated using different scripts and differently configured infrastructure, and therefore have two different, but partially overlapping, sets of bugs.

I can't see how this duplication of effort is helping us to reach the Qt5 Beta milestone any quicker (actually quite the opposite given how few people there seem to be involved with Qt5 packaging), and we need to get to that milestone before anyone has time to re-house or make radical changes to the CI infrastructure.  Therefore, we should either

1) Make both systems generate packages using exactly the same scripts, configurations and environments (i.e., use copies of the same VM's), or

2) Choose one set of packages, test only those, and shut down the other system because nobody will be doing anything useful with its output.

--
Jason