(→Build System Project Reorg) |
(categorise) |
||
| (5 intermediate revisions not shown) | |||
| Line 6: | Line 6: | ||
== Plans == | == Plans == | ||
| + | See also: [http://conference2010.meego.com/session/meego-and-obs-current-state-and-roadmap MeeGo and OBS: current state and roadmap] session at MeeGo Conference 2010 (video and slides). | ||
| - | === 2.1.x Update === | + | === OBS === |
| + | ==== 2.1.x Update ==== | ||
We are on track to update the MeeGo Build System to 2.1.1 which was [http://lists.opensuse.org/opensuse-buildservice/2010-10/msg00239.html released] Oct 29th, 2010. See the original [http://lists.opensuse.org/opensuse-announce/2010-10/msg00009.html announcement] for 2.1 for more details about the new features and fixes. | We are on track to update the MeeGo Build System to 2.1.1 which was [http://lists.opensuse.org/opensuse-buildservice/2010-10/msg00239.html released] Oct 29th, 2010. See the original [http://lists.opensuse.org/opensuse-announce/2010-10/msg00009.html announcement] for 2.1 for more details about the new features and fixes. | ||
| Line 13: | Line 15: | ||
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. | 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 === | + | ==== 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: | 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: | ||
| Line 21: | Line 23: | ||
* finally, migrate to LDAP and disable current database backend | * finally, migrate to LDAP and disable current database backend | ||
| - | === Build System Project Reorg === | + | ==== 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: | At the moment, projects are organised based on usage scenarios or verticals. the main project is Trunk with the following vertical/UX based projects: | ||
| Line 36: | Line 38: | ||
* Reference or Applications (tentative name) | * Reference or Applications (tentative name) | ||
| - | '''Core''' would have all compliance libraries and OS base packages (essentials) and their | + | '''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. |
| - | 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: | There are two major advantages here: | ||
| - | * We can always guarantee that the core packages are self contained and | + | * We can always guarantee that the core packages are self contained and consistent without any bogus dependencies |
| - | consistent without any bogus dependencies | + | * When building compliant applications all you need is to build against'''Core''' which will guarantee that you do not link against libraries that are not available on all devices |
| - | * When building compliant applications all you need is to build against | + | |
| - | '''Core''' 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 | + | We started experimenting and have been splitting Trunk packages into core+application in the following devel area in the MeeGo Build System: |
| - | core+application in the following devel area in the MeeGo Build System: | + | |
* devel:cleanup:core | * devel:cleanup:core | ||
* devel:cleanup:reference | * 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 | + | 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. |
| - | 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: ] | ||
| + | |||
| + | [[Category:Build Infrastructure]] | ||
Contents |
MeeGo is currently running OBS 2.0.6 with minor changes specific to MeeGo:
See also: MeeGo and OBS: current state and roadmap session at MeeGo Conference 2010 (video and slides).
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.
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:
At the moment, projects are organised based on usage scenarios or verticals. the main project is Trunk with the following vertical/UX based projects:
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 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 started experimenting and have been splitting Trunk packages into core+application in the following devel area in the MeeGo Build System:
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.
Refer to /Release_Infrastructure for info on the tools Release Automation will be carried out in the follwoing order