[Releasing] Duplication of packaging effort
Tuukka.Turunen at digia.com
Tue Aug 14 08:35:23 CEST 2012
On 14.8.2012 5.46, "jason.mcdonald at nokia.com" <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,
>>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.
I am worried about the same thing. Especially since we do not have
automated release testing yet in place like we do for Qt 4.x (I mean those
release tests we run to automatically installing Qt to large number of
different configurations, running through different apps, testing compile
etc and reporting how it went etc - the platform autotests we naturally
have for Qt 5 as well.) Eventually this will be in place, but not yet for
validating the beta.
Obviously from our viewpoint it would be really great if the testing focus
can be placed more to the packages we are generating.
>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.
The setups we planned to be identical, but separately set up to test that
the 'packaging recipes' work. I think that has quite well been achieved,
and it is now just maintaining the two if we want to keep both running.
>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.
My preference for #2 - unless we suddenly get a lot more resources to do
the testing we would be better off with just one set.
>Releasing mailing list
>Releasing at qt-project.org
More information about the Releasing