> -----Original Message----- > From: Shane Bryan [mailto:[email protected]] > Sent: Saturday, December 18, 2010 2:10 AM > To: Zhu, Peter J > Cc: [email protected]; [email protected] > Subject: Re: [meego-packaging] Send notifications if ABI/API changes > > 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) > I mean owners of packages introducing ABI changes, not mean apps package owners.
Peter > Shane... _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
