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

Benefits:

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).

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?"

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.

Proposal:

• 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.

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:

Surrounds

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.

Structure

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?

PPAs

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.

Surrounds

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.

Fremantle

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

Are Intel subverting MeeGo.com?

Well... there's a "challenging" blog title :)

Please read on and allow me to explain.

Intro

So what's making me risk offending one of the powerhouses behind MeeGo?


First off, let me say that I think the answer is "No"; but I do think there's a problem and it should be solved.


So having hopefully gotten your attention; what's the problem? Well, quelle surprise, it's that inconvenient "openness" again.


MeeGo is an open distribution; I don't think that's really in doubt. However there have been many discussions on what makes something open and I'd like to add another: "Inclusiveness".


For the record : In the remainder of this post I've included issues that I've seen raised that I may not personally support.

Issue

The question is ... who gets to use the builds that are produced at meego.com? Well, technically "anyone", but practically "only people who've bought recent Intel hardware".


Why? Because the MeeGo.com builds are optimised for the Intel Atom processor; not a generic x86.


So what's the impact of this?


Pros: Less CPU usage for some functions (3D and audio codecs AFAIUI get +20% performance on certain tasks)


.... that's it


Cons. Well machines with a non-Atom CPU running MeeGo netbook edition may boot up but often fail to run. Additionally non Atom machines can't easily develop for MeeGo (eg the image building app uses ssse3 instructions inside somewhere.)

Impact

If a developer wanders over to look at MeeGo and sees that she needs to buy an Atom netbook to run it then: "Oh, I need special HW to run it? Ubuntu just runs on my laptop. Bye MeeGo, hello Ubuntu."


Making it hard to use MeeGo is *not* inclusive.

Details

The way MeeGo is built any binary could contain SSSE3 instructions; however which ones actually do depends on the optimisation flags used, the compiler version and the source code and and a change in any of them can add or remove instructions.


Essentially it's "random" - or at least not humanly determinable if a given application will suddenly choke on non-Atom hardware.


In irc Thiago scanned the Qt binaries to try and find any SSSE3 instructions. When he ran a quick and dirty analysis he couldn't find any SSSE3 instruction in QtCore and QtWebKit; and found a total of 4 SSSE3 instructions on QtGui - that's many 10s or 100s of Mb of binary code and only a handful of instructions.


So given the entirety of Qt uses *4* instructions there was a challenge to the "performance benefit" it offers by using these options "across the board".

Postition

Given MeeGo.com is supposed to be open and to minimise barrier to entry this exclusion seems wrong.


MeeGo is managed by the Linux Foundation and I was under the impression that we had a Linux Foundation managed build service at build.meego.com; so why are we building for exclusivity and not inclusivity?

Fairness

My understanding of the business model is that Nokia and other vendors would have an internal OBS to allow them to tailor and optimise MeeGo for their commercial product


MeeGo's model is that Intel, Nokia and others (as vendors) have their own internal build service (OBS) to optimise for a commercial product so why does Intel get to optimise for Atom on the MeeGo.com build service?


Why do we optimise for only Atom machines on the MeeGo.com builder? Why isn't that done on build.meego.intel.com? Is Intel essentially using MeeGo.com to make "the Intel MeeGo" not "the community MeeGo"?


Obviously, as a fallback the community OBS is a potential place for this generic build but that was *not* the point. We have often been told that MeeGo *is* the community.

Counters

One point has been of the "cost" of the shared infrastructure and Intel employees having said that Intel should not be burdened with the cost of supporting other arch/platforms/builds.


There's some validity to this - and I don't think the community would object in the slightest to seeing optimisations for Atom made available *as well* as a generic build.


One question is: Is MeeGo an open and inclusive distro? Who dictates the commercial aspects of the "shared resources" and who gets to dictate what is and is not on the agenda.


One argument has been "Intel contributed the hardware and they want it optimised for their platform"; However that's not a community platform; that's a vendor specific build platform.


And are we seriously saying that a vendor producing a version of MeeGo for a non-Intel based x86 device is going to have a problem rebuilding with appropriate gcc flags?

Proposal

Add a 'generic x86' target to the MeeGo.com build architectures. This will form the basis for more inclusive MeeGo variants.


Allow the builder to create targetted binaries for some hardware; this is going to become a requirement as more hardware appears.


