2011/10/12 Andrew Flegg <[email protected]>: > Carsten wrote: >> >> We (as in the steering group) like to query the community for ideas >> on what to call the Community Edition in the future. Currently our >> splash screens says MeeGo 1.3 Community Edition which will be >> increasingily inaccurate as we're working to rebase CE on top of >> the Mer Core. > > OK, I'm confused on where you are with defining Mer's governance - > which "steering group" are you referring to? I'm talking about the CE steering group, as recently announced, we're on meego-handset, so :) > >> Some limitations: >> * Can't include trademarks or company names, such as MeeGo / Tizen, >> Nokia, etc. >> * Can't include Mer within it as Mer's a core and CE is not "the" >> Mer UX (nor is anything) > > OK, above you refer to "Mer Core" which - as you know - fits into what > I was pitching "MeeGo 2.0" would be: http://wiki.meego.com/Blueprint. > I think this is now the template for how Mer should function. However, > you also state "Mer's a core" (implying nothing more than that). > > Glossary: > > * "Mer" - a group of projects providing the infrastructure for developing > an open source, mobile Linux OS. > * "Mer Core" - a project which provides the smallest booting Linux & Qt > environment. > * "Mer Tools" - build tools and stuff on top of "Core" necessary to build > it either cross-compiled or self-hosting. > * "Mer Apps" - apps.formeego.org development, infrastructure etc. > * "Plasma Active for Mer" - a project taking Plasma Active and > delivering a Mer > build of it. > * "Handset UX for Mer" - a project taking MeeGo's Handset UX and delivering a > Mer build of it. > * "Mer Community Edition" - a polished, project aiming to deliver a > day-to-day > usable build of one or more of the other Mer projects, acting as a > reference > vendor.
Fact is that we cannot host all those things and lay bandwidth, infrastructure, legal support, governance etc to them. As stated in the mail sent to the meego mailing lists: "Initially the project will be developing a Core for basing products on and will split UX and hardware adaptations out into seperate projects within the community surrounding the Core." -- hence the "there's no "the" Mer Handset UX". There's some reasons why this split. 1) It was seen in MeeGo that reference UX'es got preferential treatment in the core, subverting any process, especially when it came to big reveals - which caused the total breakdown of a open and working requirements process 2) We want to move much of the politics out of the Mer project and motivate people to create and build their own projects, though basing on Mer, much in the same way site projects are based upon Apache httpd. - we can't and don't want to govern projects utilizing the core, let them innovate on their own terms. 3) It was seen in MeeGo that having a central governance sometimes hindered people innovating - people were seen as to having to ask permission for everything. Let's focus at what -needs- to work, a good, open governed and open developed core for people to build upon. 4) We want to make sure that any customers of the core goes through the same process of contribution - everybody is treated the same (on technical merits), noone is preferred There was a discussion about same topic some days back on IRC and the conclusion we reached was: (Vendors in here is the principle of Mer 'customers', be it hardware adaptation, UX teams, hardware vendors, hobbyists, SME's, etc) Mer project is the efforts that is the core, the activities supporting the core (like QA, release engineering, etc), and activities allowing to utilize the core better by vendors (like BOSS, MINT, mic2, etc). There was also considered the potential of somehow help projects/vendors align with Core, in terms of releases, such as "this hardware adaptation tests to work on top of Mer v2" and be referred to along with release announcements. The idea is to have the Mer project present it's functions well, allow a common project wiki space for useful activities surrounding the core, as well as extensively refer to vendors, users and activity within the Mer community - but that those activities are self-governed and projects/teams of their own. BR Carsten Munk _______________________________________________ MeeGo-handset mailing list [email protected] http://lists.meego.com/listinfo/meego-handset
