[Sugar-devel] The ARM is near

[Carlo Falciola]

I agree completely on Jonas proposal to give a strong identity to Activity developed within a sugar-portability shield, 
and let me expand a bit the concept to come to a proposal for a little "classification" of activity based on supported features, testing and development.
I think this approach could lead to two different positive effects:
1.By knowing "upfront" some of the expected behaviour of an activity, the potential user will tend to be more positive about operational or functional limitation, instead of "expecting" them and later found that they are not there.
2.Activity developers will be upfront informed of what shoud be developed by themselves in order to be a good sugar-citizen, and maybe motivate himself to progressively increase the level of overall sugarization (maybe via a "check-list" effect).

Here is what comes to my mind that should/could be part of the list (ideally the list should appears in the activity download site):
1. Architecture
    1.1 "Pure": Activity developed under the umbrella of Sugar managed portable languages & libraries (a comprensive list is needed here....)
    1.2 Sugar version compatibility
    1.3 HW tested (XO, XO1.5, ......)
    1.4 Platforms supported...  
2. Sugar Features
    2.1 Journal integration
    2.2 Collaboration supported
    2.3 ....I know I'm forgotting something here...    
3. Localization
    3.1 Localizable Activity (es.: already in Pootle, pot available, ...)
    3.2 Languages availables (nice if the list is written&updated by pootle automagically)

No limitation at all on how an activity is being developed, but let's try to enforce the avalability on axpected behaviours.

Maybe the inclusion of an activity, in some of official activity selection (honey, ...) could depends, sometimes in the future, to some subset of the list...