Bearing in mind that all of this is 100% permissible anyway; we are simply
asking "is it still a MeeGo app" if you build using the community managed libs.
I think we're proposing that apps that build using APIs in the MeeGo Core *or*
in MeeGo Extras[1] are allowed to be called MeeGo apps.
Again this allows API migration to and from Core. A deprecated API can (not
must) be moved to the surrounding community area. A new API in the community
surrounds can be moved to core.
[1] Extras is the name used for individual apps. Months ago I proposed
"Surrounds" which is a more formally managed set of supporting apps/libraries;
python would be a great example.
This would allow us to raise the bar here (ie proper "maintainer" roles) and not
upset all "Extras" apps developers with extra QA/responsibility burden.
On 13/09/10 20:53, Quim Gil wrote:
On 09/13/2010 12:04 PM, ext Alexey Khoroshilov wrote:
It sounds reasonable to me. Keeping all non-Core dependencies within
each application package would be the best and the most clean technical
solution of many issues, but it has some drawbacks (as it was discussed
in the thread):
- potential conflicts of single instance services;
This is why having MeeGo Extras within the MeeGo project as a reference
is more useful than having no reference at all. The Extras maintainers
must follow the MeeGo unstable releases and make sure the packages
maintained there just work. If Vendor X needs to provide packages that
are not part of the official MeeGo, their default reference will be
MeeGo Extras.
+1
<snip lots of stuff I agree with>
- lack of tool support that is required to make the approach easy-to-use
for application developers.
If an app developer is looking for the easy-to-use then they must go for
the official APUIs and SDK, which will probably include an easy way to
publish to the AppUp, Ovi, etc.
Developers that decide not to go through the official route can still
find a reasonably easy process to get their packages at MeeGo
Extras-devel, and from there promoted through the QA process. Hundreds
of app developers have done this already at
http://wiki.maemo.org/Uploading_to_Extras-devel
The MeeGo Community OBS might make this process even simpler.
It will for sure.
It is also likely to be part of the SDK design AFAIUI.
- Should MeeGo Extras packages be compliant themselves?
Define "compliant" in this context, please. :)
Only need MeeGo Core[2] and MeeGo Extras/Surrounds to build
[2] I assume Core includes the UXes; Niels and I are setting up project
structures today.
- Should we impose MeeGo Extras package naming scheme to MeeGo vendors
and vice versa? (Otherwise, different names of the same package may lead
to issues with simultaneous installation of applications depending on
that packages)
See my point above about having Extras as a reference and place to
negotiate solutions to conflicts and avoid the lazy/ugly hacks.
If vendors want an extra API then they get it into Surrounds first; then
eventually into core?
- Should we have several grades of MeeGo compliance applications? And
what is a purpose of the "MeeGo compliant application" concept?
For clarity, I would restrict the word "compliance" to the official
MeeGo compliance based on the official API. "A MeeGo compliant app runs
on any MeeGo compliant device". If we dilute this we are opening a
Pandora's box.
The MeeGo Extras stable repository would contain apps tested to work on
top of official MeeGo releases. No "compliance" word needed: they are
"extras".
Vendor specific compliance requirements not shared by the rest of MeeGo
have nothing to do with MeeGo and are out of scope here.
So maybe my proposal is a bit stronger.
Who keeps saying "MeeGo is the community" ... I'm sure I've heard that
somewhere...
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
