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.

Restructuring MeeGo : Executive Summary

Where should MeeGo be targeted?


MeeGo Core : focus

What should MeeGo Core be delivering?


MeeGo: Systems and Processes

What else should MeeGo be delivering?


MeeGo : Evaluating MeeGo

How do we support MeeGo evangelists?


MeeGo : Lead by example

How we should walk in our customers shoes.


MeeGo and the hacker community

How do we embrace the hacker community?


MeeGo : Infrastructure

Pragmatics... what services should we run?


MeeGo :Restructured

How could we approach this?

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)

Core

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.

SDK

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' http://mer-l-in.blogspot.com/2011/04/meego-de-that-is-how-you-do-it.html

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.

Futures

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.

Mini-Glossary

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." (https://meego.com/about)

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;

Proposal:

Support the MINT (MeeGo Integration Tools) project

Deliver a Vendor Manual