Sunday, 7 August 2011

Restructure MeeGo : By Installments

I've just published a series of articles that reflect my thoughts on
improving MeeGo and setting some directon. This outline should help navigate.

Wednesday, 3 August 2011

MeeGo :Restructured

Of all these posts this one is the biggest strawman. It is not a concrete proposal... more an exploration of possible structures.

Development and Maintainance Projects.

(note ... the term "native packages" is explained at the bottom)


Packages needed to create a MeeGo image that boots to a bare X/Wayland screen (with no applications) on a reference device (eg ExoPC). Middleware packages driven by the IVI, Tablet and Handset verticals are in the scope of Core. Reference UXes are not.

Focus is on providing a minimal set of packages to allow a product be built upon. Everything required for compliance and very little more.

"I can build a compliant product from the source released from this area."

Question: How to manage the reference device Hardware Adaptation (HA) without giving special treatment?

Primarily a maintenance project with few native packages.

Tools, build-root and toolchain

Packages needed by developers to compile and create MeeGo images: gcc, spectacle, gdb, make etc.

Note that some tools like mic2 that need to be supported on non-MeeGo platforms (SuSE, Debian, RHEL/Fedora, Ubuntu etc) may be better placed in the 'External Tools' project.

Primarily a maintenance project with few native packages.

Tied tightly to Core release schedules.

Distro : Apps + Surrounds == "MeeGo, the distro"

MeeGo isn't a distro - but for the convenience of the hacking community of users on MeeGo devices it should have one. This area provides packages for apps and upstream libraries required to support them like emacs, vim, python etc. It would be made up from Apps and Surrounds. MeeGo should be the reference to be developing on for MeeGo

Surrounds is primarily a maintenance project with few native packages. Very similar to typical distros.

Apps is primarily a development project with native packages.

Related to Core releases.


Packages needed to develop Apps for MeeGo.

Primarily a development project with native packages.

Related to Core release schedules.

External Tools and Systems

Packages, documentation and IT information for build and deployment systems/packages used by MeeGo and vendors. Typically intended to run on OSes other than MeeGo. Scope includes OBS, Bugzilla, BOSS, OTS, mic2, REVS, IMG

A mix of maintenance and development packages.

Reference Tablet UX, Handset UX, IVI UX

Packages providing a reference UX layer that can be built on top of the Core. No Core packages can be touched. These projects are intended to be used not just as reference implemenatations but also as reference working models.

Requests and bug-reports to Core from the MeeGo UX project should not be treated any differently to a customer project developing a closed UX.

It would make most sense to develop the UX as an aspect of an integration project.

Primarily a development project with native packages.

They could have an release schedule independent to Core (as a vendor would).

Multiple Hardware Adaptation Projects

Community or openly managed packages needed to adapt or supplement Core to boot and run to the same level as Core on individual devices such as ExoPC, IdeaPad, N9* etc. Working with Core and a suitable CE project would be a good approach that would exercise problems faced by vendors with multiple hardware devices.

A mix of maintenance and development packages.

Integration Projects

Eventually these projects should support MeeGo overall by highlighting and helping to resolve interoperability issues based on different MeeGo releases or form-factors.

Handset Community Edition / CE

Packages from Core, the N9* HA and one (or more) Reference UXes as well as CE-specific packages.

The CE project acts as a 'Reference Vendor'

Tablet Edition

As with the Handset CE but using different HA projects. The ExoPC MeeGo images should be released by this project.

This project too should be contributing to the 'Reference Vendor' concept.

IVI Edition

As with the Tablet Edition but for IVI.


What else? Well how about some future gazing?

MeeGo Python

A set of packages supported by MeeGo. Device vendors who see the value in QML apps with python as the underlying language may include this in a "Compliant" device under an appropriate "MeeGo" label.


native packages

MeeGo tends to use upstream packages wherever possible; but of course some areas will develop new software - these packages are known as 'native' packages since the code and the packaging are managed at the same time.

MeeGo : Infrastructure

As mentioned, we want MeeGo projects to use and validate the interfaces and procedures we expect our customers to use. To support this we should provide an operating environment to enable that goal.