As we know: 'optimized for Atom' sells and attracts developers to the platform and a set of development hardware, etc..


But surely we can be "optimized for Atom" without excluding non-Atom users.


This means anyone with a non-Atom device could at least start MeeGo on eg an AMD desktop. As Arjan says: "I and several of my coworkers run MeeGo to develop MeeGo" "it's still very much intended to be a quite complete *client* PC linux"


http://lists.meego.com/pipermail/meego-dev/2010-April/001318.html
http://lists.meego.com/pipermail/meego-dev/2010-April/001392.html

Works for everyone

Well, isn't that the job of MeeGo.com?


MeeGo.com is supposed to be open and to minimise barrier to entry - lets help it do that

Conclusion

The point is that MeeGo should be doing a generic i586 build


Not Intel, MeeGo

Open Letter / Proposal to allow Maemo on the MeeGo Community OBS

This is an open letter to the whole MeeGo community and on behalf of the Maemo development community. The purpose of this letter is to ask the MeeGo community for their permission to bring Maemo build targets (currently Fremantle eventually Harmattan, Diablo, Chinook?) to the MeeGo Community OBS and to ask the Maemo development community for their support in this project.

*Please discuss on meego-community mailing list*

I would like to emphasise that this is a Maemo Community initiative and is not being pushed by Nokia.

At this point we are not aware of any similar initiatives related to the Moblin community but we would fully support any that arise.

The Maemo community has built up around Nokia devices which, in many ways, are amongst the most open devices available in their class. There is a passion for openness in the Maemo community and we know that the future for this family of devices lies with MeeGo.

Many of us are looking forward to MeeGo and are keen to transition as smoothly as possible.

However our devices are not fully open and developing for them has dependencies on vendor proprietary binaries which would need to be available on the build service. This would mean putting closed binaries on the MeeGo OBS and having a part of the MeeGo Community OBS functionality being 'restricted' to Maemo developers.

Naturally we recognise and respect that MeeGo is an open source project and there may be ideological issues in allowing closed binaries into the ecosystem (even though they're just for build/linking). We also recognise the risk of "opening the door" to closed binaries and suggest that this arrangement could be agreed as a one-time "grandfathering in" (http://en.wikipedia.org/wiki/Grandfather_clause) situation for the Maemo community.

However we also feel that the benefits of supporting a smooth transition for the vibrant Maemo development community would be worthwhile both for MeeGo and Maemo:

• developers would be able to use the OBS' natural ability to target Fremantle, Harmattan and MeeGo from a single location. This would bring more developers and their applications to MeeGo sooner.
• many of the same people in the Maemo and MeeGo community teams look after the Maemo Autobuilder and the MeeGo application OBS. Our limited volunteer time would be used more effectively on a single platform instance.
• resources earmarked for Maemo could be added to the MeeGo estate and would naturally be used at peak efficiency as Maemo demand decreases and MeeGo demand rises.
• new Maemo community Quality Assurance processes would evolve around the shared OBS and could assist the development of MeeGo QA processes.

and perhaps most important of all:

• users of existing devices could expect a significantly longer maintainable life from products built on a consolidated build service and could look forward to their applications being available on MeeGo as soon as devices become available.

The maemo.org buildservice already has a 'proof of concept' instance of the OBS which allows the Fremantle target to co-exist with a MeeGo target and we already intend to use this as a basis for the MeeGo community OBS.

The proposed solution *must* allow MeeGo community users to use the MeeGo Community OBS without any reference to Nokia closed binaries; this facet of the service should be entirely optional.

Equally the legal issues around the closed binaries require an EULA related to demonstrated possession of a relevant device. This can be handled in a similar manner to the Maemo Autobuilder service; ie registration of a serial# to a developer account.

The proposal therefore is:

• To provide the closed binaries as a build-target repository (probably DoD for those who know and care) on the community OBS.
• To grant ACL based access to this repository based on acceptance of an EULA
• To *not* require any such EULA for 'MeeGo-only' accounts on the service

I've run this by Tero Kejo in Nokia and he's very supportive of the idea.

From:

David Greaves / lbt
   Community Member and build systems guy.
Niels Breet / X-Fade
   maemo.org webmaster and autobuild owner
Carsten Munk / Stskeeps
   maemo.org distmaster
Andrew Flegg / Jaffa
   on behalf of the Maemo Community Council