[yocto-ab] Member involvement in the core of the project

[Philip Balister]

On 09/30/2016 06:17 AM, Richard Purdie wrote:
> One issue I've been giving some thought to is involvement of members
> and their developers in the core engineering of the project. There are
> several kinds of activity people undertake:
> 
> * Ownership of areas, reviewing and handling patches there
> * Stable branch maintainership
> * Bug fixing
> * Recipe ownership and maintenance
> * SWAT team (owns handling autobuilder monitoring/reporting)
> 
> We've a lot of interesting process pieces which I'd really like to
> expose to a wider audience as I think people don't realise the power of
> some of the automated tooling or testing infrastructure we have.

Richard is touching on some ideas that have worried me for quite some
time. Over the past 6 years, Intel has done a lot of work on the
project. To the point I'm concerned about the corporate bus factor.
We've all read the news, so it is no surprise that Intel is doing some
corporate soul searching. I have as much idea of anyone on this board
how that will play out.

OK, now that we've got that out of the way.

Clearly, OpenEmbedded was around before Intel and will be around for
many, many more years, regardless of any changes that may or may not
occur there.

This board is made up with representatives of companies that have
recognized the incredible value of collaborating to build a foundation
for building embedded systems.

The question is how to sustain the fine work of the past few years and
spread the development and maintenance burden over the larger community.
We've seen the results of the efforts of the past few years pay off in
broader project adoption, now we need to encourage users to start
contributing more and get more companies joining the Yocto Project.

Philip

> 
> One area that springs to mind is recipe maintainership. You can view
> the automated reporting we have at http://recipes.yoctoproject.org/rrs/
> recipes/2.2/M4/ and this tells us who maintains a given OE-Core recipe,
> what the current version is and what the current upstream release is
> at.
> 
> I'm sure that the role of recipe maintainer is not as well documented
> as perhaps it should be and this is something we can fix comparatively
> easily. It boils down to being responsible for updating to new versions
> when they become available and helping fix bugs in particular recipes
> if any arise. It also carries a responsibility to improve testing, be
> it by adding ptest to recipes if appropriate, or helping test recipes
> through our other automated test means. I'd like to suggest that member
> organisations each pick up responsibility for at least some handful of
> recipes.
> 
> We have a comparatively large test matrix and a level of test
> automation which I'm proud of. I'd love to see people learning about
> our tools (recipe reporting, devtool, etc.) and our testing techniques
> (ptest, oe-selftest, testimage, etc.) and then taking these into other
> layers and places.
> 
> Members technically are required to provide a development resource who
> works on the core of the project and we've traditionally not enforced
> this. Something like recipe maintainership could be an easily tracked
> and comparatively fair way of indicating involvement and support of the
> project and also would then encourage the above transfer of technology
> from the core layer into the wider ecosystem.
> 
> I was planning to raise this and discuss this further at the advisory
> board meeting but this would seem like a good place/time to start a
> discussion.
> 
> Thoughts/feedback/comments welcome.
> 
> I'm particularly open to other ideas on how we get members more
> involved.
> 
> Cheers,
> 
> Richard
>