headers
jari.tahvanainen | 1 Mar 2011 11:42
Picon

Release 1.2 (feature) status today

Hello all,

 

There we earlier some discussion around MM3 status for Release 1.2 (http://lists.meego.com/pipermail/meego-pm/2011-February)

Really short summary for the discussion would be that for all the projects there were no commitment to fulfill the targets written in http://wiki.meego.com/Release_Engineering/Milestones

One can also state that commitment is not even needed for all the cases – and I have no objection on this either.

 

And here is just an update to numbers presented earlier:

-          All planned features integrated

o   Core OS 89/392=23% - including resolved 220/392=56% (Was 77/392 - 175/392 if one includes resolved to this)

o   Handset 72/303=24% - including resolved 97/303=32% (Was 71/303 - 80/303 if one includes resolved to this)

o   IVI 11/13=85% - including resolved 12/13=92% (Was 0/11 = 0% - all features are in Accepted state still)

o   Netbook – no features for 1.2

-          All data flows verified from UX

o   Handset KeyFeature Test Results on N900 http://qa-reports.meego.com/1.2/Handset/Key%20Basic%20Feature/N900/1331 having RR/PR = 86%/50% (Was RR/PR=85%/57%)

o   IVI - Basic Feature Suite on IA-Russellville http://qa-reports.meego.com/1.2/Ivi/Basic%20Feature%20Testing/Ia-Russellville/1245 having RR/PR = 52%/45% (Was RR/PR=72%/59%)

o   For Core OS I suppose the current Dataflow set would be the closest one having for N900 http://qa-reports.meego.com/1.2/Core/Dataflow/N900/1261 RR/PR = 90%/53% (Was RR/PR=90%/40%)

 

Br, Jari

_______________________________________________
MeeGo-pm mailing list
MeeGo-pm@...
http://lists.meego.com/listinfo/meego-pm
Permalink | Reply | 0 comments |
headers
Jeremias Bosch | 2 Mar 2011 15:59
Picon
Favicon

Update of Core Lib "Telepathy" 0.51 - 0.57 even MeeGo Core is frozen for 1.2 Release.

Hello all,
we are working on an Framework and Application using Telepathy. Our main
target platform is MeeGo.
We happily saw

http://www.mail-archive.com/meego-dev-WXzIur8shnEAvxtiuMwx3w <at> public.gmane.org/msg08011.html

and decided to be compliant with MeeGo Core 1.2 - which is delivering
Telepathy 0.51 as 'core compliant'.
Unfortunately there was without any further notice an update of
Telepathy 0.51 to 0.57.

https://bugs.meego.com/show_bug.cgi?id=13593

Which does change logical functionalty / provides different Interfaces
and is classically neither API nor ABI compatible.
Meaning we did porting to from previous 0.21 to 0.51 because we expected
the lib version is frozen. But now it is 0.57.
I wonder how can we avoid that there is not another update randomly
coming along the way to 1.2 Meego Release?

Don't get this wrong, the 0.57 Version seems seriously better than 0.51,
we are glad of having it updated. But
we want to secure that for future updates of any Core Compliant Lib
there is at least a 2 Weeks notice before
such an update esp. when core is supposed to be in frozen state.

Best,

Jeremias
Permalink | Reply | 3 comments |
headers
Hindman, Gavin | 2 Mar 2011 17:51
Picon
Favicon

Re: Update of Core Lib "Telepathy" 0.51 - 0.57 even MeeGo Core is frozen for 1.2 Release.

This update occurred the week we went into feature-freeze, and contained a large number of necessary bug
fixes, so the update was allowed.  We will be keeping middleware changes to an absolute minimum, and
especially anything that is not ABI/API compatible with previous versions will be heavily scrutinized.

Thanks,
__________________________ 
Gavin Hindman 
SSG\OTC MeeGo Core Product Manager

-----Original Message-----
From: meego-pm-bounces@...
[mailto:meego-pm-bounces@...] On Behalf Of Jeremias Bosch
Sent: Wednesday, March 02, 2011 7:00 AM
To: meego-pm@...
Subject: [MeeGo-pm] Update of Core Lib "Telepathy" 0.51 - 0.57 even MeeGo Core is frozen for 1.2 Release.

Hello all,
we are working on an Framework and Application using Telepathy. Our main
target platform is MeeGo.
We happily saw

http://www.mail-archive.com/meego-dev-WXzIur8shnEAvxtiuMwx3w <at> public.gmane.org/msg08011.html

and decided to be compliant with MeeGo Core 1.2 - which is delivering
Telepathy 0.51 as 'core compliant'.
Unfortunately there was without any further notice an update of
Telepathy 0.51 to 0.57.

https://bugs.meego.com/show_bug.cgi?id=13593

Which does change logical functionalty / provides different Interfaces
and is classically neither API nor ABI compatible.
Meaning we did porting to from previous 0.21 to 0.51 because we expected
the lib version is frozen. But now it is 0.57.
I wonder how can we avoid that there is not another update randomly
coming along the way to 1.2 Meego Release?

Don't get this wrong, the 0.57 Version seems seriously better than 0.51,
we are glad of having it updated. But
we want to secure that for future updates of any Core Compliant Lib
there is at least a 2 Weeks notice before
such an update esp. when core is supposed to be in frozen state.

Best,

Jeremias

_______________________________________________
MeeGo-pm mailing list
MeeGo-pm@...
http://lists.meego.com/listinfo/meego-pm
Permalink | Reply | 0 comments |
headers
Olli Salli | 2 Mar 2011 20:34
Picon

Re: Update of Core Lib "Telepathy" 0.51 - 0.57 even MeeGo Core is frozen for 1.2 Release.


> Hello all,
> we are working on an Framework and Application using Telepathy. Our main
> target platform is MeeGo.

Hi,

while I don't have any information on how the MeeGo release process is
supposed to go wrt feature freezes and such, and am not in any way
responsible for pushing new tp-qt4 releases to MeeGo, I'd like to clear
up some of the confusion about API/ABI compatibility in telepathy-qt4.

> We happily saw
>
> http://www.mail-archive.com/meego-dev-WXzIur8shnEAvxtiuMwx3w <at> public.gmane.org/msg08011.html
>
> and decided to be compliant with MeeGo Core 1.2 - which is delivering
> Telepathy 0.51 as 'core compliant'.
> Unfortunately there was without any further notice an update of
> Telepathy 0.51 to 0.57.
>
> https://bugs.meego.com/show_bug.cgi?id=13593

First of all, the versions are 0.5.1 and 0.5.7. This is not just a
cosmetic difference, rather API/ABI compatibility is encoded in the
version number as follows:

Each version 0.5.x is backwards compatible with any earlier 0.5.x release,
but not backwards compatible with any 0.4.x release. Any 0.6.x release
will be backwards compatible all the way down to 0.5.0 as well: in
general, any release series identified by an even minor version (0.6.x
or 0.4.x) is a STABLE release series, which will be backwards compatible
with the odd-numbered DEVELOPMENT release series immediately preceding
it (0.5.x and 0.3.x, correspondingly).

In other words, 0.5.7 is backwards compatible, both API and ABI wise,
with 0.5.1. As is 0.5.8 - the current latest release. It's true that as
it's a development series (odd minor version number), we'll keep adding
features and API to it, but any such changes will always be backwards
compatible ie. we don't remove any public API/ABI or change it incompatibly.

When we need to make a backwards incompatible change in the future,
we'll only do that in a new development series 0.7.x (increased minor
version) with a new API/ABI, and also correspondingly increase the .so
version, so that both libraries can be parallel installed. We'll also
keep maintaining a bugfix-only stable 0.6.x release series which will be
backwards compatible with any 0.5.x release to get bugfixes in for those
applications which haven't yet ported to the new API/ABI, just as we're
currently maintaining the 0.4.x release series, which is compatible with
all 0.4.x and 0.3.x releases.

