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. > - wasted disk space that is essential for some devices; Having MeeGo Extras as a reference helps resolving the conflicts and duplications there, instead of just pushing lazy/ugly hacks bloating users memory space. > - extra security risks in view of the fact that all instances should be > updated by all providers independently; Again, this enforces everybody's interested on having a MeeGo Extras QA process where anybody can look and report issues. And where a system is in place to demote packages, push updates, etc. > - 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. > At the same time, the MeeGo Extras way leads to some concerns as well: > - How to guarantee acceptable quality and ABI stability of shared > packages from MeeGo Extras? Is it enough to just explain to application > developer consequences of her/his choice? The last I have heard was that the idea is to have a QA process in place. See http://wiki.maemo.org/Extras-testing to learn how Maemo has been organizing the community QA process. There have been some discussion to implement a process taking the lessons learned from the Maemo experience. What you see in that wiki page may not translate directly to the MeeGo Extras QA process. Tero Kojo is the person responsible of this. See http://wiki.meego.com/Proposal_for_Community_Application_Support > - Should MeeGo Extras packages be compliant themselves? Define "compliant" in this context, please. :) > - 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. > - 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. -- Quim Gil MeeGo advocate _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
