Contents 1 MeeGo Buildsystem Roadmap 1.1 Current Status 1.2 Plans 1.2.1 OBS 1.2.1.1 2.1.x Update 1.2.1.2 LDAP integration 1.2.1.3 Build System Project Reorg 1.2.2 Automation

MeeGo Buildsystem Roadmap

Current Status

MeeGo is currently running OBS 2.0.6 with minor changes specific to MeeGo:

• Backport of notification plugin to be able to use AMQP for events
• Minor Web UI changes

Plans

See also: MeeGo and OBS: current state and roadmap session at MeeGo Conference 2010 (video and slides).

OBS

2.1.x Update

We are on track to update the MeeGo Build System to 2.1.1 which was released Oct 29th, 2010. See the original announcement for 2.1 for more details about the new features and fixes.

The update to 2.1.1 is scheduled to happen on Saturday, November 6th. Downtime is scheduled between 12:00-14:00 GMT on that date.

LDAP integration

2.1.x adds enhanced LDAP support which will allow advanced user management. We are planning to migrate all users from the current implementation to a dedicated LDAP instance and finally enable password changes by the user and better tracking for users and groups in general. The migration to LDAP will happen after 2.1.1 deployment and will happen in 2 steps:

• Review of all users and cleanup of users currently not active, i.e. removing duplicates etc.
• Reset password on all accounts and verifying emails of all users, this will lead to another wave of cleanups leading to the final user list
• Migrate users to LDAP and run initial tests with LDAP as the backend. At that time, user creation and user changes is frozen and disabled.
• finally, migrate to LDAP and disable current database backend

Build System Project Reorg

At the moment, projects are organised based on usage scenarios or verticals. the main project is Trunk with the following vertical/UX based projects:

• Trunk:Netbook
• Trunk:Handset
• Trunk:IVI

The vertical projects build against Trunk, thus, the Trunk is the container for all share packages required by all verticals. With the introduction of the compliance and the need to have a self-contained core stack, based on the MeeGo architecture, the above model does not scale and causes conflicts among verticals and does not provide a clear view of what exactly the base stack that can be used to build compliant applications.

Hence, we have the following proposal to split the whole lot into 2 groups instead .

• Core
• Reference or Applications (tentative name)

Core would have all compliance libraries and OS base packages (essentials) and their build requirements. All misc. stuff like reference apps, tools and non-core libraries would go into the Applications project and build on top of Core.

There are two major advantages here:

• We can always guarantee that the core packages are self contained and consistent without any bogus dependencies
• When building compliant applications all you need is to build againstCore which will guarantee that you do not link against libraries that are not available on all devices

We started experimenting and have been splitting Trunk packages into core+application in the following devel area in the MeeGo Build System:

• devel:cleanup:core
• devel:cleanup:reference

This effort still ongoing and doing this we are already identifying lots of issues and dependencies that should not be there and cleaning those up as we go.

Automation

Refer to /Release_Infrastructure for info on the tools Release Automation will be carried out in the follwoing order

• Deploy BOSS (install and test) [DONE]
• install OBS plugin to communicate with BOSS [DONE]
• Deploy IMG (install and configure) [ETA: W45]
• Automate image creation for weekly/testing/daily snapshots [ETA: W46]
• Implement checks: set of checks to test before proceeding with submit requests. [ETA: ]
• Deploy the checks: check each request, if it fails the test, then reject it, otherwise notify maintainer to process the request [ETA: ]