On Sat, Dec 18, 2010 at 12:12:53AM +0800, Zhu, Peter J wrote: > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Shane Bryan > > Sent: Friday, December 17, 2010 11:28 PM > > To: [email protected] > > Cc: [email protected] > > Subject: Re: [meego-packaging] Send notifications if ABI/API changes > > > > On Fri, Dec 17, 2010 at 04:02:31PM +0100, [email protected] wrote: > > > 1. list the symbols exported by your library (current package) > > > 2. list the symbols exported by your library (new package) > > > 3. compare the symbols and check for ABI breakage > > > > None of these help in the cases where there is no library between the > > applications and the services they depend on, such as DBus services. > > > > For example, oFono and connman. Until recently, there were no supported > > or maintained Qt APIs for these, so most apps that use them, do so through > > straight QDBus interfaces, which, as you know, do not have headers or > > symbols available in the build environment that are checkable like these. > > > > It's even more complicated since the services are not build requirements > > at all, just runtime install requirements (and really, as Jussi pointed out, > > not even a true requirement, as their abscence can usually be handled > > gracefully). > > > > With the recent introduction of libofono-qt, this could be improved, in > > that now this problem could be minimized to just libofono-qt and ofono > > (assuming all apps move to using it). But libofono-qt will still need to > > be tracking to specific versions of ofono unless someone owns verifying all > > functionality (which, btw, is impossible, due to differences in carrier > > services, networks, etc) or at least, looking for both name and behavior > > differences in the ofono DBus APIs. > > > Yes, for dbus service/interface changes, it must be raised by ofono MeeGo > maintainers in this case by sending the notification with detail info.
Agreed > > This problem has bit us many many times, and as of yet, I've seen only > > so-so ideas, and no true "ownership" from QA or package maintainers on > > coming up with a real solution (if one exists). > > > Package owners must do this rather than rely on QA finding bugs after it's > already in MeeGo. This only works if we (package owners and/or developers) are aware that: 1) New version is being released, triggering us to check 2) We monitor all possible ML that impact our app/package At the moment, both of these are manual actions that are prone to information overload (too many emails) and plain human error (changes/diffs too large to pick out all that could affect our apps/packages) Shane... _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
