Jump to Navigation

BoF: MeeGo DE - *THAT* is how you do it

Session Summary: 
MeeGo is (or should be) aimed at vendors : this BoF is about continually validating that goal. It will discuss extending the "DE Project Vision" to include "Be a reference vendor". We will identify deliverables such as documentation about processes, organisational layout and tool usage. We will identify how we test, challenge and improve the MeeGo <-> Vendor interface in the open. See: http://mer-l-in.blogspot.com/2011/04/meego-de-that-is-how-you-do-it.html
Session Abstract: 

Carsten outlined the "MeeGo DE LTP (Long Term Plans)"

Constraints:
* A MeeGo project, not dependent on any vendor
* Get the most out of existing MeeGo investment on a stable and public devices.
* For the benefit of the MeeGo community.
* Emulating a vendor working with MeeGo and sharing the results in real-time, in the open.
* Just for fun

This session will focus on "For the benefit of the MeeGo community" and how DE should help a vendor get started, decide what setup is needed and go into details such as the OBS project structure and role-specific processes that are needed for various types of deployment.

To do this DE must undertake all 3 aspects of a vendor:

* The Veneer ("Value Add Layer" if you're marketing a device)
* Hardware Adaptation
* Contributing Back (A phb may prefer to hear: "Influencing MeeGo's direction")

How will DE differentiate and manage these roles?

David proposes the use of MeeGo tools as a success criteria (for both DE and MeeGo tools): Is this feasible? If so then how should DE use MeeGo tools to deliver their product? What managment reports from REVS are needed? What BOSS automation? How does OTS work in DE?

DE should aim to be held up as an example of "How to work with MeeGo" ; with real deliverables beyond supporting a specific device and to provides a tangible benefit to everyone in MeeGo.

Some general deliverables from DE project:

* Clear product-oriented and release-managed deliverables in the veneer layer with testing and automation
* Documentation of a requirements driven approach to MeeGo core contributions
* Documentation of a requirements driven approach to hardware adaptation

How do we provide a clear "Developer to Device" story:

* DVCS -> OBS (development)
* OBS -> repo (integration)
* repo -> Image (publish)
* Image testing (test)
* Bug/FEA tracking and reporting
* Continuous Integration ? (DE can't afford to build&test an image per git commit)

How do we "Test, challenge and improve the MeeGo <-> vendor interface in the open"
* Features
* Bugs
* Releases (Live/daily/weekly/etc)
* Managing release-time branching
* Infrastructure & Services
* Best practice for HW, operations
* Deployed system information
* Change processes (outages, upgrades, OBS target changes)

Sessions Details

  • BoF
    24 May 14:30 - 15:10

The conference organizing committee has put together slide templates for presenters to use if they so choose. Feel free to take and modify as you like!