An accident of history means the infrastructure we use is already set up in a way that would allow us to replicate some aspects of a vendor's view of MeeGo; we should take advantage of this and as well as clarifying the organisational lines between projects we should strive to replicate the technical interfaces too.

In order to support this new project setup I propose we *don't* change our infrastructure in any significant way.

One key objective (IMO) is to help vendors deliver MeeGo products. This means ensuring that when they deploy systems like OBS, OTS, Bugzilla, BOSS, REVS and others they can get up and running quickly. It also means that they should be able to interoperate smoothly with the MeeGo projects identified above.

We have 2 OBS deployments - we should expand this to include additional systems such as Bugzilla and we should live through the "remote system" issues we expect customers to face.

MeeGo and the hacker community

We know that : "The MeeGo project provides a Linux-based, open source software platform for the next generation of computing devices." (

So from that I suggest our target customers are pretty obvious: Device manufacturers. Not individual OSS community hackers.

I suggest that we hackers (I consider myself a community hacker as well as a paid MeeGo contributor) should approach MeeGo by recognising that:

MeeGo is not aimed at us -- Sorry but it's not.

Think about it - we don't want it to be aimed at us. We want devices running MeeGo that we can hack. So lets help make it super-attractive to device vendors; then we get to buy their hardware and do what we do best ... hack on it!

Having another Debian/openSuSE/Fedora isn't going to help - if device vendors wanted this then they already exist. MeeGo *has* to be different.

But this doesn't stop us from building cool stuff using MeeGo. Nothing is stopping us from contributing back.

However, by letting MeeGo Core focus on delivering to device vendors we in the hacker community can set up projects like the N900 CE where we have *much* more freedom to construct a real distro. MeeGo Core by itself is not much fun - CE is where the cool stuff happens ;)

MeeGo : Lead by example

One of MeeGo's biggest failings IMHO is related to its customers.

We expect our customers to work with us and against our systems: OBS, BZ etc - but do we even know how that 'work with us' is supposed to work?

We expect our customers to track bugs in our Bugzilla and link to their private Bugzilla. How exactly?

When a problem is seen in MeeGo we expect a bug report and/or a patch - yet we can't even make that work ourselves; our UX team are granted special rights that customers don't have. Certain patches appear referencing private bug trackers (eg B.O.O bugs) - if Intel can't get this right then our customers have no chance. The only way to solve this problem, and to keep on top of it, is to ensure that significant parts of the MeeGo project act as if they were external customers - still very much a part of the open community but experiencing the social and technical interfaces that we expect customers to use.

I propose we handle this in 2 ways:
  • CE, UX and Tools to become discretely scheduled MeeGo Projects
  • Seperate OBS, BZ and REVS infrastructure for Projects and Core
    (reviewed in more detail later)
  • No special handling of any Projects (eg UX)

A more powerful long term solution is to take the opportunity that the Community Edition project offers to fulfill the role of a 'reference vendor' and openly demonstrate how effectively MeeGo can deliver. We should use this to explain, demonstrate - and validate - how real vendors should interact with the MeeGo project at all levels: features, bugs, processes, release management, communication and even infrastructure.

Essentially we should make "How to be a MeeGo Product Builder" a MeeGo Project deliverable.

MeeGo : Evaluating MeeGo

MeeGo is most likely to enter an organisation via an exhaustive evaluation process.

We need to understand where those performing the evaluation will have come from. Clearly many will have significant experience in the embedded space and there are some good projects in MeeGo supporting these experienced developers in establishing a prototype MeeGo port to their hardware.

What we're missing though is a solution that allows this 'one man hacker' type evaluation to scale into a multi-person team evaluation and demonstrate MeeGo's suitability for an international, multi-team, delivery organisation with hundreds of people.

MeeGo can do this already - for free. So why aren't we shouting about it?

MeeGo: Systems and Processes

Vendors need much more than lots of source code and a toolchain: they need clarity, consistency, guidance, processes and systems.

