[oe] OEDEM - Summary of some the outcome

[Richard Purdie]

I think the OE Developer meeting was productive and there were some good
discussions. I'd like to start to share some of these with the members
and wider community as there were also some decisions made based on the
discussions and its important to place these in context.

e.V. Meeting
============

It is not my place to report on this so I will leave that to the
official minutes. I'll just say that it took place and was very
positive.

Technical Steering Committee
============================

This was mentioned during the e.V. meeting such that the e.V. board has
been asked to establish a TSC by the members. The wiki was updated with
the key parts of the discussion:
http://wiki.openembedded.net/index.php/TSC

We agreed that 5 people was a good number for this group as there could
be no vote deadlock due to the odd number and that 7 people was probably
too large. Since there are six candidates this means that we need to
vote but that gives members a choice and is therefore perhaps a good
thing. Any further candidates have a short while (a few days?) to come
forward before the board sets up and holds an online vote.

It was highlighted that the people on the TSC are expected to look into
issues and understand them so they can give an opinion so abstaining
from voting on the TSC is not going to reflect well on any person doing
that.

Its expected that people should attempt to resolve issues in the
community first. If that fails a decision can be requested from the TSC
on an issue. TSC decisions will be listed somewhere public. The TSC does
not have to be asked to take action on something, it can issue a
decision without one being requested if it fulfils the objectives and
obligations of the TSC.


Bitbake Roadmap
===============

I presented a summary of the document I sent out via email a short while
ago. In summary, the 1.8 days are coming to an end and 1.10 is now the
future plan. its objective is to sync the good bits from the master
branch client/server split so we can reduce the divergence and then we
can fix the remaining issues with master. The client/server split
remains the objective for a bitbake 2.0 release.

We have the 1.8.16 release (1.8.14 was a mess, sorry about that) and we
agreed we should bump the minimum version requirement in OE.dev so we
can start using features in there like BBCLASSEXTEND and dropping
unneeded "import bb" and "import os" statements.


OE Core Changes
===============

I put the case forward that OE needs to evolve and that other projects
are showing neat features we don't have and that are hard to add to OE
in its current state. My biggest concerns are about our staging process
as other people like e2factory have a neat checksum feature for "staging
packages" and we'd love to have them but staging is such a mess its
effectively strangling us.

Whilst in the future core changes are something the TSC will be
responsible for reaching a decision on it was felt that there was
sufficient people at OEDEM to reach a decision about some current
proposals until the TSC is established, particularly due to the presence
of TSC candidates, OE e.V. board members and members of the former OE
core team.

The proposals were:

a) Adopt the removal of the layout_* variables from Poky.
b) Change the do_populate_staging/do_stage functions to use the results 
   from the do_install step as proposed in other emails
c) Adopt the native.bbclass changes from Poky to allow use of 
   BBCLASSEXTEND = "native"
d) Start removing legacy do_stage functions and convert exclusively to 
   the new model
e) Start converting recipes to BBCLASSEXTEND = "native"
f) Merge the new canadian SDK classes from Poky and start a gradual 
   conversion to them with a view to obsoleting the existing sdk and 
   canadian recipes.
g) Rename "do_populate_staging" to "do_populate_sysroot" and 
   "TMPDIR/staging" to "TMPDIR/sysroots" to reflect how much this 
   directory has changed and to truly reflect its contents. The word 
   "staging" confuses a lot of new users in my experience.

The transition path was discussed and it was agreed that everything that
can reasonably be done has been done with regard to minimising breakage.
Phil proposed adding a staging comparison mode to the new staging
function which would help with the transition.

A target of the end of the year was set of transitioning all staging
functions and the removal of all legacy staging methods. These changes
will therefore be merged into OE.dev forthwith after a tag has been
made. It was felt it was better to get on and make the changes quickly
in one go rather than spreading them out and needing repeated testing
after each set.


Questions/comments/feedback etc. all welcome!

Cheers,

Richard