Hello We in Qt are wondering what the best option for packaging Qt for MeeGo is. The current situation is that we release a tarball and someone, at some point, applies some unknown patches and makes an RPM.
Since Qt is a central piece of MeeGo, we'd like to have more visibility of
that process. Especially on the "unknown patches" part.
So my question is: how should this process be?
I can think of two possibilities:
1) Qt is responsible for the source tarball only, with someone in the MeeGo
team is clearly responsible for the packaging and owns the patches applied;
2) Qt is responsible for the source tarball and the RPMs for MeeGo (x86 and
ARM). Whether the actual build is done on our hardware or in the MeeGo OBS is
irrelevant.
More likely than not, in option 2, there would be no patches applied to Qt and
it would be a stock & pristine build. (Note: the current patches are unknown
to us, so this option also implies that they go away unreviewed)
To be understood: yes, we're offering to take ownership of the build. We can
just as well not take on that responsibility -- but in that case, we'll
rebuild Qt for the Nokia MeeGo devices and remove any patches we don't know
about.
Either way, we're setting ourselves up for executing QA on the MeeGo reference
platforms (continuous integration, regression testing, release testing). We
cannot provide the same level of QA or hardening for other devices.
So this is a question to all: what is the preferred method?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
