(Go and get yourself a coffee) :)

The idea of this new group has gained enough traction such that we have decided to run multiple sessions at Connect. Before we can start to plan the sessions however, we need to gain a better idea of interested parties. So, who and in what capacity do people wish to participate?

What is the SoC Technology Group (STG)?

Broadly speaking it's a splinter/pseudo group of technical engineers from each applicable Working Group. Although it could easily contain members from Platform, Infrastructure and/or Landing Teams. The primary role of the STG would be to enable feature sets being produced by the Working Groups on each of our supported boards. This team will focus heavily on the upstream kernel.

Discussion sessions at Connect

Interested parties should be encouraged to attend these sessions. It is here that we shall knock some kind of proposal into shape. There are currently lots of unknowns and loose ends which we need to tie up. Some of the important items shall be mentioned in this email and can be discussed accordingly, others will undoubtedly crop up along the way.

A clearly defined road map will need to be defined: 1. Detailing whether we intend to (and are capable of) parallelising development, so that each board is being worked on concurrently. Our members would be less than pleased if we were to prioritise our platforms and theirs were found at the bottom of the list. There are many ways in which we can utilise our limited resources to make this happen, but it will take some careful deliberation in order to figure out an optimal way of working. 2. Detailing which features are the most important for our members. Once decided we need to create a prioritised feature list which will be worked through in sequence.

Engineering resources is clearly going to be a touchy subject. Some of the Working Groups are already feeling over-worked and under staffed, but engineers need to come from somewhere. To ease the strain I propose an assignee rotation solution. Swapping out old for new on a per-cycle or per-board enablement basis. The latter is the preferred solution, as it ensures that there are no ends to tie-up and that a feature will be complete before the STG saw fresh blood requiring learning-curve post context-switch.

Carrying on with the resources theme, other teams from within Linaro have offered support. As the work is meaningful and interesting there should be no shortage of volunteers. Should the STG consist of members from Platform for instance, or can some of the work be sub-contracted out to them instead?

Hacking sessions at Connect

Anyone who's interested in undertaking some real coding that will end-up upstream should attend these sessions. There will be plenty of interesting work available to share around. No upstreaming experience necessary. As long as you are capable of turning documentation into functional code I'm sure we can put you to good use. :)

Hacking sessions will require clear documentation detailing the APIs for each piece of functionality we wish to enable. Does this already exist? If so, where can it be acquired (http://g.l.o/<wg-tree>/Documentation/)? In the absence of clear documentation, would the WGs provide a Subject Matter Expert (SME) to adopt the role of mentor for the sessions? Or better still, both.

As already discussed, we require a detailed, prioritised feature list of missing (i.e. to be coded) and enabled (i.e. fully implemented) features for each board from each of the participating Working Groups.

Topics summarised

- Discuss: Platform development concurrency strategy - Discuss: Assignee rotation/permanent re-assignment

- Required: Documentation - Required: Engineering resources (during the sessions and in the team) - Required: Prioritised missing/enabled feature lists for each platform

I think that'll do for now. :)

Kind regards, Lee