(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//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
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
