OEDEM - Summary of some the outcome

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

Re: OEDEM - Summary of some the outcome

[Marco Cavallini]

Richard Purdie ha scritto, Il 09/11/2009 11:36:
> 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.

.snip.

> Cheers,
> 
> Richard


Excellent report and reminder,
thank you Richard.


Cordiali Saluti / Kindest Regards / mit freundlichen Grüssen
--
Marco Cavallini | KOAN sas | Bergamo - Italia
 embedded and real-time software engineering
   Atmel third party certified consultant
Phone:+39-035-255.235 - Fax:+39-178-22.39.748
      http://www.KoanSoftware.com

Re: OEDEM - Summary of some the outcome

[Rolf Leggewie]

Richard,

thank you for the information.

I have one question and one comment.

Richard Purdie wrote:
> too large. Since there are six candidates this means that we need to

Who are the six candidates?  I can't find their names in the wiki or
elsewhere easily.

> 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

It would have been nice to make sure that Debian actually has 1.8.16
before making it a requirement.  I prefer to use packaged software so I
can worry about other things.

Regards

Rolf

Re: OEDEM - Summary of some the outcome

[Richard Purdie]

On Tue, 2009-11-10 at 10:13 +0900, Rolf Leggewie wrote:
> Richard Purdie wrote:
> > too large. Since there are six candidates this means that we need to
> 
> Who are the six candidates?  I can't find their names in the wiki or
> elsewhere easily.

They are listed in the wiki, albeit with a title that could be better:
http://wiki.openembedded.net/index.php/Oedem/2009_TSC_election

> > 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
> 
> It would have been nice to make sure that Debian actually has 1.8.16
> before making it a requirement.  I prefer to use packaged software so I
> can worry about other things.

That is unfortunate but I suspect if we waited until everyone's personal
favourite distro adopted it, we'd impose artificial limits on what is a
development branch. No easy solution really :(.

Cheers,

Richard

Re: OEDEM - Summary of some the outcome

[Otavio Salvador]

Hello,

On Mon, Nov 9, 2009 at 11:50 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> That is unfortunate but I suspect if we waited until everyone's personal
> favourite distro adopted it, we'd impose artificial limits on what is a
> development branch. No easy solution really :(.

Even being a big fan of Debian I must to agree here; OE shouldn't wait
for distros to make changes otherwise we'll have a nightmare to
manage.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: OEDEM - Summary of some the outcome

[Frans Meulenbroeks]

2009/11/10 Otavio Salvador <otavio@ossystems.com.br>:
> Hello,
>
> On Mon, Nov 9, 2009 at 11:50 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
>> That is unfortunate but I suspect if we waited until everyone's personal
>> favourite distro adopted it, we'd impose artificial limits on what is a
>> development branch. No easy solution really :(.
>
> Even being a big fan of Debian I must to agree here; OE shouldn't wait
> for distros to make changes otherwise we'll have a nightmare to
> manage.

actually installing it from scratch is not really a big deal anyway,
grab the tarball (I used wget
http://download.berlios.de/bitbake/bitbake-1.8.16.tar.gz)
untar to the right place, then rename dir to bitbake; then python
setup.py build and optionally python setup.py install

And RP, thanks for the report! Very appreciated!

Frans

Re: OEDEM - Summary of some the outcome

[Phil Blundell]

On Tue, 2009-11-10 at 10:13 +0900, Rolf Leggewie wrote:
> It would have been nice to make sure that Debian actually has 1.8.16
> before making it a requirement.  I prefer to use packaged software so I
> can worry about other things.

Remember that bitbake doesn't need to be installed (into /usr or
anywhere else): you can run it directly from a checkout in your OE
working directory.  That ought to be a reasonable stopgap for most
people until the distributions catch up.

p.

Re: OEDEM - Summary of some the outcome

[Otavio Salvador]

Hello,

On Tue, Nov 10, 2009 at 9:35 AM, Phil Blundell <pb@reciva.com> wrote:
> Remember that bitbake doesn't need to be installed (into /usr or
> anywhere else): you can run it directly from a checkout in your OE
> working directory.  That ought to be a reasonable stopgap for most
> people until the distributions catch up.

This is how I use it; in fact I use a git clone :-)

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: OEDEM - Summary of some the outcome

[Phil Blundell]

On Mon, 2009-11-09 at 10:36 +0000, Richard Purdie wrote:
> 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.

I think there was one more:

h) Enable packaged staging as default, with a view to making it
mandatory after a suitable transition period.

p.