2010/9/19 Graham Cobb <[email protected]>:
> On Sunday 19 September 2010 08:55:13 Carsten Munk wrote:
>> 2010/9/19 Graham Cobb <[email protected]>:
>> > Personally I don't think Staging is needed as part of the Compliance
>> > definition (it might be needed for other reasons). The rule should be:
>> > an app can depend on any other package which is maintained by the same
>> > entity (person/company/project team/whatever) and which is available from
>> > the same repository.
>>
> Of course, we can't test the "available from the same repo" bit, but that is
> no different with your proposal of having the apps built from the same source
> package.
Ah, we can test that one, given we banned standalone rpm as installation source.
What I'm leaning on current wrt compliance for 1.1:
Applications installed from a repository is only allowed source. This
is for security reasons as updates must be able to flow to users.
Only allow dependencies from MeeGo Core and optional profile in 1.1
(this is fully testable)
Applications must install into their own directory hierarchy
For 1.2 compliance, we set up a working group that has the goal of
providing test cases and organisation, compliance text changes with
the goal of allowing non-Core-non-profile dependancies.
This all under the principle: that a MeeGo compliant application
indicated for a certain version, profile and architecture MUST install
successfully on a MeeGo-compliant device running this version, profile
and architecture. This cannot be diluted.
The key problems that must be solved:
1) Managing common dependencies in an ecosystem-friendly manner
(vendors, end-users, developers)
1.1) Practical requirement: The common dependencies must follow same
model as MeeGo features with regards to maintenance and QA, security
updates. IE, someone takes responsibility and commits to maintaining
the dependency.
2) The application/packages must be machine testable ahead of
installation for MeeGo app compliance. We cannot have a team of
testers subjectively review every single application, has to be left
for the machines :)
2.1) Installation sources must be accessible to the MeeGo.com test
machinery and all devices that has Internet connectivity which allows
adding the sources.
3) Test cases must be proven to not allow non-compliant behaviour.
(It's always easy to test for your rules but for compliance, you need
to test non-compliance too)
And the wishlist
* Compliance rules and testcases that allows an application vendor to
depend on packages within his own installation source that are
non-shared with other repositories ('private dependencies')
.. add your wish here.
If you can come up with a proposal that solves these issues before 1.1
release, be my guest to present it here :)
Best regards,
Carsten Munk
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
