[oe] Bitbake Architecture, Roadmap, Maintainers and the future

[Esben Haabendal]

Hi

On Fri, 2010-12-31 at 02:42 +0000, Richard Purdie wrote:

> There are a bunch of people who can commit to bitbake, some inactive,
> some active in different areas with different priorities. I think mine
> are clear above, I'd appreciate others to make their objectives clear so
> everyone understand people's positions and what people plan and don't
> plan to do.

While I do not and cannot be considered a maintainer in any form, I do
have a special use for BitBake.  I use an (almost) upstream BitBake as
part of the OE-lite project, and as such has rather strong investment in
BitBake.

I do not use BitBake as a command, but as a Python module, as OE-lite
has a different dependency and runqueue/cooker model.  Because of this I
hope to find some time improve the separation between the parser, data
and cooker in BitBake, but I will surely notice and have to do something
about it if BitBake is regressed with regards to this.

As for merging with sstate, OE-lite uses a completely different staging
model (simple per-recipe package based), and I would be very unhappy if
merging sstate into BitBake will make it impossible for OE-lite to use
upstream BitBake.  I haven't looked enough into the sstate
implementation with regards to this yet though.

Most of all, I would like to stress that there actually are other users
of BitBake than OE and Poky. I hope this is considered a good thing seen
from a BitBake perspective, and not a disturbance.

If possible, perhaps we could have a small BitBake meeting at FOSDEM,
trying to coordinate the way forward?

Oh, btw.  I feel completely comfortable with Chris as BitBake maintainer,
that were 

/Esben