QT Packages, Repositories and PR1.2

On Fri, May 21, 2010 at 10:14 AM, Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> wrote:

>> The developer should wait for pr 1.2. At this point in time all the
>> work spent on dealing with PR1.1 is wasted effort.
>
> Which means that whole work spent on dealing with Maemo is also wasted. Nokia
> wants to be good at scarying developers out of platform?

No, it means PR1.2 will probably happen sooner than you think. If
someone wants to start implementing workaround schemes today it's ok,
but I'd personally suggest using the time between now and PR1.2 on
something that's actually going to see real use.

--
Ville M. Vainio
http://tinyurl.com/vainio

On Fri, May 21, 2010 at 9:34 AM, Ville M. Vainio <vivainio@gmail.com> wrote:
[...]
> No, it means PR1.2 will probably happen sooner than you think. If

A not-affirmative sentence ("will not be released for sure before X
weeks") may help developers to decide.

Regards

Niko

Dnia piątek, 21 maja 2010 o 09:55:29 Nicola Mfb napisał(a):
> On Fri, May 21, 2010 at 9:34 AM, Ville M. Vainio <vivainio@gmail.com>
> wrote: [...]
>
> > No, it means PR1.2 will probably happen sooner than you think. If
>
> A not-affirmative sentence ("will not be released for sure before X
> weeks") may help developers to decide.

nOKIA will not tell you that. My bet is 12 November - until that I will use
LR1.2 on my phone (LR == Leaked Release compared to PR == Public Release).

Regards,
--
JID: hrw@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

On Fri, May 21, 2010 at 10:00 AM, Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> wrote:
[...]
>> A not-affirmative sentence ("will not be released for sure before X
>> weeks") may help developers to decide.
>
> nOKIA will not tell you that. My bet is 12 November - until that I will use
> LR1.2 on my phone (LR == Leaked Release compared to PR == Public Release).

I do not need a release date, I need "a not release date"!
E.g., "our QA procedure needs 4 weeks of testing after a bug was
fixed, as the last was closed a week ago, do not expect public release
before 3 weeks, and may be delayed again".
Just to have an idea, as user I'm happy with 1.1.1, as developer I
need such information.

Regards

Niko

On Friday 21 May 2010 07:06:35 Ville M. Vainio wrote:
> On Fri, May 21, 2010 at 2:42 AM, Felipe Crochik <felipe@crochik.com> wrote:
> > As today what a developer needs to do to get an application that uses qt
> > to the end user? Is there a way to tell the autobuilder to compile
> > against the 4.5 qt and make the package only depend on it?
>
> The developer should wait for pr 1.2. At this point in time all the
> work spent on dealing with PR1.1 is wasted effort.

The rationale of working out scenarios is to have a course of action if a
similar situation arises (not necessarily with Qt or another PR). As I
mentioned previously, I agree with Niels that this is more a packaging than a
PR1.1/1.2 (delay) issue, PR1.2 will just make the symptoms temporarily go
away. In other words, do not bother with PR1.1 but bother with how you
package your packages :)


Best regards,
Attila

On Fri, 2010-05-21 at 10:00 +0200, ext Marcin Juszkiewicz wrote:
> Dnia piątek, 21 maja 2010 o 09:55:29 Nicola Mfb napisał(a):
> > On Fri, May 21, 2010 at 9:34 AM, Ville M. Vainio <vivainio@gmail.com>
> > wrote: [...]
> >
> > > No, it means PR1.2 will probably happen sooner than you think. If
> >
> > A not-affirmative sentence ("will not be released for sure before X
> > weeks") may help developers to decide.
>
> nOKIA will not tell you that. My bet is 12 November - until that I will use
> LR1.2 on my phone (LR == Leaked Release compared to PR == Public Release).

As Eero said in one previous email, no-one in Nokia knows either :)
Because it's released when it's tested. There are some guesses of
course, but those didn't go so well in the past as everyone knows.

-Kimmo

>
> Regards,

On Friday 21 May 2010 01:42:43 you wrote:
> 1. As today what a developer needs to do to get an application that
> uses qt to the end user? Is there a way to tell the autobuilder to compile
> against the 4.5 qt and make the package only depend on it?

In theory you just depend on the proper version of libqt4-dev, but it's tricky
as you might indirectly reference libs that are also newer in the SDK/new PR
so end up with a 4.6 dependency (or broken build), see below...

> 2. What is the point of the (not so few) qt applications on the
> repository that were compiled against the qt4-core (4.6)? Unless pr1.2 will
> have a qt that is binary compatible to the libs on the autobuilder right
> now these packages will be completely useless, right? I thought the point
> of committing packages using qt4-core (4.6) now was to have them ready for
> day one when pr 1.2. gets out.

Most of the applications got compiled for Qt4.6 'by accident', in terms that
they do not really depend on or need 4.6 (nor did the original author WANT
that specific version), but with current SDK setup they end up being linked
against 4.6 anyway. This is why in my previous post I said this is not
strictly a PR1.1 problem, a similar situation might arise with other packages
if not managed correctly.

> 3. The qt applications not using qt4-maemo5 are "moved" to testing. How
> are they being tested right now? They can't be tested on the pr1.1, because
> they are compiled against qt 4.6. Are they not being tested at all
> (everything is at halt); or they are being tested by people that have "pre
> release" pr1.2; or are they being tested using scratchbox environment?

AFAIK it's halted. Considering PR1.2 uses a separate repo, it makes no sense
to promote them (yet) anyway. I would not consider prerelease 1.2 as a valid
platform for community QA purposes.

> Thanks for taking the time to answer me. It has been very interesting and
> "illuminating"

Hate to be the bearer of bad news :( What we managed to agree for the PR1.2
release is that development releases starting with PR1.2 will not be called
libqt4-maemo5 as it's not that obvious that it's *really* just a version for
testing, prone to breakage and not necessarily the exact one that will end up
in the next PR. Future releases will sport the 'experimental' moniker (f.e.
libqt4-experimental, python-qt4-experimental) so it's more clear that it (and
stuff depending on it) are not meant to be promoted to end users. Not ideal,
but hopefully will reduce confusion until a better solution is found that is
acceptable for both Nokia and the community.


Regards,
Attila

On 21/05/2010 09:34, Ville M. Vainio wrote:
> No, it means PR1.2 will probably happen sooner than you think.

And we've never been so close to the release!
--
Yves-Alexis

This whole thing has been horrible from the start. I was happily
coding, learning to use Qt in a mobile environment, and then the
autobuilder got switched to a version NO ONE has on their phone. I can
build my app locally and it will run great on my n900, but as soon as
I download it from extras-devel, it seg faults. So I thought I would
wait until PR 1.2 was released, which was supposed to be '2 weeks' ...
now it's not coming until November ?!?!

It's obviously not working right (there are several apps that I use
that are un-updatable or now crash), is causing a lot of bad press,
frustrating developers, and making users confused and angry.

Please put up a wiki page detailing EXACTLY what needs to be done for
a package to work properly using the new autobuilder, if that is even
possible. Otherwise -- please, please please just put it back the way
it was. Just make it work.

I'll wait a little longer for this to get resolved, but if it takes
too long I just might ebay my n900 and go Android.

Sorry for the rant but sometimes it feels good to get things off your chest !

Cheers,

- ianaré sévi



2010/5/21 Attila Csipa <maemo@csipa.in.rs>:
> On Friday 21 May 2010 01:42:43 you wrote:
>> 1.    As today what a developer needs to do to get an application that
>> uses qt to the end user? Is there a way to tell the autobuilder to compile
>> against the 4.5 qt and make the package only depend on it?
>
> In theory you just depend on the proper version of libqt4-dev, but it's tricky
> as you might indirectly reference libs that are also newer in the SDK/new PR
> so end up with a 4.6 dependency (or broken build), see below...
>
>> 2.    What is the point of the (not so few) qt applications on the
>> repository that were compiled against the qt4-core (4.6)? Unless pr1.2 will
>> have a qt that is binary compatible to the libs on the autobuilder right
>> now these packages will be completely useless, right? I thought the point
>> of committing packages using qt4-core (4.6) now was to have them ready for
>> day one when pr 1.2. gets out.
>
> Most of the applications got compiled for Qt4.6 'by accident', in terms that
> they do not really depend on or need 4.6 (nor did the original author WANT
> that specific version), but with current SDK setup they end up being linked
> against 4.6 anyway. This is why in my previous post I said this is not
> strictly a PR1.1 problem, a similar situation might arise with other packages
> if not managed correctly.
>
>> 3.    The qt applications not using qt4-maemo5 are "moved" to testing. How
>> are they being tested right now? They can't be tested on the pr1.1, because
>> they are compiled against qt 4.6. Are they not being tested at all
>> (everything is at halt); or they are being tested by people that have "pre
>> release" pr1.2; or are they being tested using scratchbox environment?
>
> AFAIK it's halted. Considering PR1.2 uses a separate repo, it makes no sense
> to promote them (yet) anyway. I would not consider prerelease 1.2 as a valid
> platform for community QA purposes.
>
>> Thanks for taking the time to answer me. It has been very interesting and
>> "illuminating"
>
> Hate to be the bearer of bad news :( What we managed to agree for the PR1.2
> release is that development releases starting with PR1.2 will not be called
> libqt4-maemo5 as it's not that obvious that it's *really* just a version for
> testing, prone to breakage and not necessarily the exact one that will end up
> in the next PR. Future releases will sport the 'experimental' moniker (f.e.
> libqt4-experimental, python-qt4-experimental) so it's more clear that it (and
> stuff depending on it) are not meant to be promoted to end users. Not ideal,
> but hopefully will reduce confusion until a better solution is found that is
> acceptable for both Nokia and the community.
>
>
> Regards,
> Attila
>

>I'll wait a little longer for this to get resolved, but if it takes
>too long I just might ebay my n900 and go Android.

You can also compile it yourself and create your own repository ...
easier to manage, and do the trick ... and switch back to the maemo
repository again when everythings will be fixed.

--
Benoît HERVIER, Khertan Software - http://khertan.net/