This is a list of things the ARM community should maintain in MeeGo:

= QEMU =

The qemu-arm that is employed on build.meego.com and published on tools repository

Upstream:

Maintainer: ?

= ARM patches for GCC =

Upstream:

Maintainer: ?

= OBS Cross packages =

Upstream:

Maintainer: ?

= ARM porters =

People committing to fixing ARM build failures in OBS

List of people with build.meego.com accounts:

* someone

List of people with build.pub.meego.com accounts:

* someone

= Add more =

2011-06-20T06:01:18Z

Stskeeps:

There has been some confusion on the N900 Community Edition work in relation to the MeeGo project. This page helps to answer some of the questions that occasionally does pop up in order to clear the air.

= What is the Community Edition work about? =

From [[ARM/N900]]:

''The Community Edition (CE) is an 'overlay' constructed above the current core MeeGo 1.2. The Community Edition project is working as a draft of a MeeGo handset image, to make possible the MeeGo development on your N900 hardware. Being a draft it will not take into account all features commonly present in a handset OS. Flashed with this edition N900 will be usable as a primary phone device for a developer/hacker person.''

= What does the overlay mean in practice? =

Think of the CE effort as a vendor that wants to take MeeGo 1.2 and productize this and put this on a device. How will they do this?

* They'll take the MeeGo 1.2 release (and subsequent update releases) binary packages
* They will add hardware adaptation packages for their device
* They will add patches to MeeGo 1.2 source packages, as they can without risking compliance problems (if not breaking ABI/API, etc), according to section 2.2 of MeeGo compliance document, Platform Source Code Modification Policy.

This will typically be stored in a repository and images made by the usage of MeeGo 1.2 repositories + the CE repositories.

When images are made, the vendor's modifications should take priority over the original.

A typical vendor will not and should not have to rebuild entire MeeGo distribution and we do exactly the same as a vendor would, in CE.

= Why don't you just submit the modifications back to MeeGo? Does this mean N900 Community Edition is a MeeGo fork? =

We'd love to submit changes back, but there are many factors making this difficult:

