ARM/N900/ReleaseProcess

This page describes the N900 Developer edition release process.

Contents 1 Principles 2 Repository setup 3 Image building and testing matrix 4 Procedures 4.1 Developer: Branch a package and submit changes to DE 4.2 Release engineering 4.2.1 Image creation 4.2.2 Image configurations 4.2.3 Daily image creator 4.2.4 Release Format 4.2.5 Images 4.3 DE-affiliated meego.com users

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 Community OBS:

• Project:DE:Trunk (stable repository)
• 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.

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.

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 https://api.pub.meego.com 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

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 https://api.pub.meego.com 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 https://api.pub.meego.com 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 requests towards Project:DE:Trunk:Testing:

• Verify the package actually builds in the origin project
• Review the package on basis of 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 requests list towards Project:DE:Trunk
• Decline any changes made directly to Project:DE:Trunk not done from Project:DE:Trunk:Testing.

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
• sage
• alaukkanen
• jkunnari
• marquiz
• sachawla
• ksilinja
• liljeber
• sikemppa
• kjokinie
• msugano
• msafr
• zhurakiv
• japaloja
• logoel