ARM/N900/DeveloperEdition/BOSS

2011-09-01T06:03:06Z

Sage: /* Wish List */

ARM/N900/ReleaseProcess

2011-08-22T11:02:10Z

Sage: /* Release engineering */

This page describes the [[ARM/N900/DeveloperEdition|N900 Developer edition]] release process.

== Principles ==

* We cannot get everything into MeeGo 1.2/will have significant difficulties getting into MeeGo 1.2 due to feature freeze and the fact that 1.2 branch doesn't have official handset release. So patches will go into the N900 CE OBS project.
** NOTE: All non handset related patches should be pushed to MeeGo 1.2 track if accepted.
* 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/testing repository)

''Currently'', each of them builds against MeeGo 1.2 release, via the Project:DE:MeeGo:1.2/standard . The project in MeeGo OBS is [http://build.meego.com/project/show?project=MeeGo%3A1.2%3Aoss MeeGo:1.2:oss] which is referred as MeeGo.com:MeeGo:1.2:oss in Community OBS.

The CE development is done against "a moving target" instead of a published release, which is called as 'standard' repository in the Community OBS CE projects. This standard is live link against the MeeGo:1.2:oss project mentioned earlier.

== Image building and testing ==

Four different Community Edition images are build daily.

* mg-handset-armv7nhl-n900-ce-stable
* mg-handset-armv7nhl-n900-ce-testing
* mg-tablet-armv7nhl-n900-ce-stable
* mg-tablet-armv7nhl-n900-ce-testing

Images are prefixed with mg instead of MeeGo to distinguish those more from the official MeeGo builds.

The stable images on Friday of each week are considered as the weekly releases.

QA performs sanity checks for the stable images and acceptance tests for the testing images.

Both sanity & acceptance tests are very brief run-throughs of the functionality of the entire MeeGo distribution, to assure that the basic health of the distribution and report major regressions at the earliest time. All the checkpoints in sanity & acceptance test reflect the most important and basic functionality of the distribution.

== Developers ==

=== Submit a new package ===

Submitting new package from for example home project, i.e., home:username to CE can be done with osc:

osc -A <nowiki>https://api.pub.meego.com</nowiki> sr home:username <my_new_package> Project:DE:Trunk:Testing

After the package is submitted there will be message sent by BOSS to the #meego-arm IRC channel and release engineers will review the changes ASAP.

=== Branch an existing package and submit changes to CE ===

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

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

osc -A <nowiki>https://api.pub.meego.com</nowiki> branch -cm "To work on MeeGo CE" 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 architecturesi armv8el and i586.

.. do your work

'''NOTE:''' Remember to add entry to .changes file and describe what your submit fixes. "- Fixes for BMC#1234" isn't enough, but "- photo-index.patch: Fixed segmentation fault when indexing photos (BMC#1234)" would do.

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]]
** '''NOTE: Because of bug 22696 the review needs to be done manually. See: https://bugs.meego.com/show_bug.cgi?id=22696'''
osc -A https://api.pub.meego.com/ rdiff Project:DE:Trunk:Testing <PACKAGE> <SOURCE_PROJECT>
* Create a link (if needed) from MeeGo.com:MeeGo:1.2:oss to Project:DE:Trunk based on [[ARM/N900/ReleaseProcess#When_new_package_is_submitted_to_Project:DE:Trunk:Testing|guide below]]
* After the link is created and review for the changes have been made you can accept the package.
* MTF framework/desktop packages should be pushed through the [[OBS/Community_OBS/Project_Areas#MTF|Project:MTF]] project

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 the package to Project:DE:Trunk
* 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

=== When new package is submitted to Project:DE:Trunk:Testing ===

When new package is submitted to Project:DE:Trunk:Testing there is two different ways to handle the SR.

'''A)''' First you should check if the package is already in MeeGo.com:MeeGo:1.2:oss projec, if not see section '''B)'''. If the packages was in MeeGo 1.2 oss repo then you need to create a link to that project with following commands:
osc -A https://api.pub.meego.com linkpac -c MeeGo.com:MeeGo:1.2:oss <PACKAGE> Project:DE:Trunk

'''B)''' In case the package is not in the MeeGo.com:MeeGo:1.2:oss you need to do SR manually from the Project:DE:Trunk:Testing to Project:DE:Trunk
osc -A https://api.pub.meego.com sr -m "Forwarding. Remember the link." Project:DE:Trunk:Testing <PACKAGE> Project:DE:Trunk

=== When link needs to be updated ===

'''WARNING: This method has very high risk of breaking package!'''

At times when the there is fix in CE that can't be pushed to the MeeGo upstream for some reason, e.g., too large change for the specified MeeGo release and we still need to get that fix to the package to get some functionality working, there might be a situation where the change needs to be rebased on top of the newer upstream version. For this check there is a [https://gitorious.org/meego-developer-edition-for-n900/upstreamchecker upstreamchecker] tool that can be used to check if package is much behind of the upstream. After verifying with this tool and maybe from the webui you might need to rebase the package, e.g.,

First check that there are not any pending submit requests to Project:DE:Trunk.
osc -A https://api.pub.meego.com request list Project:DE:Trunk <PACKAGE>

Then force the new link
osc -A https://api.pub.meego.com linkpac -c -f MeeGo.com:MeeGo:1.2:oss <PACKAGE> Project:DE:Trunk

Then checkout the copy of the package and update it.
osc -A https://api.pub.meego.com co Project:DE:Trunk <PACKAGE>
cd <package_checkout>
osc -A https://api.pub.meego.com up

Next we need to apply the diff, which might be possible to do with patch, or just applying manually. Remember to solve the conflicts if you used patch.
patch -p0 < project.diff

Remeber to remove the old diff from the project.
osc rm project.diff

And in the end just submit the changes.
osc ci -m "Rebased link."

=== Image creation ===

Multiple options, we are currently looking at having the images physically built in internal Nokia IMG service and transferred to a public download site.

=== Image configurations ===

N900 CE image configurations (kickstart files) are located at https://gitorious.org/meego-developer-edition-for-n900/image-configurations gitorious tree under the kickstarts directory.

=== Daily image creator ===

From the git tree above the images are created by daily-image-builder, which is available at https://gitorious.org/image-building-tools/daily-image-builder

daily-image-builder script is executed every morning on computer X from where the images are uploaded to http://repository.maemo.org/meego/n900-de/daily/ around 04:00 UTC.

=== Release Format ===

The directories in n900-de repository look following 1.1.99.2.20110412.6.DE.2011-04-19.2 where the start is the MeeGo version and the end after DE is the DE build version in following format YYYY-MM-DD.<build_count>

The MeeGo version is taken from http://repo.meego.com/MeeGo/snapshots/stable/1.2.0.90/

==== Images ====

Currently we have couple of different images types:

mg-handset-armv7nhl-n900-ce-stable
mg-handset-armv7nhl-n900-ce-testing
mg-tablet-armv7nhl-n900-ce-stable
mg-tablet-armv7nhl-n900-ce-testing

All the images use [http://repo.meego.com/MeeGo/snapshots/stable/1.2.0.90/ MeeGo 1.2 stable snapshot repository] as a base. In CE case the stable and testing in image name means which CE repository is used in addition to the MeeGo snapshot repository, i.e., in stable images we use [http://repo.pub.meego.com/Project:/DE:/Trunk/standard/ Project:DE:Trunk] repository and in testing [http://repo.pub.meego.com/Project:/DE:/Trunk:/Testing/standard/ Project:DE:Trunk:Testing] repository.

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

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

* stskeeps
* [http://www.meego.com/users/sage sage]
* alaukkanen
* jkunnari
* marquiz
* sachawla
* ksilinja
* liljeber
* sikemppa
* kjokinie
* msugano
* msafr
* zhurakiv
* japaloja
* logoel
* lamikr
* vesku
* tjyrinki
* tazpa

[[Category:N900]]

ARM/N900/ReleaseProcess

2011-08-22T11:00:06Z

Sage: /* Release engineering */

This page describes the [[ARM/N900/DeveloperEdition|N900 Developer edition]] release process.

== Principles ==

* We cannot get everything into MeeGo 1.2/will have significant difficulties getting into MeeGo 1.2 due to feature freeze and the fact that 1.2 branch doesn't have official handset release. So patches will go into the N900 CE OBS project.
** NOTE: All non handset related patches should be pushed to MeeGo 1.2 track if accepted.
* 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/testing repository)

''Currently'', each of them builds against MeeGo 1.2 release, via the Project:DE:MeeGo:1.2/standard . The project in MeeGo OBS is [http://build.meego.com/project/show?project=MeeGo%3A1.2%3Aoss MeeGo:1.2:oss] which is referred as MeeGo.com:MeeGo:1.2:oss in Community OBS.

The CE development is done against "a moving target" instead of a published release, which is called as 'standard' repository in the Community OBS CE projects. This standard is live link against the MeeGo:1.2:oss project mentioned earlier.

== Image building and testing ==

Four different Community Edition images are build daily.

* mg-handset-armv7nhl-n900-ce-stable
* mg-handset-armv7nhl-n900-ce-testing
* mg-tablet-armv7nhl-n900-ce-stable
* mg-tablet-armv7nhl-n900-ce-testing

Images are prefixed with mg instead of MeeGo to distinguish those more from the official MeeGo builds.

The stable images on Friday of each week are considered as the weekly releases.

QA performs sanity checks for the stable images and acceptance tests for the testing images.

Both sanity & acceptance tests are very brief run-throughs of the functionality of the entire MeeGo distribution, to assure that the basic health of the distribution and report major regressions at the earliest time. All the checkpoints in sanity & acceptance test reflect the most important and basic functionality of the distribution.

== Developers ==

=== Submit a new package ===

Submitting new package from for example home project, i.e., home:username to CE can be done with osc:

osc -A <nowiki>https://api.pub.meego.com</nowiki> sr home:username <my_new_package> Project:DE:Trunk:Testing

After the package is submitted there will be message sent by BOSS to the #meego-arm IRC channel and release engineers will review the changes ASAP.

=== Branch an existing package and submit changes to CE ===

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

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

osc -A <nowiki>https://api.pub.meego.com</nowiki> branch -cm "To work on MeeGo CE" 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 architecturesi armv8el and i586.

.. do your work

'''NOTE:''' Remember to add entry to .changes file and describe what your submit fixes. "- Fixes for BMC#1234" isn't enough, but "- photo-index.patch: Fixed segmentation fault when indexing photos (BMC#1234)" would do.

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]:

'''NOTE: The process is changing a bit. These instructions are not up to date. See: https://bugs.meego.com/show_bug.cgi?id=22696'''

* Verify the package actually builds in the origin project
* Review the package on basis of [[Packaging/Guidelines|packaging guidelines]]
* Create a link (if needed) from MeeGo.com:MeeGo:1.2:oss to Project:DE:Trunk based on [[ARM/N900/ReleaseProcess#When_new_package_is_submitted_to_Project:DE:Trunk:Testing|guide below]]
* After the link is created and review for the changes have been made you can accept the package.
* MTF framework/desktop packages should be pushed through the [[OBS/Community_OBS/Project_Areas#MTF|Project:MTF]] project

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 the package to Project:DE:Trunk
* 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

=== When new package is submitted to Project:DE:Trunk:Testing ===

When new package is submitted to Project:DE:Trunk:Testing there is two different ways to handle the SR.

'''A)''' First you should check if the package is already in MeeGo.com:MeeGo:1.2:oss projec, if not see section '''B)'''. If the packages was in MeeGo 1.2 oss repo then you need to create a link to that project with following commands:
osc -A https://api.pub.meego.com linkpac -c MeeGo.com:MeeGo:1.2:oss <PACKAGE> Project:DE:Trunk

'''B)''' In case the package is not in the MeeGo.com:MeeGo:1.2:oss you need to do SR manually from the Project:DE:Trunk:Testing to Project:DE:Trunk
osc -A https://api.pub.meego.com sr -m "Forwarding. Remember the link." Project:DE:Trunk:Testing <PACKAGE> Project:DE:Trunk

=== When link needs to be updated ===

'''WARNING: This method has very high risk of breaking package!'''

At times when the there is fix in CE that can't be pushed to the MeeGo upstream for some reason, e.g., too large change for the specified MeeGo release and we still need to get that fix to the package to get some functionality working, there might be a situation where the change needs to be rebased on top of the newer upstream version. For this check there is a [https://gitorious.org/meego-developer-edition-for-n900/upstreamchecker upstreamchecker] tool that can be used to check if package is much behind of the upstream. After verifying with this tool and maybe from the webui you might need to rebase the package, e.g.,

First check that there are not any pending submit requests to Project:DE:Trunk.
osc -A https://api.pub.meego.com request list Project:DE:Trunk <PACKAGE>

Then force the new link
osc -A https://api.pub.meego.com linkpac -c -f MeeGo.com:MeeGo:1.2:oss <PACKAGE> Project:DE:Trunk

Then checkout the copy of the package and update it.
osc -A https://api.pub.meego.com co Project:DE:Trunk <PACKAGE>
cd <package_checkout>
osc -A https://api.pub.meego.com up

Next we need to apply the diff, which might be possible to do with patch, or just applying manually. Remember to solve the conflicts if you used patch.
patch -p0 < project.diff

Remeber to remove the old diff from the project.
osc rm project.diff

And in the end just submit the changes.
osc ci -m "Rebased link."

=== Image creation ===

Multiple options, we are currently looking at having the images physically built in internal Nokia IMG service and transferred to a public download site.

=== Image configurations ===

N900 CE image configurations (kickstart files) are located at https://gitorious.org/meego-developer-edition-for-n900/image-configurations gitorious tree under the kickstarts directory.

=== Daily image creator ===

From the git tree above the images are created by daily-image-builder, which is available at https://gitorious.org/image-building-tools/daily-image-builder

daily-image-builder script is executed every morning on computer X from where the images are uploaded to http://repository.maemo.org/meego/n900-de/daily/ around 04:00 UTC.

=== Release Format ===

The directories in n900-de repository look following 1.1.99.2.20110412.6.DE.2011-04-19.2 where the start is the MeeGo version and the end after DE is the DE build version in following format YYYY-MM-DD.<build_count>

The MeeGo version is taken from http://repo.meego.com/MeeGo/snapshots/stable/1.2.0.90/

==== Images ====

Currently we have couple of different images types:

mg-handset-armv7nhl-n900-ce-stable
mg-handset-armv7nhl-n900-ce-testing
mg-tablet-armv7nhl-n900-ce-stable
mg-tablet-armv7nhl-n900-ce-testing

All the images use [http://repo.meego.com/MeeGo/snapshots/stable/1.2.0.90/ MeeGo 1.2 stable snapshot repository] as a base. In CE case the stable and testing in image name means which CE repository is used in addition to the MeeGo snapshot repository, i.e., in stable images we use [http://repo.pub.meego.com/Project:/DE:/Trunk/standard/ Project:DE:Trunk] repository and in testing [http://repo.pub.meego.com/Project:/DE:/Trunk:/Testing/standard/ Project:DE:Trunk:Testing] repository.

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

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

* stskeeps
* [http://www.meego.com/users/sage sage]
* alaukkanen
* jkunnari
* marquiz
* sachawla
* ksilinja
* liljeber
* sikemppa
* kjokinie
* msugano
* msafr
* zhurakiv
* japaloja
* logoel
* lamikr
* vesku
* tjyrinki
* tazpa

[[Category:N900]]

ARM/N900/ReleaseProcess

2011-08-19T12:19:05Z

Sage: /* Release engineering */

This page describes the [[ARM/N900/DeveloperEdition|N900 Developer edition]] release process.

== Principles ==

* We cannot get everything into MeeGo 1.2/will have significant difficulties getting into MeeGo 1.2 due to feature freeze and the fact that 1.2 branch doesn't have official handset release. So patches will go into the N900 CE OBS project.
** NOTE: All non handset related patches should be pushed to MeeGo 1.2 track if accepted.
* 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/testing repository)

''Currently'', each of them builds against MeeGo 1.2 release, via the Project:DE:MeeGo:1.2/standard . The project in MeeGo OBS is [http://build.meego.com/project/show?project=MeeGo%3A1.2%3Aoss MeeGo:1.2:oss] which is referred as MeeGo.com:MeeGo:1.2:oss in Community OBS.

The CE development is done against "a moving target" instead of a published release, which is called as 'standard' repository in the Community OBS CE projects. This standard is live link against the MeeGo:1.2:oss project mentioned earlier.

== Image building and testing ==

Four different Community Edition images are build daily.

* mg-handset-armv7nhl-n900-ce-stable
* mg-handset-armv7nhl-n900-ce-testing
* mg-tablet-armv7nhl-n900-ce-stable
* mg-tablet-armv7nhl-n900-ce-testing

Images are prefixed with mg instead of MeeGo to distinguish those more from the official MeeGo builds.

The stable images on Friday of each week are considered as the weekly releases.

QA performs sanity checks for the stable images and acceptance tests for the testing images.

Both sanity & acceptance tests are very brief run-throughs of the functionality of the entire MeeGo distribution, to assure that the basic health of the distribution and report major regressions at the earliest time. All the checkpoints in sanity & acceptance test reflect the most important and basic functionality of the distribution.

== Developers ==

=== Submit a new package ===

Submitting new package from for example home project, i.e., home:username to CE can be done with osc:

osc -A <nowiki>https://api.pub.meego.com</nowiki> sr home:username <my_new_package> Project:DE:Trunk:Testing

After the package is submitted there will be message sent by BOSS to the #meego-arm IRC channel and release engineers will review the changes ASAP.

=== Branch an existing package and submit changes to CE ===

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

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

osc -A <nowiki>https://api.pub.meego.com</nowiki> branch -cm "To work on MeeGo CE" 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 architecturesi armv8el and i586.

.. do your work

'''NOTE:''' Remember to add entry to .changes file and describe what your submit fixes. "- Fixes for BMC#1234" isn't enough, but "- photo-index.patch: Fixed segmentation fault when indexing photos (BMC#1234)" would do.

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]:

'''NOTE: The process is changing a bit. These instructions are not up to date. See: https://bugs.meego.com/show_bug.cgi?id=22696'''

* Verify the package actually builds in the origin project
* Review the package on basis of [[Packaging/Guidelines|packaging guidelines]]
* Create a link from MeeGo.com:MeeGo:1.2:oss to Project:DE:Trunk based on [[ARM/N900/ReleaseProcess#When_new_package_is_submitted_to_Project:DE:Trunk:Testing|guide below]]
* After the link is created and review for the changes have been made you can accept the package. '''NOTE:''' It is recommended to ''Forward to Project:DE:Trunk'' (but not accept the package in Project:DE:Trunk) instead of just ''Accept'' the package to make sure it ends up to the Project:DE:Trunk project eventually.
* MTF framework/desktop packages should be pushed through the [[OBS/Community_OBS/Project_Areas#MTF|Project:MTF]] project
* If there is already existing submit request from Project:DE:Trunk:Testing to Project:DE:Trunk that request should be accepted to Project:DE:Trunk first if possible. Otherwise that request should be rejected and this new request should supersede that one.

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 the package to Project:DE:Trunk
* 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

=== When new package is submitted to Project:DE:Trunk:Testing ===

When new package is submitted to Project:DE:Trunk:Testing there is two different ways to handle the SR.

'''A)''' First you should check if the package is already in MeeGo.com:MeeGo:1.2:oss project, if not see section '''B)'''. If the packages was in MeeGo 1.2 oss repo then you need to create a link to that project with following commands:
osc -A https://api.pub.meego.com linkpac -c MeeGo.com:MeeGo:1.2:oss <PACKAGE> Project:DE:Trunk
osc -A https://api.pub.meego.com linkpac Project:DE:Trunk <PACKAGE> Project:DE:Trunk:Testing

'''B)''' In case the package is not in the MeeGo.com:MeeGo:1.2:oss you need to do SR manually from the Project:DE:Trunk:Testing to Project:DE:Trunk
osc -A https://api.pub.meego.com sr -m "Forwarding. Remember the link." Project:DE:Trunk:Testing <PACKAGE> Project:DE:Trunk

Also what should be noted that when new package goes to the Project:DE:Trunk also a link needs to be added from Project:DE:Trunk to Project:DE:Trunk:Testing
osc -A https://api.pub.meego.com linkpac Project:DE:Trunk <PACKAGE> Project:DE:Trunk:Testing

=== When link needs to be updated ===

'''WARNING: This method has very high risk of breaking package!'''

At times when the there is fix in CE that can't be pushed to the MeeGo upstream for some reason, e.g., too large change for the specified MeeGo release and we still need to get that fix to the package to get some functionality working, there might be a situation where the change needs to be rebased on top of the newer upstream version. For this check there is a [https://gitorious.org/meego-developer-edition-for-n900/upstreamchecker upstreamchecker] tool that can be used to check if package is much behind of the upstream. After verifying with this tool and maybe from the webui you might need to rebase the package, e.g.,

First check that there are not any pending submit requests to Project:DE:Trunk.
osc -A https://api.pub.meego.com request list Project:DE:Trunk <PACKAGE>

Then force the new link
osc -A https://api.pub.meego.com linkpac -c -f MeeGo.com:MeeGo:1.2:oss <PACKAGE> Project:DE:Trunk

Then checkout the copy of the package and update it.
osc -A https://api.pub.meego.com co Project:DE:Trunk <PACKAGE>
cd <package_checkout>
osc -A https://api.pub.meego.com up

Next we need to apply the diff, which might be possible to do with patch, or just applying manually. Remember to solve the conflicts if you used patch.
patch -p0 < project.diff

Remeber to remove the old diff from the project.
osc rm project.diff

And in the end just submit the changes.
osc ci -m "Rebased link."

=== Image creation ===

Multiple options, we are currently looking at having the images physically built in internal Nokia IMG service and transferred to a public download site.

=== Image configurations ===

N900 CE image configurations (kickstart files) are located at https://gitorious.org/meego-developer-edition-for-n900/image-configurations gitorious tree under the kickstarts directory.

=== Daily image creator ===

From the git tree above the images are created by daily-image-builder, which is available at https://gitorious.org/image-building-tools/daily-image-builder

daily-image-builder script is executed every morning on computer X from where the images are uploaded to http://repository.maemo.org/meego/n900-de/daily/ around 04:00 UTC.

=== Release Format ===

The directories in n900-de repository look following 1.1.99.2.20110412.6.DE.2011-04-19.2 where the start is the MeeGo version and the end after DE is the DE build version in following format YYYY-MM-DD.<build_count>

The MeeGo version is taken from http://repo.meego.com/MeeGo/snapshots/stable/1.2.0.90/

==== Images ====

Currently we have couple of different images types:

mg-handset-armv7nhl-n900-ce-stable
mg-handset-armv7nhl-n900-ce-testing
mg-tablet-armv7nhl-n900-ce-stable
mg-tablet-armv7nhl-n900-ce-testing

All the images use [http://repo.meego.com/MeeGo/snapshots/stable/1.2.0.90/ MeeGo 1.2 stable snapshot repository] as a base. In CE case the stable and testing in image name means which CE repository is used in addition to the MeeGo snapshot repository, i.e., in stable images we use [http://repo.pub.meego.com/Project:/DE:/Trunk/standard/ Project:DE:Trunk] repository and in testing [http://repo.pub.meego.com/Project:/DE:/Trunk:/Testing/standard/ Project:DE:Trunk:Testing] repository.

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

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

* stskeeps
* [http://www.meego.com/users/sage sage]
* alaukkanen
* jkunnari
* marquiz
* sachawla
* ksilinja
* liljeber
* sikemppa
* kjokinie
* msugano
* msafr
* zhurakiv
* japaloja
* logoel
* lamikr
* vesku
* tjyrinki
* tazpa

[[Category:N900]]

ARM/N900/DeveloperEdition/BOSS

2011-08-16T06:52:26Z

Sage: /* BOSS Checks */

ARM/N900/ReleaseProcess

2011-07-13T10:57:45Z

Sage: /* When link needs to be updated */

This page describes the [[ARM/N900/DeveloperEdition|N900 Developer edition]] release process.

== Principles ==

* We cannot get everything into MeeGo 1.2/will have significant difficulties getting into MeeGo 1.2 due to feature freeze and the fact that 1.2 branch doesn't have official handset release. So patches will go into the N900 CE OBS project.
** NOTE: All non handset related patches should be pushed to MeeGo 1.2 track if accepted.
* 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/testing repository)

''Currently'', each of them builds against MeeGo 1.2 release, via the Project:DE:MeeGo:1.2/standard . The project in MeeGo OBS is [http://build.meego.com/project/show?project=MeeGo%3A1.2%3Aoss MeeGo:1.2:oss] which is referred as MeeGo.com:MeeGo:1.2:oss in Community OBS.

The CE development is done against "a moving target" instead of a published release, which is called as 'standard' repository in the Community OBS CE projects. This standard is live link against the MeeGo:1.2:oss project mentioned earlier.

== Image building and testing ==

Four different Community Edition images are build daily.

* mg-handset-armv7nhl-n900-ce-stable
* mg-handset-armv7nhl-n900-ce-testing
* mg-tablet-armv7nhl-n900-ce-stable
* mg-tablet-armv7nhl-n900-ce-testing

Images are prefixed with mg instead of MeeGo to distinguish those more from the official MeeGo builds.

The stable images on Friday of each week are considered as the weekly releases.

QA performs sanity checks for the stable images and acceptance tests for the testing images.

Both sanity & acceptance tests are very brief run-throughs of the functionality of the entire MeeGo distribution, to assure that the basic health of the distribution and report major regressions at the earliest time. All the checkpoints in sanity & acceptance test reflect the most important and basic functionality of the distribution.

== Developers ==

=== Submit a new package ===

Submitting new package from for example home project, i.e., home:username to CE can be done with osc:

osc -A <nowiki>https://api.pub.meego.com</nowiki> sr home:username <my_new_package> Project:DE:Trunk:Testing

After the package is submitted there will be message sent by BOSS to the #meego-arm IRC channel and release engineers will review the changes ASAP.

=== Branch an existing package and submit changes to CE ===

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

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

osc -A <nowiki>https://api.pub.meego.com</nowiki> branch -cm "To work on MeeGo CE" 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 architecturesi armv8el and i586.

.. do your work

'''NOTE:''' Remember to add entry to .changes file and describe what your submit fixes. "- Fixes for BMC#1234" isn't enough, but "- photo-index.patch: Fixed segmentation fault when indexing photos (BMC#1234)" would do.

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]]
* Create a link from MeeGo.com:MeeGo:1.2:oss to Project:DE:Trunk based on [[ARM/N900/ReleaseProcess#When_new_package_is_submitted_to_Project:DE:Trunk:Testing|guide below]]
* After the link is created and review for the changes have been made you can accept the package. '''NOTE:''' It is recommended to ''Forward to Project:DE:Trunk'' (but not accept the package in Project:DE:Trunk) instead of just ''Accept'' the package to make sure it ends up to the Project:DE:Trunk project eventually.
* MTF framework/desktop packages should be pushed through the [[OBS/Community_OBS/Project_Areas#MTF|Project:MTF]] project
* If there is already existing submit request from Project:DE:Trunk:Testing to Project:DE:Trunk that request should be accepted to Project:DE:Trunk first if possible. Otherwise that request should be rejected and this new request should supersede that one.

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 the package to Project:DE:Trunk
* 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

=== When new package is submitted to Project:DE:Trunk:Testing ===

When new package is submitted to Project:DE:Trunk:Testing there is two different ways to handle the SR.

'''A)''' First you should check if the package is already in MeeGo.com:MeeGo:1.2:oss project, if not see section '''B)'''. If the packages was in MeeGo 1.2 oss repo then you need to create a link to that project with following commands:
osc -A https://api.pub.meego.com linkpac -c MeeGo.com:MeeGo:1.2:oss <PACKAGE> Project:DE:Trunk
osc -A https://api.pub.meego.com linkpac Project:DE:Trunk <PACKAGE> Project:DE:Trunk:Testing

'''B)''' In case the package is not in the MeeGo.com:MeeGo:1.2:oss you need to do SR manually from the Project:DE:Trunk:Testing to Project:DE:Trunk
osc -A https://api.pub.meego.com sr -m "Forwarding. Remember the link." Project:DE:Trunk:Testing <PACKAGE> Project:DE:Trunk

Also what should be noted that when new package goes to the Project:DE:Trunk also a link needs to be added from Project:DE:Trunk to Project:DE:Trunk:Testing
osc -A https://api.pub.meego.com linkpac Project:DE:Trunk <PACKAGE> Project:DE:Trunk:Testing

=== When link needs to be updated ===

'''WARNING: This method has very high risk of breaking package!'''

At times when the there is fix in CE that can't be pushed to the MeeGo upstream for some reason, e.g., too large change for the specified MeeGo release and we still need to get that fix to the package to get some functionality working, there might be a situation where the change needs to be rebased on top of the newer upstream version. For this check there is a [https://gitorious.org/meego-developer-edition-for-n900/upstreamchecker upstreamchecker] tool that can be used to check if package is much behind of the upstream. After verifying with this tool and maybe from the webui you might need to rebase the package, e.g.,

First check that there are not any pending submit requests to Project:DE:Trunk.
osc -A https://api.pub.meego.com request list Project:DE:Trunk <PACKAGE>

Then force the new link
osc -A https://api.pub.meego.com linkpac -c -f MeeGo.com:MeeGo:1.2:oss <PACKAGE> Project:DE:Trunk

Then checkout the copy of the package and update it.
osc -A https://api.pub.meego.com co Project:DE:Trunk <PACKAGE>
cd <package_checkout>
osc -A https://api.pub.meego.com up

Next we need to apply the diff, which might be possible to do with patch, or just applying manually. Remember to solve the conflicts if you used patch.
patch -p0 < project.diff

Remeber to remove the old diff from the project.
osc rm project.diff

And in the end just submit the changes.
osc ci -m "Rebased link."

=== Image creation ===

Multiple options, we are currently looking at having the images physically built in internal Nokia IMG service and transferred to a public download site.

=== Image configurations ===

N900 CE image configurations (kickstart files) are located at https://gitorious.org/meego-developer-edition-for-n900/image-configurations gitorious tree under the kickstarts directory.

=== Daily image creator ===

From the git tree above the images are created by daily-image-builder, which is available at https://gitorious.org/image-building-tools/daily-image-builder

daily-image-builder script is executed every morning on computer X from where the images are uploaded to http://repository.maemo.org/meego/n900-de/daily/ around 04:00 UTC.

=== Release Format ===

The directories in n900-de repository look following 1.1.99.2.20110412.6.DE.2011-04-19.2 where the start is the MeeGo version and the end after DE is the DE build version in following format YYYY-MM-DD.<build_count>

The MeeGo version is taken from http://repo.meego.com/MeeGo/snapshots/stable/1.2.0.90/

==== Images ====

Currently we have couple of different images types:

mg-handset-armv7nhl-n900-ce-stable
mg-handset-armv7nhl-n900-ce-testing
mg-tablet-armv7nhl-n900-ce-stable
mg-tablet-armv7nhl-n900-ce-testing

All the images use [http://repo.meego.com/MeeGo/snapshots/stable/1.2.0.90/ MeeGo 1.2 stable snapshot repository] as a base. In CE case the stable and testing in image name means which CE repository is used in addition to the MeeGo snapshot repository, i.e., in stable images we use [http://repo.pub.meego.com/Project:/DE:/Trunk/standard/ Project:DE:Trunk] repository and in testing [http://repo.pub.meego.com/Project:/DE:/Trunk:/Testing/standard/ Project:DE:Trunk:Testing] repository.

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

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

* stskeeps
* [http://www.meego.com/users/sage sage]
* alaukkanen
* jkunnari
* marquiz
* sachawla
* ksilinja
* liljeber
* sikemppa
* kjokinie
* msugano
* msafr
* zhurakiv
* japaloja
* logoel
* lamikr
* vesku
* tjyrinki
* tazpa

[[Category:N900]]

2011-06-28T12:04:17Z

Sage:

This page describes the [[ARM/N900/DeveloperEdition|N900 Developer edition]] release process.

== Principles ==

* We cannot get everything into MeeGo 1.2/will have significant difficulties getting into MeeGo 1.2 due to feature freeze and the fact that 1.2 branch doesn't have official handset release. So patches will go into the N900 CE OBS project.
** NOTE: All non handset related patches should be pushed to MeeGo 1.2 track if accepted.
* 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)

''Currently'', each of them builds against MeeGo 1.2 release, via the Project:DE:MeeGo:1.2/standard .

When again developing against a moving target instead of a published release, each of them will have two build targets for the packages:

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

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

== Image building and testing matrix ==

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

Both sanity & acceptance tests are very brief run-throughs of the functionality of the entire MeeGo distribution, to assure that the basic health of the distribution and report major regressions at the earliest time. All the checkpoints in sanity & acceptance test reflect the most important and basic functionality of the distribution.

We do the sanity test against the Trunk and the acceptance test against Trunk:Testing.

{| 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:MeeGo:1.2:oss (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 architecturesi armv8el and i586.

.. do your work

'''NOTE:''' Remember to add entry to .changes file and describe what your submit fixes. "- Fixes for BMC#1234" isn't enough, but "- photo-index.patch: Fixed segmentation fault when indexing photos (BMC#1234)" would do.

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]]
* When accepting the change to Project:DE:Trunk:Testing make sure that there is existing package link already if the change is a patch is to package in MeeGo.com:Trunk
osc -A https://api.pub.meego.com linkpac -c MeeGo.com:Trunk <package> Project:DE:Trunk
osc -A https://api.pub.meego.com linkpac Project:DE:Trunk <package> Project:DE:Trunk:Testing
* After the link is created and review for the changes have been made you can accept the package. ''NOTE:'' It is recommended to ''Forward to Project:DE:Trunk'' (but not accept the package in Project:DE:Trunk) instead of just ''Accept'' the package to make sure it ends up to the Project:DE:Trunk project eventually.

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.

==== When link needs to be updated ====

First check that there are not any pending submit requests to Project:DE:Trunk.
osc -A https://api.pub.meego.com request list Project:DE:Trunk <PACKAGE>

Then force the new link
osc -A https://api.pub.meego.com linkpac -c -f MeeGo.com:MeeGo:1.2:oss <PACKAGE> Project:DE:Trunk

Then checkout the copy of the package and update it.
osc -A https://api.pub.meego.com co Project:DE:Trunk <PACKAGE>
cd <package_checkout>
osc -A https://api.pub.meego.com up

Next we need to apply the diff, which might be possible to do with patch, or just applying manually. Remember to solve the conflicts if you used patch.
patch -p0 < project.diff

Remeber to remove the old diff from the project.
osc rm project.diff

And in the end just submit the changes.
osc ci -m "Rebased link."

==== Image creation ====

Multiple options, we are currently looking at having the images physically built in internal Nokia IMG service and transferred to a public download site.

==== Image configurations ====

N900 DE image configurations (kickstart files) are located at https://gitorious.org/meego-developer-edition-for-n900/image-configurations gitorious tree under the kickstarts directory.

==== Daily image creator ====

From the git tree above the images are created by daily-image-builder, which is available at https://gitorious.org/image-building-tools/daily-image-builder

daily-image-builder script is executed every morning on computer X from where the images are uploaded to http://repository.maemo.org/meego/n900-de/daily/ around UTC 03:00.

==== Release Format ====

The directories in n900-de repository look following 1.1.99.2.20110412.6.DE.2011-04-19.2 where the start is the MeeGo version and the end after DE is the DE build version in following format YYYY-MM-DD.<build_count>

The MeeGo version is taken from http://download.meego.com/trunk-daily/builds/trunk/

==== Images ====

Currently we have couple of different images types:

mg-handset-armv7nhl-n900-de-sanity
mg-handset-armv7nhl-n900-de-acceptance
mg-tablet-armv7nhl-n900-de-acceptance

All the images use MeeGo Trunk (later on MeeGo 1.2) daily repository as a base. So no Trunk:Testing packages are used. This pretty much means that DE images are closest to the MeeGo sanity test report results. In DE case the sanity and acceptance in image name means which DE repository we are using in addition to the MeeGo Trunk, i.e., in sanity images we use Project:DE:Trunk repository and in acceptance Project:DE:Trunk:Testing repository.

Tablet image uses also Project:DE:Devel:Tablet repository for some n900 tablet specific modifications.

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

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

* stskeeps
* [http://www.meego.com/users/sage sage]
* alaukkanen
* jkunnari
* marquiz
* sachawla
* ksilinja
* liljeber
* sikemppa
* kjokinie
* msugano
* msafr
* zhurakiv
* japaloja
* logoel
* lamikr
* vesku
* tjyrinki
* tazpa

[[Category:N900]]