* For MeeGo 1.3, many of the components we've been applying bug fixes to (MeeGo Touch Framework), are no longer part/will not be part of MeeGo 1.3
* For MeeGo 1.2, only bug fixes go in according to [http://wiki.meego.com/Release_Engineering/Software_update_process#Work_Flow Software update process] and after approval of a update release bug, fixes can go in.
* Because of 2.2 of MeeGo compliance document, Platform Source Code Modification Policy, we cannot submit to 1.3 and just reuse the packages from there in our repository as these packages will typically have updated versions (and due to compliance rules, we can't use those)

When those factors aren't blocking, we submit modifications/improvements and usually get them accepted.

CE is not a MeeGo fork beyond what a typical vendor does to make a MeeGo project. We're an active effort to improve MeeGo and we actively try to submit back our modifications. For those submissions that are not successful, we have to maintain a modified package.

= But your work isn't MeeGo compliant! =

Believe it or not, but we actively try to be compliant. We haven't yet submitted test results, but in our daily work when integrating components or patches, we look to MeeGo compliance. The MeeGo 1.2 compliance document is not yet closed either.

Compliance brings along the benefit that applications made with MeeGo 1.2 SDK will work on N900 Community Edition and applications made in relation to CE work, will work on MeeGo 1.2 devices, so of course we'd like to be part of that.

= Why does the Community Edition use the Community OBS? =

We wanted to start out the project in a place where:

* It was easy to ramp up people in and involve everyone
* Where there was no NDAs or company affilation needed to access the service

In addition to that, we wanted to encourage people to develop for MeeGo and the community OBS was a logical place as anyone with a meego.com account can get access to it.

= Why don't you just use MeeGo 1.3 directly and contribute directly? =

MeeGo 1.3 is in a invasive changes phase and difficult for any newcomers to get into - it is hard to develop when your underlying system isn't stable.

= What does CE bring to MeeGo? What is the benefit for MeeGo? =

== A reference vendor ==

Community Edition acts like a vendor would in the MeeGo ecosystem. We share same mission as a vendor - we want to productize MeeGo for a device.

The difference is just that we don't have any secret devices to do this for, compared to ordinary vendors. This means that:

* We can feed back any problems with what is being released from the MeeGo project instantly back to the project, without having to consider some information secret.
* We can help show problems with process and difficulties with making a MeeGo product.
* We can show a public example of how to make a MeeGo product and train people how to make a MeeGo product.

== Training ==

MeeGo has a contribution problem. It is often difficult to contribute as:

* You need a build.meego.com account if you want to submit anything more than mere software patches (which should go upstream anyway)
* You can only get a build.meego.com account if you have a distinct purpose to do so (and most people don't at first, except 'contribute to meego')
* Review process/feature/bug process has a very steep learning curve.

MeeGo is also a platform and not a end-user product - this means that often, you do not see the immediate result of your contributions in what you use daily. People take the MeeGo platform and build a product using it.

Community Edition lowers the bar of entry for contribution and allows people to come in from the street and start experimenting with the platform and learn how to contribute to MeeGo in a reasonable pace on top of a stable MeeGo release. People can learn everything from release engineering, image creation, packaging, bug triaging, etc. and then go on to use those skills straight in the MeeGo project. They can use the device day to day and see the impact of their changes.

People who are trained within Community Edition can then show their merit when applying for build.meego.com account and be an immediate skilled contributor to MeeGo.

== Future ==

The future remains to be seen for Community Edition. An idea could be to expand the CE work for multiple devices, even beyond Handset/ARM, think Netbook, Tablet - to encourage MeeGo contributions for all these areas. And to continue with the reference vendor work.

Your thoughts? Please discuss on meego-dev@meego.com

ARM/N900/CE Factsheet

2011-06-20T05:45:50Z

Stskeeps: /* Why don't you just submit the modifications back to MeeGo? Does this mean N900 Community Edition is a MeeGo fork? */

ARM/N900/CE Factsheet

2011-06-20T05:45:15Z

Stskeeps: /* Why does the Community Edition use the Community OBS? */

Stskeeps: /* DE-affiliated meego.com users */

= Developer edition release process =

== Principles ==

* Everything we cannot get into MeeGo 1.2/will have significant difficulties getting into MeeGo 1.2 due to feature freeze will go into the N900 DE OBS project.
* Everything should ideally be contributed back to MeeGo 1.3 release track.
* We should stay ABI compatible with MeeGo 1.2.
* We should be aiming for providing a MeeGo compliant "product".

== Repository setup ==

We have two OBS projects on the [http://build.pub.meego.com Community OBS]:

* [https://build.pub.meego.com/project/show?project=Project%3ADE%3ATrunk Project:DE:Trunk] (stable repository)
* [https://build.pub.meego.com/project/show?project=Project%3ADE%3ATrunk:Testing Project:DE:Trunk:Testing] (staging repository)

Each of them has two build targets for the packages:

* 'standard', which points to the current state of the MeeGo 1.2 trunk which becomes next weekly.
* 'weekly', which points to MeeGo 1.2 weekly release.

This setup will allow us to look-ahead on upcoming issues caused by changes done in the MeeGo 1.2 trunk.

== Image building and testing matrix ==

MeeGo.com weekly release comes out on wednesdays. DE weekly release comes out on fridays.

{| class="wikitable" border=1
|-
! Day
! MeeGo.com 1.2 Trunk & Project:DE:Trunk
! MeeGo.com 1.2 Trunk & Project:DE:Trunk:Testing
! MeeGo.com 1.2 Weekly & Project:DE:Trunk
! MeeGo.com 1.2 Weekly & Project:DE:Trunk:Testing
|-
| Monday
| sanity
| acceptance
|
|
|-
| Tuesday
| sanity
| acceptance
|
|
|-
| Wednesday (Freeze, only fixes to make sure a proper weekly release happens are let in to Trunk)
|
|
| weekly release track sanity
| weekly release track acceptance
|-
| Thursday
| sanity
| acceptance
| weekly release track sanity
| weekly release track acceptance
|-
| Friday (after weekly release, repository unfreezes)
| sanity
| acceptance
| weekly release track sanity, if OK, DE weekly release
|
|}

Rationale:

Weekly release == MeeGo 1.2 Trunk on wednesdays, so no need to have seperate images.

Weekly release acceptance testing needs to happen to make the fixes flow to weekly release fix.

"Normal" Sanity/acceptance serves to help prepare for next weeks changes.

== Procedures ==

=== Developer: Branch a package and submit changes to DE ===

Choose your origin (in the following, ORIGIN) of the package:

* MeeGo.com:Trunk (currently 1.2)
* Project:DE:Trunk:Testing (fix a package already contained in DE)

osc -A <nowiki>https://api.pub.meego.com</nowiki> branch -cm "To work on MeeGo DE" ORIGIN packagename

This creates home:yourusername:branches:ORIGIN.

Go to https://build.pub.meego.com/home/list_my and find your project.

If there is no repositories listed in Repositories tab,
go and click "add repository" and "advanced interface" and choose Project:DE:Trunk:Testing as project,
"standard" as repository, new name "standard" and architectures armv7el, armv8el and i586.

.. do your work

After your work is done, i.e., doing the changes to the package and after you have committed the changes to your branch, it is time to check that everything is like it should be. So, lets verify the diff between your branch and the target. NOTE: If you are submitting new package to Project:DE:Trunk:Testing the diff is most probably empty.

osc -A <nowiki>https://api.pub.meego.com</nowiki> submitreq -dm "." home:yourusername:branches:ORIGIN packagename Project:DE:Trunk:Testing

After you have confirmed that the diff is ok. It is time to submit the changes:

osc -A <nowiki>https://api.pub.meego.com</nowiki> submitreq -m "What you changed" home:yourusername:branches:ORIGIN packagename Project:DE:Trunk:Testing

As a result of this command you will get request id that corresponds the request. You can check your request from the OBS webui https://build.pub.meego.com/request/show/REQUEST_ID

=== Release engineering ===

If you'd like to help out with release engineering, poke Stskeeps / Carsten Munk on IRC.

General procedure for reviewing [https://build.pub.meego.com/project/list_requests?project=Project:DE:Trunk:Testing requests towards Project:DE:Trunk:Testing]:

* Verify the package actually builds in the origin project

* Review the package on basis of [[Packaging/Guidelines|packaging guidelines]]

Conditions and procedure for accepting a package change into Project:DE:Trunk from Project:DE:Trunk:Testing:

* The package change must not break any compilation in Trunk:Testing

* The package change must have been included in one acceptance testing image and no regressions seen because of it by QA.

* When OK, submit package to Project:DE:Trunk and remove package from Project:DE:Trunk:Testing (use UI).

* Only accept changes to Project:DE:Trunk that fix issues towards maintaining quality of the weekly image release from Wednesday to Friday weekly release time (soft freeze)

* Accept in the [https://build.pub.meego.com/project/list_requests?project=Project:DE:Trunk requests list towards Project:DE:Trunk]

* Decline any changes made directly to Project:DE:Trunk not done from Project:DE:Trunk:Testing.

=== DE-affiliated meego.com users ===

'''Please send mail to carsten@maemo.org to get activated on community OBS'''

<pre>
alaukkanen
jkunnari
marquiz
sachawla
ksilinja
liljeber
sikemppa
kjokinie
msugano
msafr
zhurakiv
</pre>