Hi,

I went through the MeeGo 1.1 Compliance Specification
(v. 1.0.99.4) with people from Nokia MeeGo team.

Comments we wanted to highlight:

1. Compliancy principles (and ABI), section 1.4.1.1.
The compliancy principles regarding ABI are not clear. Is the
target to have one ABI per CPU architecture (like ARM v7) or
are multiple (accepted) flavors possible (like ARM v7 hardfp
and ARM v7 softfp)?

Additional questions
        a) is the ABI promise over releases stated somewhere in the document?
        b) how long an ABI is guaranteed to stay?

Perhaps MeeGo API and source level compatibility would be adequate for 
1.1 and the (ARM) ABI story could be clarified for 1.2. specification.

2. Stack based compliancy and component versions
The stack based compliancy seems to be too strict on what changes can
be done. It forbids any behavioral changes which is not good. However,
it should be possible to add *any* changes (with clear changelogs) as long 
as the functionality (API and/or behavior) provided by the reference 
implementation is not harmed. The wording should be so that it encourages
to contribute the changes to MeeGo/corresponding upstream projects.

The spec. is not clear about how package version numbering should be handled.

3. MeeGo API
The future compatibility is vague as the release cadence of major number
releases is not known. Interface management policy is not known either
(i.e., how to mark a to be removed interface 'deprecated' etc.).

4. Platfrom API
Platform API is not targeted for application compliance and no guarantee
whatsoever should be given. The whole Platform API can be dropped
from the compliancy specification. The only supported application API is
MeeGo API.

5. Web Run-Time
No need to mention WRT separately (section 3.6 + other places) either. Aligned
with previous item (4.) Bottom line: remove sections 3.5 and 3.6 and put focus 
on
MeeGo API applications.

6. Appendix A: Core OS packages
We should aim for very compact core OS and let MeeGo users be able to 
cut 'dep' packages away (when possible). Therefore, the compliancy should
only explicitly require 'core' packages and not mention 'dep' packages.

7. Editorial issues
There are plenty minor ones, these will be sent to Mats directly.

-- 
Best Regards, Mikko
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev

Reply via email to