The MeeGo IVI Working Group is still forming and has not yet defined an IVI profile. What is being released in MeeGo 1.1 is a "sample" set of applications and UI that are validated on the Intel IVI platform. I hope some folks will volunteer to provide support for an ARM IVI platform, someone has to act as platform maintainer, kernel maintainer, and in the build and test roles.
We look forward to the IVI working group helping to establish the reference platforms and definition of IVI profile for compliance purposes. regards Joel Clark MeeGo Intel IVI program manager -----Original Message----- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Carsten Munk Sent: Tuesday, October 19, 2010 10:49 PM To: Wichmann, Mats D Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] new draft of MeeGo compliance specification 2010/10/20 Wichmann, Mats D <mats.d.wichm...@intel.com>: > > There's a fresh draft up, finally: > > http://wiki.meego.com/Quality/Compliance#Specification Thanks for pushing this out, Quick run through - hope this is constructive criticism: Line 72, we really need to spell out that it is ARMv7, EABI, softfp (for 1.1) as there is emerging tendancies in industry to use hardfp too. Line 75-76, IVI is not a supported profile? Lines 127-129, given that GCC 4.5 in MeeGo 1.1 isn't exactly the best when it comes to compiler bugs on ARM and some other areas, is there an exception to compiler bug fixes as these might be needed to actually productize? Line 182, MeeGo 1.1 Xorg server actually has --disable-xinerama so we can't demand this as compliance (please verify rest on a running implementation). For GLESv2 you should require that an implementation must Provide: libGLESv2.so.2 exists (can be a symlink) and libEGL.so.1 (can be a symlink) Line 187, don't we need more than 'uses 2.6.35 kernel or later'? There should be a requirement on the minimum of options to provide on a MeeGo install for a userland to run. Lines 202-203: Have you tried to make a 'compliant' package that actually uses dots within a package name? It's against Packaging/Guidelines and we need to try this out before shipping a compliance document noone can live up to :) Lines 241-242, regarding the heated issue: I agree there's no good technical way to test for compliance with non-core-non-ux-deps right now, but I would propose we set up a work group to work on this exact issue to come up with a proper solution for 1.2 timeframe - you agree? There certainly seems to be enough people passionate about the issue and we should be able to come up with a good solution in a proper constructive work group. Lines 249-250: This doesn't ring true in my ears - MeeGo compliant app means that my app will install and run, right? I think this needs more work and specification before it should be allowed - the RPM subarchitecture stuff might be a direction but (d) must always be true or we can't rely an app being compliant meaning it will install and work on my device. Lines 262: there's also a patchlevel (.35) in current MeeGo 1.1 MeeGo Core packages: most apps will base on let's say, libGLESv2.so.2 instead of 'mesa' - is it stated anywhere that for these things, a drop-in ABI-API compatible .so is OK too? We should be careful not to shoot ourselves in the foot - app rpms will depend on libblahblah.so.1 in Requires: , not 'libblahblah' package. General comment: I think it would be wise to state something about compliant package distribution. It would be good to discourage straight-rpm downloads and encourage repositories instead due to making it possible to receive security updates of the application. And the philosophical comment: compliance document only states what MeeGo requires, not what too much about what it promises in terms of it's platform development. Let's say, if we do ABI/API breaks doing major releases or not.. Best regards, Carsten Munk MeeGo Nokia N900 hardware adaptation maintainer. _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
