Interesting discussion. Thank you! On 09/08/2010 09:28 PM, ext Arjan van de Ven wrote: > I think there's a more general "what is MeeGo" thing behind this.
Yes. Let's agree first in the concept and then sorting out the technical aspects will be easier. > For some, MeeGo is *the* distribution, there is only one, and because of > that, things that add to one will add to all of MeeGo > > For others, MeeGo is "the reference", where the assumption is that many > companies will make variants that they all want to call "MeeGo", but > that are all different in some ways. Here we are talking about libraries and apps. The backbone is the MeeGo official API, provided by the MeeGo Core. I guess we all agree that no matter how many variants companies and communities do around MeeGo that official API needs to be there as a minimum requirement. Well, this is a starting point. Let's look first at MeeGo Extras: If the developers targeting MeeGo Extras want to support libraries not present in the MeeGo architecture then they should be able to do so, as long as their packages work on top of MeeGo Core. And this should allow developers targeting MeeGo Extras to use those libraries. The MeeGo Community OBS and the MeeGo Extras QA process should help porting, developing and maintaining these libraries and apps not sitting directly on top of the official MeeGo API, but functional in a stock MeeGo OS. The open development of MeeGo allows the maintainers of this Extras components to test them against new releases and fix/negotiate in case of breakage. In practice, this Extras maintainers are some of the earliest and best testers of the unstable platform. Now, what about the MeeGo vendors? Those vendors sticking to the pure MeeGo stack with only some UX customization on top can benefit directly from MeeGo Extras - or their users can if they wish and their system is open enough to add the Extras repo. If they are not interested, no problem. Those vendors adding their own libraries on top of pure MeeGo can solve the problem of collisions with MeeGo Extras by assigning a top priority to their repos (I guess) or taking more drastic measures promoting their own packages and basta. Or just like the MeeGo maintainers, they can fix/negotiate with the Extras maintainers. Those vendors doing deeper changes in the fringe of MeeGo compatibility know anyway that they are playing with fire. If they want to get the benefit of Extras they will need to do some homework. If they just want a closed system without Extras input then there is no problem to solve. In any case if there is a conflict the guidance comes automatically from the MeeGo API and the MeeGo Core. The open development and the explicit willingness to sit on top of newest releases as soon as they are ready for production just makes the conflict resolution easier. > The first model is what Maemo used to be, there was only one Maemo; the > second model is what Moblin used to be, with many variants. I think there is a way to benefit from the beautiful aspects of both platforms. The versatile architecture of Moblin (compared to Maemo) was beautiful. The proliferation of application developers and community libraries (compared to Moblin) was beautiful too. > Frankly, I see MeeGo only be able to follow the second model; there is > more than one company doing products with MeeGo (heck, Novell already > has a variant), and thus there will be variants. > The moment you have variants, where you allow the variants to add their > own stuff on top, you can't have an "Extras" repository that works for > all of these variants anymore, only one that works > for the reference. But we can't stop Extras because of the variants. On the contrary, a strong and useful Extras will only help those variants to differ from the MeeGo reference only when there is a good business reason to do so. Any step you do out of the MeeGo way might cost you hundreds of apps not available to your users. Lat but not least: since the MeeGo launch and even before "open source innovation" has been a driver of this 'joint platform developed under the auspices of the Linux Foundation'. Limiting the MeeGo umbrella to the official stack and API and limiting that innovation to companies able to create their own ecosystems is imho limiting the MeeGo potential too much. And for no good reason? > And once that's the case..... you really can't say "oh but you can > depend on anything that's in Extras". Or even "you can depend on things > that are not in the required set" to be honest. I agree: the MeeGo project should put the emphasis on the official MeeGo API as the only reliable dependency. This doesn't mean that we must cut the Extras initiative pushing them out of the MeeGo umbrella. -- Quim Gil MeeGo advocate _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
