[oe] Bitbake Architecture, Roadmap, Maintainers and the future
eha at doredevelopment.dk
Fri Dec 31 15:24:34 CET 2010
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
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,
More information about the Openembedded-devel