>
> Which does change logical functionalty / provides different Interfaces
> and is classically neither API nor ABI compatible.
> Meaning we did porting to from previous 0.21 to 0.51 because we expected
> the lib version is frozen. But now it is 0.57.
> I wonder how can we avoid that there is not another update randomly
> coming along the way to 1.2 Meego Release?
>

As described in depth above, while 0.2.1 is from an earlier stable
release series which neither 0.5.1 nor 0.5.7 is compatible with, 0.5.7
is fully backwards compatible with 0.5.1. If in fact you've found some
public API/ABI which is available in 0.5.1 but not in 0.5.7 or something
for which the valid usage now results in different behavior, then that
is a bug: in that case, please elaborate what specifically has changed
incompatibly, and we'll try to prevent any such changes in the future.

However, we've been able to at least compile and run all of the
packages ever ported to the 0.5 API/ABI in other projects I'm following
with no problems
whatsoever every time a new 0.5.x release has been made. Hence at least
the subset of the API used by the numerous
components depending on tp-qt4 in the projects I know of has remained
compatible during the entire 0.5.x release series.

> Don't get this wrong, the 0.57 Version seems seriously better than 0.51,
> we are glad of having it updated. But
> we want to secure that for future updates of any Core Compliant Lib
> there is at least a 2 Weeks notice before
> such an update esp. when core is supposed to be in frozen state.
>