Whilst we've looked at clarity at the package level there are a lot more areas where guidance would be welcome; setting up an end-to-end delivery system with various organisational units is a daunting task.

MeeGo has knowledge in this area and can - and should - be delivering more of what device manufacturers (and those in the ecosystem around them) need to prepare themselves to make these MeeGo based products.

Whilst relatively straightforward, probably the most valuable initial delivery would be a consistent set of terminology. This will establish a baseline for communication and improve comprehension of the entities in the MeeGo world and how they relate to previous experiences.

We already provide and suggest some systems: OBS, OTS, BOSS, Bugzilla, IMG, GIT, REVS - the next step is to suggest how these are deployed and configured. This would improve deployment speed and reduce "time to productivity".

Following on from this we can provide information to support sizing estimates for various aspects of the deployment; from build and test systems to training.

Finally we can outline proven approaches to integration; handling code flows from GIT to OBS; bug handling strategies; managing daily and weekly snapshots; MeeGo synchronisation schedules.

This area is likely to be seen as the domain of SIs - however MeeGo will benefit from establishing a reasonably consistent approach across the board; having a 'preferred' deployment/integration solution will reduce variation and hence support costs (both to MeeGo and upstream tools like the OBS); confusion is less likely to arise from mismatched expectations; Vendors and SIs will be able to interoperate more easily;

  • Support the MINT (MeeGo Integration Tools) project
  • Deliver a Vendor Manual
  • MeeGo Core : focus

    MeeGo does deliver a great set of packages which experienced teams can use as an excellent baseline for building product.

    What is not needed is yet another general purpose linux distro where each vendor has to interpret the structure and determine for themselves exactly which packages belong where.

    Instead we should be clear about what packages the MeeGo project delivers : A tight baseline which can be relied on when delivering a commercial product.

    When approaching MeeGo it is not at all clear what is required for compliance and what is part of the sample distribution that vendors are expected to either replace or significantly change.

    I suggest MeeGo package areas are clarified and redefined and that interfaces between them (especially reference projects) are made more explicit.

    In particular MeeGo should offer a Core which provides a minimal set of packages - enough to build a compliant product. The processes used in Core must obviously be appropriate for MeeGo development - but they *must* also be appropriate for customers too. Around the Core MeeGo will have a number of associated projects forming a well-defined structure around a "bullseye" and not a fuzzy melting pot. These are very much part of the MeeGo project but may only be loosely tied to the release schedule of Core.

    Tasks :
  • rip out what's not neeeded from Core
  • create UX and Tools projects
  • create an open MeeGo distro built on these projects

  • Smaller groups are easier to manage
  • Permits properly exploring the vendor:MeeGo relationship at the
    operational level
  • Much easier for alternative 'reference' solutions to take root
  • Restructuring MeeGo : Executive Summary

    Whilst the MeeGo Project has the potential to be incredibly beneficial to the linux device market it can and must do more to fulfill that aspiration.

    MeeGo is in danger of becoming "Yet Another Linux Distro". As with any venture; in order to succeed MeeGo must first identify and focus on satisfying its customers.

    Identification is not too hard : organisations involved in building devices based on MeeGo.

    Satisfying them is harder : these organisations are not your typical linux hackers, nor are they linux-friendly IT teams. They are software product delivery professionals. They care about more than just the source that comes out of MeeGo - they care about managing their build and delivery environments. The last thing these people want is to re-invent the wheel; they are under pressure and need as much help as they can get - automation, QA, progress reporting, minimising overhead and cookie-cutter deployments.

    Delivering a repo full of packages is a great start but it's not enough .. not by a long shot.

    This is the first in a series of few articles that make some concrete proposals.

    (Thanks to the community people who've helped review this : I'll put the text onto the MeeGo wiki for further comment and editing).

    Wednesday, 27 April 2011

    MeeGo DE - *THAT* is how you do it ....

    Over the past several weeks I've been hitting one concept over and over again: "reference".

    I'm talking here about the idea of a reference implementation; and I don't mean something so comprehensive that it's almost useless... rather a manageable set of information aimed at easing entry into a project.

    I've been accused of being a bit long-winded :) So let me offer a short proposal:

    Justify the DE project by extending the "DE Project Vision" to include "Be a reference vendor". Extend the deliverables to include documentation about processes, organisational layout and tool usage. Test, challenge and improve the MeeGo <-> Vendor interface.

    I put this to Carsten and Jukka a while ago and they were very positive about it - so if it sounds intriguing then here's my thinking:

    MeeGo is (or should be) aimed at vendors. So what is a vendor? Or perhaps, in this context, what aspects of a vendor are we interested in? I think the following three areas are relevant:
    • The Veneer ("Value Add Layer" if you're marketing a device)
    • Hardware Adaptation
    • Contributing Back (A phb may prefer to hear: "Influencing MeeGo's direction")
    As a vendor newly arriving at MeeGo I am going to need to work in one or more of these areas - so what do I do? What systems do I need? How do I setup teams, OBS projects? How do they interact with MeeGo? What testing processes should I use? What tools and systems are already available? How do I avoid re-inventing the wheel? How do I link to the core OBS? How do I get a feature included in the core?

    Answering these questions correctly is vital if a vendor is to effectively assess the cost of operating in the MeeGo ecosystem; and that assesment should influence their decision to work with MeeGo. Quite simply: the lower we can make barriers to entry, the more vendors will join MeeGo. Not only that; if we can identify and resolve problems with them then that will improve satisfaction. It is also worth remembering that many vendors will be new to working in the open - using the reference project may help to overcome 'shyness' be it cultural or confidentiality based.

    This is not just about vendors either. MeeGo as a project has to support the vendor ecosystem - and whilst we do want a diverse community out there, we don't want to support needless variations in process or even terminology. Providing a "suggested way of working" and ensuring that all our tools and processes work with it means that we can minimise the cost of these interactions from MeeGo's point-of-view.

    MeeGo also provides interfaces to these vendors - but has no real mechanism for reviewing or testing them (although I'd like to address that in my BoF session at MeeGo 2011). For example

    • the handling and communication of significant API changes during development;
    • simple operational communication;
    • how are vendor products supported *after* a MeeGo release?
    • how should vendors operate near releases (forks);
    • I need a change to a MeeGo component : it's not going to be accepted this release; what do I do?
    DE operates in all of the layers I mentioned but it's not clear what activity is related to what layers. I'd like to see:
    • DE provide some clarity around the three roles: particularly a review of the OBS project structure and role-specific processes.
    • Clear product-oriented and release-managed deliverables in the veneer layer with testing and automation
    • Documentation of a requirements driven approach to MeeGo core contributions
    • Documentation of a requirements driven approach to hardware adaptation

    Of course the objective of these deliverables is to support new vendors and contributors to DE/MeeGo; not to overburden the contibutors. bearing in mind that

    I think the success criteria in this ares would be if any organisation can quickly and easily setup a new initiative to thoroughly evaluate MeeGo for a new product.

    There are other areas where we can support vendors by pursuing this model; the use of the MeeGo community OBS mimics the separation between the MeeGo OBS and the vendor's internal OBS. This allow issues dealing with the relationship to MeeGo to be examined openly: what is the recommended link to the core OBS; how are vendors impacted by downtime; what's the best approach to provide a reasonably stable MeeGo base to build the 'veneer layer' on during a sprint whilst still allowing the vendor to be aware of emerging issues in Trunk.

    MeeGo also has other system tools: BOSS, REVS, IMG and OTS are freely available and were designed at Nokia using their product building expertise - how can we offer these to the MeeGo vendor ecosystem to once again reduce cost and probably more importantly: time to market. These tools are used in MeeGo core - but they are not documented or discussed (and are probably not relevant to vendors anyway since their business goals are different). Using them in DE allows increased public scrutiny.

    So here's another success criteria (for both DE and MeeGo tools): is DE using MeeGo tools to deliver their product? Do the managment reports from REVS provide useful data? Is BOSS automation effective and sufficiently low-overhead? Does OTS work in resource-limited environments?

    Finally - you have to ask what the point of the DE project is? I think if it can be held up as an example of "How to work with MeeGo" and has real deliverables beyond supporting an aging device then it provides a tangible benefit to everyone in MeeGo.

    A little post-script too : whilst I've focused on DE here this concept applies to a lot of what's done around MeeGo. Opensource succeeds because we stand on the shoulders of midgets - a *lot* of midgets. We should each aim to ensure that when we 'deliver' something to the opensource community we ask "how easy have I made it to let someone else improve on this?"

    Saturday, 12 February 2011

    What now for MeeGo?

    So Nokia has dramatically reduced commitment to MeeGo and has cited, amongst other thinks, MeeGo's inability to deliver a focussed baseline with sufficient speed. I happen to agree with this failure (and given Nokia was a significant part of MeeGo's management I don't think there's a blame issue - more a how do we fix it issue)

    Assumptions and observations:

    • MeeGo is intended to provide a viable but focussed baseline upon which vendors can build compliant products; not to be an expansive and 'complete' linux distribution.
    • MeeGo has limited dedicated resourcs and focusing them on a reduced MeeGo core will improve quality.
    • 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.
    • MeeGo core does not appreciate the difficulties a vendor has in tracking MeeGo;
    • A visibly secure development model is important to the perceived integrity of MeeGo - so visibly restricting write access to the core is important.


    • MeeGo Core is confirmed as not being a linux distribution
    • An open MeeGo project (openMeeGo?) is created on the community infrastructure to provide a reference MeeGo distribution
    • Packages not *essential* to the delivery of a compliant MeeGo Core are moved into the community OBS (emacs, vi etc - maybe even the reference UXes) where they are available for use by development teams and end users.
    • "openMeeGo" acts as a reference vendor and provides a forum for reviewing and improving the processes MeeGo uses to communicate releases
    • MeeGo community (which includes core developers) has a significantly lower barrier to entry.

    Thursday, 27 January 2011

    MeeGo Community Development: Apps, Surrounds and the Community OBS

    So... lets say we have some device that run MeeGo; what else can it do? Where are the apps?

    Apps - the area formerly known as "Extras"

    Borrowing Andrew Flegg (Jaffa)'s mission statement for MeeGo Community Apps: we need to ensure a vibrant and quality area for community open source software.

    So MeeGo Apps is the community app store and follows on from the succesful Maemo Extras.

    It allows app developers to build MeeGo compliant (and other) apps and distribute them to users.

    What makes Apps different from a 'random repository' is the community QA process that is applied; the objective of this QA process is to permit users to trust the apps and to deliver a collection of apps that a commercial vendor could enable on a shipping device (as Nokia did with 'Maemo Extras' on the N900).

    Clearly then, there needs to be some processes (and automation) to define how QA checks are carried out and what to do when certain events occur. We already have a process automation sytem (called BOSS - it's is being developed by Nokia and is essentially an integration of various OSS libraries) - now we need to decide what processes and criteria we use to manage and promote apps. Initially I suggest we start with the Maemo Extras process and refine that.

    When we talk about process we are also talking about policy. I've discussed this below and quite a few of the points apply to Apps.

    Now, it's not yet clear what OBS targets Apps should build against. Currently we have:
    • MeeGo:1.1:Core
    • MeeGo:1.1:Core:Handset
    • MeeGo:1.1:Core:IVI
    • MeeGo:1.1:Core:Netbook
    These correspond to the MeeGo Core and then a number of UXes. However there are plans to consolidate them in the main MeeGo OBS - but how should the Apps area look? Should a handset user be presented with apps which were only intended to run on a netbook? OTOH is this anything to do with the repo and build target - should it be determined by metadata and selectively presented by the download application?

    Well, until this is resolved, an app developer simply needs to enable each target that the app supports to make it available in that repository.

    I think the discussion up to this point is fairly simple and uncontentious; 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 and MeeGo-extra applications. MeeGo-compliant apps are those which only use libraries in MeeGo core/UX; MeeGo-extra apps have a little extra open-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 in how development happens around MeeGo as well as in the centre. The following is intended to be a discussion document; there are clearly some 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 the point of MeeGo? Well, IMHO, MeeGo is primarily a modern linux baseline upon 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 OBS supporting the development and delivery of the MeeGo core system software and reference UXes.

    Of course MeeGo is also capable of being a wonderful and open linux distro in its own right. However I personally think that to be a success, the MeeGo core needs to focus on the primary goal and allow more of the "linux distro" side to be managed as a surrounding project.

    Incidentally, in my day job I care a lot about how MeeGo presents itself to us as a vendor. I think it would be a good thing for MeeGo to have it's own "reference product" built around the core that it offers to vendors. This would expose issues like:
    • How does MeeGo communicate significant upcoming changes to it's customers?
    • How do we deal with package naming clashes?
    • How much of MeeGo is needed for compliance vs the parts that are needed 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 of open source libraries, tools and applications that support the building of collaborative bazaar-style applications and yes, maybe even MeeGo distributions.

    Whilst I don't think this is an immediate change, I do think it's an interesting direction for MeeGo to take that may allow more focus on the core deliverables.

    In the meantime lets look at this "extra open-source goodness" I promised:


    As we know, the open source world is a world of sharing; we regularly stand on the shoulders of our peers and it's considered very bad taste to just 'bundle' a library into a monolithic application. (Notice how I didn't mention any kind of compliance programme by name - aren't I good!)

    Surrounds provides a collection of libraries and tools that encourages this best practice way of working in MeeGo and delivers MeeGo-extra apps. The most obvious area would be for languages like perl, python and ruby. These languages have large numbers of useful libs that clearly are not going to be present in core MeeGo. Of course there will be many other tools and applications that would also be at home in Surrounds.

    Over time, packages may migrate into core MeeGo and equally, some are going to be deprecated. Hopefully Surrounds makes both of those actions a little easier but we do need to decide how we handle deprecation/promotion of applications/libs between core and Surrounds.

    There are many complexities when dealing with a collection of packages like 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 and users. This alone means that Surrounds should probably start off slowly and ramp up as MeeGo users and developers arrive in larger numbers. The important thing is to prepare for the main issues we're likely 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 needed by 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 it and an application "Wowee" built against an imaginary libvisual-1.0 which is in the Surrounds-1.2-A stable release of Surrounds.

    9 months later many libraries have been updated and developers want to use the latest versions... it's time to release a new version of Surrounds-1.2. Sadly libvisual is up to version 1.0a with a minor tweak which would break Wowee; not only that but the Wowee developer has gone awol (so there's no-one to test it) and no-one's stepped up to update it. Even worse there are 50,000 users using Wowee which is working like a dream.

    Looking at the large number of apps in Maemo Extras I think problems like this will arise and are beyond the resources of the community to handle at this point.

    A technical solution may be that when Surrounds-1.2-A is installed it goes into /opt/surrounds/1.2-A/... and any apps use the appropriate path to find their dependencies.

    This allows apps that use libraries from Surrounds-1.2-A and Surrounds-1.2-B to be installed concurrently even if they use different 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 it would be good to identify in advance. Just ask a maemo developer about the "optification" hack :)

    Porting vs Maintaining : A MeeGo partner

    When it comes to populating Surrounds we need to look to the larger linux ecosystem.

    Some tools and libraries will have comitted maintainers who have time to monitor their packages and fix bugs and security issues in a timely manner.

    This is the classic distribution 'maintainer' role.

    Some libraries won't. Developers will simply need a particular library and 'grab' a source rpm that looks like it's good-enough. They throw it at the OBS and a few minutes later have an installable package for their application. This is what happens in Maemo Extras.

    I call this activity 'porting'.

    The problem arises when another developer does the same thing a few weeks later with a slightly different version of the package. This may cause the original app to fail.

    Equally, none of those developers want to commit to maintaining the library. So when a security issue arises, no-one is ready to update the package.

    I'm actually a little concerned about prolific porting - and sadly this is the bit that gets the fame and glory : "look how many packages he's ported". The truth is that this doesn't bode well for MeeGo in the long run.

    My suggestion for this group of packages is to nominate an upstream or partner distro with a good security record and a wide base of packages. Surrounds releases would closely track this distro (and will likely differ from core MeeGo). Packages taken from this distro would be fast tracked as 'ported' rather than 'maintained' and only minimal packaging changes would be allowed. This would allow Surrounds to leverage the partner-distro's security efforts (and hopefully offer benefits to the partner in return).

    For obvious reasons I propose openSuse as the partner distro. (For the record 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 I wrote in a bit of rant (forgive me Shane). Some apply to Surrounds and Apps, some to the OBS in general

    • Licenses: OSI only licenses? GPL3 (considering the "promotion to core" target).
    • People: What's the process for absent devs? If someone says "hey, lbt, let me upload a new version of that library Shane uploaded" ... do I just let her? What if there's a security issue in it? What if you've not been seen in 3 months? Do maintainers need to demonstrate reliability to handle timely updates?
    • Legal : Do we accept mp3 players? libdecss? What about porn? What about apps with a rather rude splash screen? Any patent issues? (Don't forget the system physically lives in the "land of the free" so is subject to state seizure by the RIAA).
    • Commercial: I've had commercial organisations enquire about using the community OBS. I've had them ask to sponsor it. How do we deal with this? My first reaction is "no commercial work"... but why not?
    • Quality: Do we insist on a valid bugtracker being identified for all Surrounds packages? Must it proxy via a bmc#?
    • Packages scope: Where's the ITP?
    • Can we rebuild MeeGo with some different compiler flags (think non-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 stop doing what they're doing?
    • Non-MeeGo targets? When Smeegol becomes Sogmeel will we allow it to 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 we need more help. In part this whole post is a way to structure what we'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 the top level namespace to allow us to support additional distros such as Fremantle and hopefully others.

    One common use for structure is to provide a QA route. Packages go from some sub-project in a developer's home: area to a 'Team' area and then into a Testing area. Each transition is subject to policy and quality checks. Defining these workflows and structures correctly will make life easier.

    Team Areas

    It makes sense for teams to have collaboration for things like KDE, Gnome, Python, LibreOffice, Emacs etc. This would allow more thorough testing to take place before releasing either to Surrounds or Apps

    However, what's needed to form a team? Can anyone just step up and claim Team:KDE or should we ask for some relationship with upstream? Do we just want to assess a proposal? Who does the assesment? Do we announce this and give time for the community to raise objections or considerations?


    The general policy for *home* projects is "OSI, nothing illegal and don't take the piss". We may (or may not) need a more formal one :)

    Certainly these PPAs offer developers a huge amount of freedom. They can start by uploading and building a package in a "home" directory (which can have a structure underneath it for multiple projects). This will allow them to build against any of the main targets; any group/community projects or even any other community member home projects. Oh, and they can use each others code as a baseline too. Once built the packages are automatically published to a repo on the 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 complete set of repositories (1 per subproject). No painful QA processes for them and no 'fragmentation' for the MeeGo community. But equally these repo(s) will needed to be manually added to a device in order for it to appear in any apt-get/zypper/yum etc. Oh, and the Apps downloader team really should pay attention here.

    A huge benefit here is that to for a user to get at a development version of an application they use a specific repository, not a mishmash of randomly unstable packages (like the Maemo Extras-devel area).

    MeeGo Targets

    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 is fine - 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?

    MeeGo Snapshots

    One area to look at is how often we import MeeGo snapshots - and incur the rebuild cost for any projects targetting them.

    MeeGo Rebuilds

    Frankly I'm a bit fed up that after a year I can't run MeeGo on my desktop. It has an AMD phenom chip and an ATI card - both well supported in the opensource world. It's time to build a community MeeGo :)

    Do we need a community version targetting the DublinBook? What about the O2 Joggler? Are there any policy issues here? Can anyone ask for this - there's potentially a lot of resource tied up doing this kind of rebuild.


    What projects are needed in the Surrounds area? Certainly some unstable->testing->stable cycle makes sense; but this is not likely to be 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 and to 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 into these 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