So… lets say we have some device that run MeeGo; what else canit do? Where are the apps?
Apps – the area formerly known as “Extras”
Borrowing Andrew Flegg (Jaffa)’s mission statement for MeeGo CommunityApps: we need to ensure a vibrant and quality area for community opensource software.
So MeeGo Apps is the community app store and follows on from thesuccesful Maemo Extras.
It allows app developers to build MeeGo compliant (and other) apps anddistribute them to users.
What makes Apps different from a ‘random repository’ is the communityQA process that is applied; the objective of this QA process is topermit users to trust the apps and to deliver a collection of appsthat a commercial vendor could enable on a shipping device (as Nokiadid with ‘Maemo Extras’ on the N900).
Clearly then, there needs to be some processes (and automation) todefine how QA checks are carried out and what to do when certainevents occur. We already have a process automation sytem (called BOSS- it’s is being developed by Nokia and is essentially an integrationof various OSS libraries) – now we need to decide what processes andcriteria we use to manage and promote apps. Initially I suggest westart with the Maemo Extras process and refine that.
When we talk about process we are also talking about policy. I’vediscussed this below and quite a few of the points apply to Apps.
Now, it’s not yet clear what OBS targets Apps should buildagainst. Currently we have:
These correspond to the MeeGo Core and then a number of UXes. Howeverthere are plans to consolidate them in the main MeeGo OBS – but howshould the Apps area look? Should a handset user be presented with appswhich were only intended to run on a netbook? OTOH is this anything todo with the repo and build target – should it be determined bymetadata and selectively presented by the download application?
Well, until this is resolved, an app developer simply needs to enableeach target that the app supports to make it available in thatrepository.
I think the discussion up to this point is fairly simple anduncontentious; we can start to address the issues mentioned and just get on with it and start to deliver MeeGo Apps
However, as mentioned, the Apps area allows both MeeGo-compliant andMeeGo-extra applications. MeeGo-compliant apps are those which onlyuse libraries in MeeGo core/UX; MeeGo-extra apps have a little extraopen-source goodness sprinkled in… Surrounds.
MeeGo: The Linux Distro
Before I tackle ‘Surrounds’ lets step back a little:
Since MeeGo was announced around a year ago I’ve been interested inhow development happens around MeeGo as well as in the centre. Thefollowing is intended to be a discussion document; there are clearlysome large gaps and I expect some of my proposals to be shot down -but I really hope that only happens when better ones are proposed!
In order to address this I think it’s important to ask… what is thepoint of MeeGo? Well, IMHO, MeeGo is primarily a modern linux baselineupon which commercial mobile computer products can be delivered.MeeGo’s main customers are not end-users – they are device vendors;*they* should be the focus of our core engineering team’s design,delivery and QA effort.
So MeeGo clearly has a focused development area with the main OBSsupporting the development and delivery of the MeeGo core systemsoftware and reference UXes.
Of course MeeGo is also capable of being a wonderful and open linuxdistro in its own right. However I personally think that to be asuccess, the MeeGo core needs to focus on the primary goal and allowmore of the “linux distro” side to be managed as a surroundingproject.
Incidentally, in my day job I care a lot about how MeeGo presentsitself to us as a vendor. I think it would be a good thing for MeeGoto have it’s own “reference product” built around the core that itoffers to vendors. This would expose issues like:
- How does MeeGo communicate significant upcoming changes to it’scustomers?
- How do we deal with package naming clashes?
- How much of MeeGo is needed for compliance vs the parts that areneeded to make a reference implementation?
- With more than one community product: how connected are devices?
So, ‘Surrounds’ is a proposal that aims to provide a collection ofopen source libraries, tools and applications that support thebuilding of collaborative bazaar-style applications and yes, maybeeven MeeGo distributions.
Whilst I don’t think this is an immediate change, I do think it’s aninteresting direction for MeeGo to take that may allow more focus onthe core deliverables.
In the meantime lets look at this “extra open-source goodness” Ipromised:
As we know, the open source world is a world of sharing; we regularlystand on the shoulders of our peers and it’s considered very bad tasteto just ‘bundle’ a library into a monolithic application. (Notice howI didn’t mention any kind of compliance programme by name – aren’t Igood!)
Surrounds provides a collection of libraries and tools that encouragesthis best practice way of working in MeeGo and delivers MeeGo-extraapps. The most obvious area would be for languages like perl, pythonand ruby. These languages have large numbers of useful libs thatclearly are not going to be present in core MeeGo. Of course therewill be many other tools and applications that would also be at homein Surrounds.
Over time, packages may migrate into core MeeGo and equally, some aregoing to be deprecated. Hopefully Surrounds makes both of thoseactions a little easier but we do need to decide how we handledeprecation/promotion of applications/libs between core and Surrounds.
There are many complexities when dealing with a collection of packageslike this:
QA and Releases
The fundamental question is “How is Surrounds QA’ed and released?”.
This is a significant undertaking and needs a lot of resource andusers. This alone means that Surrounds should probably start offslowly and ramp up as MeeGo users and developers arrive in largernumbers. The important thing is to prepare for the main issues we’relikely to face.
I propose that Surrounds is actually only populated on an “as needed”basis; tools can be submitted directly but libraries have to be neededby a tool or by an application submitted to the Apps area.
Upgrades and concurrent installations
For example: let’s look at a device that has MeeGo 1.2 installed on itand an application “Wowee” built against an imaginary libvisual-1.0which is in the Surrounds-1.2-A stable release of Surrounds.
9 months later many libraries have been updated and developerswant to use the latest versions… it’s time to release a newversion of Surrounds-1.2. Sadly libvisual is up to version 1.0awith a minor tweak which would break Wowee; not only that butthe Wowee developer has gone awol (so there’s no-one to testit) and no-one’s stepped up to update it. Even worse there are50,000 users using Wowee which is working like a dream.
Looking at the large number of apps in Maemo Extras I thinkproblems like this will arise and are beyond the resources ofthe community to handle at this point.
A technical solution may be that when Surrounds-1.2-A is installed itgoes into /opt/surrounds/1.2-A/… and any apps use the appropriatepath to find their dependencies.
This allows apps that use libraries from Surrounds-1.2-A andSurrounds-1.2-B to be installed concurrently even if they usedifferent versions.
I’m not sure how Surrounds-1.2 handles upgrades from MeeGo 1.2 to 1.3.
The message however is that there are many issues like this that itwould be good to identify in advance. Just ask a maemo developer aboutthe “optification” hack
Porting vs Maintaining : A MeeGo partner
When it comes to populating Surrounds we need to look to the largerlinux ecosystem.
Some tools and libraries will have comitted maintainers who have timeto monitor their packages and fix bugs and security issues in a timelymanner.
This is the classic distribution ‘maintainer’role.
Some libraries won’t. Developers will simply need a particular libraryand ‘grab’ a source rpm that looks like it’s good-enough. They throwit at the OBS and a few minutes later have an installable package fortheir application. This is what happens in Maemo Extras.
I call this activity ‘porting’.
The problem arises when another developer does the same thing afew weeks later with a slightly different version of thepackage. This may cause the original app to fail.
Equally, none of those developers want to commit to maintainingthe library. So when a security issue arises, no-one is readyto update the package.
I’m actually a little concerned about prolific porting – and sadlythis is the bit that gets the fame and glory : “look how many packageshe’s ported”. The truth is that this doesn’t bode well for MeeGo inthe long run.
My suggestion for this group of packages is to nominate an upstream orpartner distro with a good security record and a wide base ofpackages. Surrounds releases would closely track this distro (and willlikely differ from core MeeGo). Packages taken from this distro wouldbe fast tracked as ‘ported’ rather than ‘maintained’ and only minimalpackaging changes would be allowed. This would allow Surrounds toleverage the partner-distro’s security efforts (and hopefully offerbenefits to the partner in return).
For obvious reasons I propose openSuse as the partner distro. (For therecord I’m a Debian guy – but lets be sensible here!)
For equally obvious reasons this is a political minefield
Some random policy questions:
There are a lot of policy considerations for the community; some Iwrote in a bit of rant (forgive me Shane). Some apply to Surrounds andApps, some to the OBS in general
- Licenses: OSI only licenses? GPL3 (considering the “promotionto core” target).
- People: What’s the process for absent devs? If someone says”hey, lbt, let me upload a new version of that library Shaneuploaded” … do I just let her? What if there’s a securityissue in it? What if you’ve not been seen in 3 months? Domaintainers need to demonstrate reliability to handle timelyupdates?
- Legal : Do we accept mp3 players? libdecss? What about porn?What about apps with a rather rude splash screen? Any patentissues? (Don’t forget the system physically lives in the”land of the free” so is subject to state seizure by theRIAA).
- Commercial: I’ve had commercial organisations enquire about usingthe community OBS. I’ve had them ask to sponsor it. How do we dealwith this? My first reaction is “no commercial work”… but why not?
- Quality: Do we insist on a valid bugtracker being identifiedfor all Surrounds packages? Must it proxy via a bmc#?
- Packages scope: Where’s the ITP?
- Can we rebuild MeeGo with some different compiler flags (thinknon-ssse3 … yay … I can run MeeGo on my AMD desktop at last!)
- Do we sign any of the community repos? What does that mean?
- Acceptable Use Policy : at what point do we ask users to stopdoing what they’re doing?
- Non-MeeGo targets? When Smeegol becomes Sogmeel will we allow itto be a target?
Again the message is “there’s a lot to think about”.
The Community OBS
We have a MeeGo Community OBS already; and it builds apps for MeeGo.
It is currently managed by Niels Breet (X-fade) and I (lbt) – but weneed more help. In part this whole post is a way to structure whatwe’d like to achieve and to make it easier to identify tasks.
So what project structure do we need? We’ve not assumed MeeGo at thetop level namespace to allow us to support additional distros such asFremantle and hopefully others.
One common use for structure is to provide a QA route. Packages gofrom some sub-project in a developer’s home: area to a ‘Team’ area andthen into a Testing area. Each transition is subject to policy andquality checks. Defining these workflows and structures correctly willmake life easier.
It makes sense for teams to have collaboration for things like KDE,Gnome, Python, LibreOffice, Emacs etc. This would allow more thoroughtesting to take place before releasing either to Surrounds or Apps
However, what’s needed to form a team? Can anyone just step up andclaim Team:KDE or should we ask for some relationship with upstream?Do we just want to assess a proposal? Who does the assesment? Do weannounce this and give time for the community to raise objections orconsiderations?
The general policy for *home* projects is “OSI, nothing illegal anddon’t take the piss”. We may (or may not) need a more formal one
Certainly these PPAs offer developers a huge amount of freedom. Theycan start by uploading and building a package in a “home” directory(which can have a structure underneath it for multiple projects). Thiswill allow them to build against any of the main targets; anygroup/community projects or even any other community member homeprojects. Oh, and they can use each others code as a baselinetoo. Once built the packages are automatically published to a repo onthe community downloads server.
AFAIUI this is a lot like the Ubuntu PPA solution (hence the heading).
At that point developers can stop if they want. They have a completeset of repositories (1 per subproject). No painful QA processes forthem and no ‘fragmentation’ for the MeeGo community. But equally theserepo(s) will needed to be manually added to a device in order for itto appear in any apt-get/zypper/yum etc. Oh, and the Apps downloaderteam really should pay attention here.
A huge benefit here is that to for a user to get at a developmentversion of an application they use a specific repository, not amishmash of randomly unstable packages (like the Maemo Extras-develarea).
What MeeGo targets do we support?
MeeGo 1.0? Really? Does anyone use that?
MeeGo 1.1 and above make sense. But what architectures? As released isfine – but what if there are community rebuilds of non-ssse3?
Also, when MeeGo releases distro updates, do we just rebuild all apps?What happens to QA at this point?
One area to look at is how often we import MeeGo snapshots – and incurthe rebuild cost for any projects targetting them.
Frankly I’m a bit fed up that after a year I can’t run MeeGo on mydesktop. It has an AMD phenom chip and an ATI card – both wellsupported in the opensource world. It’s time to build a communityMeeGo
Do we need a community version targetting the DublinBook? What aboutthe O2 Joggler? Are there any policy issues here? Can anyone ask forthis – there’s potentially a lot of resource tied up doing this kindof rebuild.
What projects are needed in the Surrounds area? Certainly someunstable->testing->stable cycle makes sense; but this is not likely tobe finalised until the workflow is understood.
The Fremantle migration. Mmmm. Well it might happen at some point
Actions and Ideas
- Establish a task-force/group to coordinate and deliver activity andto act as a communications hub.
- Design and implement OBS project structures and targets for Surrounds,Apps, Teams and (suggestions for) home areas
- Design and communicate process/policy for putting packages intothese projects and migrating them
- How do packages move from Community OBS into MeeGo core
- Implement and automate stuff
- Structure and enrich the outstanding issues outlined above
- Design project structures
- Work up a proposal which sees MeeGo split into Core and Distro
- Copy this list into a Wiki so it’s actually useful