Depends on how frozen you want to be. But just to reiterate: any API and
ABI in the older
integrated 0.5.x releases is available compatibly in newer 0.5.x and
future 0.6.x releases, despite
any other unrelated API additions, so applications shouldn't need to
worry at all about the library being updated - they don't even need a
recompile to work with the new library.

All telepathy-qt4 upstream releases are always announced on the
telepathy@... mailing list, and we don't directly push
them to MeeGo, so you can follow that mailing list to get advance notice
about what's added and fixed in new tp-qt4 releases before the releases
are integrated to MeeGo (if they're at all - you could also follow for
the purpose of perhaps pushing for including a new tp-qt4 version if you
see a new feature you'd like to use in MeeGo development!)

>
> Best,
>
> Jeremias

Br,
Olli Salli

telepathy-qt4 upstream
Permalink | Reply | 1 comment |
headers
baris.boyvat | 3 Mar 2011 09:27
Picon

Re: Update of Core Lib "Telepathy" 0.51 - 0.57 even MeeGo Core is frozen for 1.2 Release.

Hello,

So as a summary of what Olli nicely explained: There were no
API/ABI breaks between 0.5.1 and 0.5.7 (written wrong by Jeremias
as 0.51 and 0.57).

Telepathy libraries has been regularly updated to MeeGo as the other
open source components before the feature freeze. 0.5.7 has
important bug fixes that needs to be included in the MeeGo 1.2.

There are always bugs created in bugzilla before a library is 
integrated to MeeGo. Also, in telepathy@..., 
all telepathy-qt4 and other Telepathy releases are announced.

Best Regards,
-Baris

> -----Original Message-----
> From: ext Olli Salli [mailto:olli.salli@...]
> Sent: 2. maaliskuuta 2011 21:34
> To: meego-pm@...
> Cc: Andre Moreira Magalhaes
> Subject: Re: [MeeGo-pm] Update of Core Lib "Telepathy" 0.51 - 0.57 even
> MeeGo Core is frozen for 1.2 Release.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > Hello all,
> > we are working on an Framework and Application using Telepathy. Our
> main
> > target platform is MeeGo.
> 
> Hi,
> 
> while I don't have any information on how the MeeGo release process is
> supposed to go wrt feature freezes and such, and am not in any way
> responsible for pushing new tp-qt4 releases to MeeGo, I'd like to clear
> up some of the confusion about API/ABI compatibility in telepathy-qt4.
> 
> > We happily saw
> >
> > http://www.mail-archive.com/meego-dev-WXzIur8shnEAvxtiuMwx3w <at> public.gmane.org/msg08011.html
> >
> > and decided to be compliant with MeeGo Core 1.2 - which is delivering
> > Telepathy 0.51 as 'core compliant'.
> > Unfortunately there was without any further notice an update of
> > Telepathy 0.51 to 0.57.
> >
> > https://bugs.meego.com/show_bug.cgi?id=13593
> 
> First of all, the versions are 0.5.1 and 0.5.7. This is not just a
> cosmetic difference, rather API/ABI compatibility is encoded in the
> version number as follows:
> 
> Each version 0.5.x is backwards compatible with any earlier 0.5.x
> release,
> but not backwards compatible with any 0.4.x release. Any 0.6.x release
> will be backwards compatible all the way down to 0.5.0 as well: in
> general, any release series identified by an even minor version (0.6.x
> or 0.4.x) is a STABLE release series, which will be backwards
> compatible
> with the odd-numbered DEVELOPMENT release series immediately preceding
> it (0.5.x and 0.3.x, correspondingly).
> 
> In other words, 0.5.7 is backwards compatible, both API and ABI wise,
> with 0.5.1. As is 0.5.8 - the current latest release. It's true that as
> it's a development series (odd minor version number), we'll keep adding
> features and API to it, but any such changes will always be backwards
> compatible ie. we don't remove any public API/ABI or change it
> incompatibly.
> 
> When we need to make a backwards incompatible change in the future,
> we'll only do that in a new development series 0.7.x (increased minor
> version) with a new API/ABI, and also correspondingly increase the .so
> version, so that both libraries can be parallel installed. We'll also
> keep maintaining a bugfix-only stable 0.6.x release series which will
> be
> backwards compatible with any 0.5.x release to get bugfixes in for
> those
> applications which haven't yet ported to the new API/ABI, just as we're
> currently maintaining the 0.4.x release series, which is compatible
> with
> all 0.4.x and 0.3.x releases.
> 
> >
> > Which does change logical functionalty / provides different
> Interfaces
> > and is classically neither API nor ABI compatible.
> > Meaning we did porting to from previous 0.21 to 0.51 because we
> expected
> > the lib version is frozen. But now it is 0.57.
> > I wonder how can we avoid that there is not another update randomly
> > coming along the way to 1.2 Meego Release?
> >
> 
> As described in depth above, while 0.2.1 is from an earlier stable
> release series which neither 0.5.1 nor 0.5.7 is compatible with, 0.5.7
> is fully backwards compatible with 0.5.1. If in fact you've found some
> public API/ABI which is available in 0.5.1 but not in 0.5.7 or
> something
> for which the valid usage now results in different behavior, then that
> is a bug: in that case, please elaborate what specifically has changed
> incompatibly, and we'll try to prevent any such changes in the future.
> 
> However, we've been able to at least compile and run all of the
> packages ever ported to the 0.5 API/ABI in other projects I'm following
> with no problems
> whatsoever every time a new 0.5.x release has been made. Hence at least
> the subset of the API used by the numerous
> components depending on tp-qt4 in the projects I know of has remained
> compatible during the entire 0.5.x release series.
> 
> > Don't get this wrong, the 0.57 Version seems seriously better than
> 0.51,
> > we are glad of having it updated. But
> > we want to secure that for future updates of any Core Compliant Lib
> > there is at least a 2 Weeks notice before
> > such an update esp. when core is supposed to be in frozen state.
> >
> 
> Depends on how frozen you want to be. But just to reiterate: any API
> and
> ABI in the older
> integrated 0.5.x releases is available compatibly in newer 0.5.x and
> future 0.6.x releases, despite
> any other unrelated API additions, so applications shouldn't need to
> worry at all about the library being updated - they don't even need a
> recompile to work with the new library.
> 
> All telepathy-qt4 upstream releases are always announced on the
> telepathy@... mailing list, and we don't directly
> push
> them to MeeGo, so you can follow that mailing list to get advance
> notice
> about what's added and fixed in new tp-qt4 releases before the releases
> are integrated to MeeGo (if they're at all - you could also follow for
> the purpose of perhaps pushing for including a new tp-qt4 version if
> you
> see a new feature you'd like to use in MeeGo development!)
> 
> >
> > Best,
> >
> > Jeremias
> 
> Br,
> Olli Salli
> 
> telepathy-qt4 upstream
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJNbpu2AAoJEAQQkupGanj4JgsH/jn0t14tkCb+niXumKXLK/Ft
> pWTp/gprVhTMTDnffY94QYaaWswM8FRr34uGZcAUI3rjbZO37kH8MX4dnRTK38Tw
> oztEWqMNfDEVxHQjPV9nIBvoa6uQLyJRygFzsJ9k3fXSo/QIs2jZ2P7pDGsjmJ91
> evcE4SiLp5FQlgV0TvLGcW6dN56dvGktt6kjQqs0SDv2QBxe90HpHjFX/CM4ylp3
> 0mCCJbS03n64EyigCjBgIsnB/QvgggrzBiKEkWceFHuLfGg/3WlG309iwBhe4EAz
> e0PVWu4LnJGdatoXi1+ZfxK6qGC0DJ+VZzvfRci9QSIqFUcwSsS89ECHMg2Z2qQ=
> =RoLs
> -----END PGP SIGNATURE-----
Permalink | Reply | 0 comments |

Gmane