Possibly better called a Product Builder Landing Page
This page is at the outline stage and is still a work in progress. Please feel free to edit and add sections and missing parts but I'd appreciate it if you discuss with me (David Greaves, lbt on irc) before making major changes (like deleting sections or re-organising)
Yes it's in HTML and not wiki flavour for now.
1 Overview
The objective of this document is to provide a comprehensive introduction to MeeGo for Product Builders: MeeGo's primary customers.
The initial focus is on small businesses or incubation / innovation centres within potential customer organisations. Here the target is to rapidly establish and/or evaluate a representative MeeGo product building environment based on continuous integration principles.
As MeeGo is adopted key systems and operational areas will need to scale as projects move towards full production.
2 CI Against MeeGo
2.1 Understanding and Following MeeGo
2.1.1 MeeGo Structures
These areas of MeeGo are of most relevance to product builders:
- Governance and Teams (RE, QA, SDK, Developers) https://meego.com/about/governance
- Architecture http://meego.com/developers/meego-architecture
- Projects https://meego.com/projects
- Git repos http://meego.gitorious.org/
- OBS Projects https://build.meego.com/project/list_public
- QA information http://wiki.meego.com/Quality
- Software releases http://wiki.meego.com/Release_Engineering/Process Note that this is a description of how MeeGo itself is developed and released; products based on MeeGo will include similar elements but will have significant variations. This will be covered later in this document.
2.1.2 Product Layers
MeeGo product projects are expected to broadly follow a three-layered model comprising
- Hardware Adaptation and Kernel
The hardware adaptation layer focuses on the low-level drivers and is usually developed in close conjuntion with an MCE.
- Middleware
Product builders are expected to be an active part of the development community and will be involved in rectifying errors and in influencing and contributing to the evolution of MeeGo.
- User Experience / Value Add
This layer is where vendors will differentiate their offerings and are expected to offer independently developed
2.1.3 The CE 'Reference Vendor' Project
The MeeGo community maintains a project and associated systems to emulate the workings of a product builder. This project complements the primary MeeGo deliverable and aims to:
- challenge and validate the software and process interfaces that MeeGo presents to customers
- exemplify the principle of "working in the open"
- refine and contibute to MeeGo tools, systems and working practices
- develop reference UXes which are optionally useable by vendors
- provide an observable and educational project which encourages external contibutors to participate and learn about MeeGo
- openly operate independent and representative systems to validate and demonstrate vendor <=> MeeGo system interoperability
- deliver an open MeeGo product
2.1.4 Roadmap data
2.1.5 Delivery status
- Feature status
- Bugs Status
- QA Status
2.1.6 Collaboration Tools
- Mailing Lists
MeeGo generates a huge amount of email traffic. It is split across a wide range of mailing lists and identifying and tracking those relevant to your role is important.
- IRC
Internet Relay Chat supports realtime text chat and enables collaboration between a large number of geographically diverse contributors. It is an important part of the MeeGo development process. Individual rooms address specific topics.
- Wiki
The MeeGo wiki is a collaborative documentation area. It contains much useful information but currently (Jun 2011) it is not very organised or maintained.
2.2 A Week In The Life of a Product Builder
Discuss how integration works internally, with upstream and with MeeGo for each of the 3 layers. Look at pulling in daily and weekly snapshots; considering whether there are too many regressions and using Trunk to identify impending breakage. Submitting, tracking and chasing bugs and features.
2.3 Developing on MeeGo
Links to SDK and OBS development information. Discussion of the developer role,
2.4 Week to Week Reporting
Layer and Image oriented QA reports covering bugs and features
2.5 Confidential Stuff
Bugs
2.6 Product Builder Essential Systems
Whilst it is possible to use alternatives, the following systems are essentially mandatory for any serious product development activity.
2.6.1 GIT / DVCS
A distributed version control system is essential. The OBS can provide rudimentary CM but it is not suitable for code development.
MeeGo systems are generally oriented towards git but others can be used in addition.
2.6.2 OBS
The OBS allows developers to compile and build on a central build service as well as on their local machines.
2.6.3 Bugzilla
Used to track defects and features. Bugzilla has been enhanced by the MeeGo community to support many capabilities needed by modern development methodologies. The goal of these enhancements is to make Bugzilla suitable as 'Your Only Tool' for bug, feature and time tracking.
2.6.4 OTS
The MeeGo test framework. OTS is designed for automated device oriented testing in a production environment.
2.6.5 BOSS
An business process automation tool; BOSS allows extensive automation of many of the code and data flows involved in building a MeeGo product. These include process, policy and quality checks as well as automating releases, dvcs to build automation, bug handling, notifications and information system feeds.
2.6.6 REVS
A management information system for release managers with package database information.
2.7 Useful Systems
2.7.1 MXR
MXR is a code indexing and cross-reference tool.
2.8 Roles and Responsibilities
2.8.1 Developers
2.8.2 Integrators
2.8.3 Translators
2.8.4 Testers
2.8.5 Documentors
2.9 Traversing a Major Release
Creating new platforms and branching VCSs for packages. Compliance issues if anticipated features are deferred to the next release.
3 Getting Started
3.1 Systems
3.1.1 Small / Evaluation Deployment
This section is for smaller deployments with a few developers (1 to 10 or so). The focus is on a rapid deployment and not on productionisation.
- GIT Server
- OBS Appliance
- BOSS VM
- Bugzilla Appliance
3.1.2 Medium / Productised
The main difference here is that additional systems will be deployed and the level of resilience and administration will increase.
- OBS and workers
- BOSS
- Resilience
3.1.3 Large
- Distributed OBS and worker pool
3.2 Teams
3.2.1 Hardware Adaptation
3.2.2 Middleware
3.2.3 UX / Value Add
3.3 Automation
Deploying new processes.
4 Benefits
4.1 MeeGo
Consistent approach from vendors
4.2 Vendors
Date: 2011-06-05 00:00:50 BST
HTML generated by org-mode 7.3 in emacs 23