Bitbake Architecture, Roadmap, Maintainers and the future

Bitbake Architecture, Roadmap, Maintainers and the future

[Richard Purdie]

There is a little friction around bitbake at the moment. I think after a
discussion I had with Chris earlier on some things are clearer and its
probably good to summarise how things stand.

I should make it clear I've not abandoned bitbake. Anyone who has
attended any OEDEM or other Yocto/Poky discussions will know that I
still think/talk a lot about it. I send RFC type emails about major
feature changes before implementation. I've also been actively
developing new bitbake features (checksums and sstate) which just
haven't been ready IMO for bitbake upstream until recently. People have
yet to see the real power of these but they're *very* close to being
useful in the real world now as anyone watching Poky will have seen.

Poky and bitbake upstream were in sync earlier this year. Unfortunately
a bad combination of circumstances have conspired to mean they've
diverged and I've not had a chance to sync between the two. Now I've
come to do so I've found some features I rely on as part of the roadmap
for bitbake have been removed, thus complicating the sync up and further
delaying it.

As a quick summary, the Poky bitbake has the checksum code and next
generation packaged-staging (sstate) whilst bitbake upstream has
parallel parsing and a number of other significant cleanups and features
such as the logging overhaul. For a while Poky's bitbake used a
different execution model to bitbake upstream but we've ended up backing
those changes out due to performance which took a long time and
complicated things as it wasn't desired (or particularly practical to
have that history in bitbake master).

Rightly or wrongly, maintainership of a project like bitbake is as much
about socialising changes and getting discussion and agreement on them
as it is about developing code. It eats a lot of time, you don't get
much thanks for it but it does make life smoother in the long run. I
tend to focus on this a lot having had bad experiences in the past where
ideas don't get socialised properly as it creates friction. I know
others much prefer just to share patches, request review and push, its a
different way of working. This is fine if you know one or the other is
going to happen but if one happens and you expect the other it causes
friction in itself. Discussion first can have benefits as "review" of
code already considered finished is hard as changes are unwelcome.

I consider myself a maintainer of bitbake as I've a long track record of
looking after the architecture of the project long term and ignoring the
past few  months, a strong record of improving the code base, certainly
not making it worse. I don't claim to write perfect code, far from it. I
do intend to continue to work steadily on improving bitbake as per the
roadmaps I've published over the past few years (taking on board input
from others as always as these aren't set in stone).

At present I don't know what role Chris wants to claim with regard to
bitbake, I have assumed now he's back working on it he wanted a
maintainership type role but that brings responsibility for roadmaps and
architecture discussion which I'm not sure he wants. I believe the
nature of bitbake needs these though.

So, bitbake in the future? At present it has bits on berlios (releases,
mailing list and a web manpage) and the git source SCM on
git.openembedded.org. Are we happy with those locations? I find it a bit
confusing...

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.

Some things bitbake does need are more regular releases and a decent
website and manual overhaul. I know Chris has helped the regular
releases and I appreciate that. I also appreciate the work Chris has
done on bitbake over the past while in general. I have mentioned this
before but people often forget to say thanks so I'll mention it again.
This email isn't meant in any negative way against Chris btw, I just
want to work out what we can do better in future.

For releases, I know the berlios interface isn't ideal and it might be
possible to automate things more which the investment might be worth it
into for more regular releases.

There is also the possibility Yocto could help in some way,
infrastructure wise, manpower to undertake certain tasks (release
automation) and maybe others. What I don't want is for any assistance
offered to be seen as "takeover" or other "interference" from Yocto as
that isn't the intention and I'd rather stay clear than have that
happen.

Thoughts/Comments?

Cheers,

Richard

Re: [Bitbake-dev] Bitbake Architecture, Roadmap, Maintainers and the future

[Khem Raj]

On Thu, Dec 30, 2010 at 6:42 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> There is a little friction around bitbake at the moment. I think after a
> discussion I had with Chris earlier on some things are clearer and its
> probably good to summarise how things stand.
>
> I should make it clear I've not abandoned bitbake. Anyone who has
> attended any OEDEM or other Yocto/Poky discussions will know that I
> still think/talk a lot about it. I send RFC type emails about major
> feature changes before implementation. I've also been actively
> developing new bitbake features (checksums and sstate) which just
> haven't been ready IMO for bitbake upstream until recently. People have
> yet to see the real power of these but they're *very* close to being
> useful in the real world now as anyone watching Poky will have seen.
>
> Poky and bitbake upstream were in sync earlier this year. Unfortunately
> a bad combination of circumstances have conspired to mean they've
> diverged and I've not had a chance to sync between the two. Now I've
> come to do so I've found some features I rely on as part of the roadmap
> for bitbake have been removed, thus complicating the sync up and further
> delaying it.
>
> As a quick summary, the Poky bitbake has the checksum code and next
> generation packaged-staging (sstate) whilst bitbake upstream has
> parallel parsing and a number of other significant cleanups and features
> such as the logging overhaul. For a while Poky's bitbake used a
> different execution model to bitbake upstream but we've ended up backing
> those changes out due to performance which took a long time and
> complicated things as it wasn't desired (or particularly practical to
> have that history in bitbake master).
>
> Rightly or wrongly, maintainership of a project like bitbake is as much
> about socialising changes and getting discussion and agreement on them
> as it is about developing code. It eats a lot of time, you don't get
> much thanks for it but it does make life smoother in the long run. I
> tend to focus on this a lot having had bad experiences in the past where
> ideas don't get socialised properly as it creates friction. I know
> others much prefer just to share patches, request review and push, its a
> different way of working. This is fine if you know one or the other is
> going to happen but if one happens and you expect the other it causes
> friction in itself. Discussion first can have benefits as "review" of
> code already considered finished is hard as changes are unwelcome.
>
> I consider myself a maintainer of bitbake as I've a long track record of
> looking after the architecture of the project long term and ignoring the
> past few  months, a strong record of improving the code base, certainly
> not making it worse. I don't claim to write perfect code, far from it. I
> do intend to continue to work steadily on improving bitbake as per the
> roadmaps I've published over the past few years (taking on board input
> from others as always as these aren't set in stone).
>
> At present I don't know what role Chris wants to claim with regard to
> bitbake, I have assumed now he's back working on it he wanted a
> maintainership type role but that brings responsibility for roadmaps and
> architecture discussion which I'm not sure he wants. I believe the
> nature of bitbake needs these though.
>
> So, bitbake in the future? At present it has bits on berlios (releases,
> mailing list and a web manpage) and the git source SCM on
> git.openembedded.org. Are we happy with those locations? I find it a bit
> confusing...
>
> 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.
>
> Some things bitbake does need are more regular releases and a decent
> website and manual overhaul. I know Chris has helped the regular
> releases and I appreciate that. I also appreciate the work Chris has
> done on bitbake over the past while in general. I have mentioned this
> before but people often forget to say thanks so I'll mention it again.
> This email isn't meant in any negative way against Chris btw, I just
> want to work out what we can do better in future.
>
> For releases, I know the berlios interface isn't ideal and it might be
> possible to automate things more which the investment might be worth it
> into for more regular releases.
>
> There is also the possibility Yocto could help in some way,
> infrastructure wise, manpower to undertake certain tasks (release
> automation) and maybe others. What I don't want is for any assistance
> offered to be seen as "takeover" or other "interference" from Yocto as
> that isn't the intention and I'd rather stay clear than have that
> happen.
>
> Thoughts/Comments?
>

it would be good to improve the manual or have some sort of testsuite.
For release I think Chris is doing a regular
releases recently. The release tars hosting could be moved from
berlios.de to where ever
bitbake is hosted right now its git it on openembedded.org and it
should be doable
to have a openemebedded.org/downloads/bitbake ... something like that.

Chris has been spending a lot of effort to merge poky/yocto changes
upstream lately and I sincerely applaud his efforts. Eventually I
think it would be good that yocto could use upstream bitbake instead
of having its own fork as it has now.


> Cheers,
>
> Richard
>
>
> _______________________________________________
> Bitbake-dev mailing list
> Bitbake-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bitbake-dev
>

Re: Bitbake Architecture, Roadmap, Maintainers and the future

[Andrea Adami]

On Fri, Dec 31, 2010 at 3:42 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> There is a little friction around bitbake at the moment. I think after a
> discussion I had with Chris earlier on some things are clearer and its
> probably good to summarise how things stand.
...

If I'm not wrong, Chris just finished the Poky-Sync on a personal branch:

https://github.com/kergoth/bitbake/tree/poky-sync

AFAIK he's trying to stabilize master before merging Poky's changes.
Just ask him :)

Regards

Andrea

Re: 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

Re: [Bitbake-dev] Bitbake Architecture, Roadmap, Maintainers and the future

[Marcin Juszkiewicz]

> There is a little friction around bitbake at the moment. I think after a
> discussion I had with Chris earlier on some things are clearer and its
> probably good to summarise how things stand.

Thank You Richard for mail.
 
> Rightly or wrongly, maintainership of a project like bitbake is as much
> about socialising changes and getting discussion and agreement on them
> as it is about developing code. It eats a lot of time, you don't get
> much thanks for it but it does make life smoother in the long run. 

> I consider myself a maintainer of bitbake

So do I - for me you are Bitbake maintainer. And I am fine with having Chris and you as maintainers.

> So, bitbake in the future? At present it has bits on berlios (releases,
> mailing list and a web manpage) and the git source SCM on
> git.openembedded.org. Are we happy with those locations? I find it a bit
> confusing...

I think that we should replace berlios with redirects to OE infrastructure. Tarballs should be available for download for any 1.8.0+ releases (older ones should not be in use now and can be generated from cgit). Manual available as separate website. I prefer to not host it at Yocto.
 
> 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.

I still have r/w to bitbake svn, no idea about git tree. There is no need for it so please remove my write access. If there will be a need for it I will send patches + pull request to proper mailing list.

Re: Bitbake Architecture, Roadmap, Maintainers and the future

[Richard Purdie]

On Fri, 2010-12-31 at 15:24 +0100, Esben Haabendal wrote:
> 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.

I know we've talked about your use of bitbake and I'm aware of it at
least.

The split between the code in general in bitbake is in general ever
improving in my opinion. Chris has some some really great work on
bitbake recently, particularly making it more pythonic. Some of the
changes just before the holidays, particularly the UI changes on the
cooker to UI relationship make me uncomfortable, particularly if they
mean the xmlrpc client/server code no longer works. My concern is that
they cross the boundary into what I'd class as regressing an API
boundary, particularly one that is only in the early stages of being
properly established and that we very much need. I don't know if this is
an API you use or not but its the kind of thing we need to be careful
about. FWIW, its independent of the parallel parsing code and other
changes which is partly why I'm so concerned it was merged as is :(.

> 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.

To put your mind at rest, there is no "policy" enforced by bitbake on
the way staging works in sstate. You might find the checksums useful and
you might be able to use them in your code but its all opt in. I'm
therefore not worried about this breaking OE-lite. If there are
problems, please just let us/me know and we'll see how we can fix that
but since everything is backwards compatible, it shouldn't be an issue.

> 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.

Its what the bitbake developers have always wanted/intended. It doesn't
mean bitbake won't change as the need for functionality appears but we
will do our best to keep things backwards compatible within reason
(although replaced functionality will still get phased out over time if
nobody needs it).

I would suggest it would be time well spent for you to find a way to be
able to use a standard upstream bitbake rather than requiring any patch
set as it will then be easier to understand what functionality and APIs
are being used and what impact changes to bitbake have.

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

I think I will be at FOSDEM and as always, am happy to talk :). I don't
think Chris is likely to be there based on previous FOSDEMs but I could
be wrong.

Cheers,

Richard

Re: Bitbake Architecture, Roadmap, Maintainers and the future

[Richard Purdie]

On Fri, 2010-12-31 at 11:26 +0100, Andrea Adami wrote:
> On Fri, Dec 31, 2010 at 3:42 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> > There is a little friction around bitbake at the moment. I think after a
> > discussion I had with Chris earlier on some things are clearer and its
> > probably good to summarise how things stand.
> ...
> 
> If I'm not wrong, Chris just finished the Poky-Sync on a personal branch:
> 
> https://github.com/kergoth/bitbake/tree/poky-sync
> 
> AFAIK he's trying to stabilize master before merging Poky's changes.
> Just ask him :)

I have talked to Chris both in person and over IRC. Recently this
consisted of personal insults thrown at me when I tried to talk about
technical details. I'm doing my best to ignore this and do something
about the technical stuff which is actually what matters.

Regarding the poky-sync branch, its a good move and I do really
appreciate it. I've also been working on the opposite part of the
problem of bringing Poky back into sync incrementally using atomic
commits rather than one big "sync" commit. Its been worthwhile as I've
found a few small areas I think functionality is still missing in
upstream despite the poky-sync branch and I'm going to be addressing
these to bring everything back 100% into sync again (as they were a few
months ago).

This work has been made particularly hard by the tendency of recent
bitbake commits to change several different things in one commit and for
small fixes to sneak into other unrelated commits too.

Cheers,

Richard

Re: Bitbake Architecture, Roadmap, Maintainers and the future

[Esben Haabendal]

On Sat, 2011-01-01 at 19:49 +0000, Richard Purdie wrote:

> The split between the code in general in bitbake is in general ever
> improving in my opinion. Chris has some some really great work on
> bitbake recently, particularly making it more pythonic. Some of the
> changes just before the holidays, particularly the UI changes on the
> cooker to UI relationship make me uncomfortable, particularly if they
> mean the xmlrpc client/server code no longer works. My concern is that
> they cross the boundary into what I'd class as regressing an API
> boundary, particularly one that is only in the early stages of being
> properly established and that we very much need. I don't know if this is
> an API you use or not but its the kind of thing we need to be careful
> about. FWIW, its independent of the parallel parsing code and other
> changes which is partly why I'm so concerned it was merged as is :(.

While when I first heard of the xmlrpc client/server code, I was
extremely exited, believing it was a near perfect fit for OE-lite.  But
later on I had second thoughtsBut looking more into it, I don't like the
complexity it adds. I believe that projects like OE, Poky and OE-lite is
best served by a BitBake implementation that is as simple as possible,
so that as many meta-data developers as possible will dare wander off
into BitBake code land also. So BitBake code improvement in general, and
simplification of BitBake in particular is on the road to better OE like
projects IMHO.

I haven't looked into the parallel parsing code yet, but hope to find
the time for it in the not so distant future.  As I am not using the
BitBake cooker, I assume I will have to hand-carry Chris' work on this
to OE-lite.

> > 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.
> 
> To put your mind at rest, there is no "policy" enforced by bitbake on
> the way staging works in sstate.

Great.  I assume also that the sstate code lives in the cooker part of
BitBake, right?

> You might find the checksums useful and
> you might be able to use them in your code but its all opt in. I'm
> therefore not worried about this breaking OE-lite.

I have a different checksums implementation, with a different
fundamental cooncept.  I do not try to figure out which variables is
(seemingly) related to a specific task, but simply checksums all
variables that is available to a task.  I plan to instead improve the
meta-data to remove unrelated variables.  This way, I don't have to
worry about calling python functions with access to the all-inclusive
'd' variable, and thus potentially voiding the generated signature.

This approach turns out to be much smaller in code size, so I am bit
reluctant to change course unless some really good technical arguments
mandates it.

> If there are
> problems, please just let us/me know and we'll see how we can fix that
> but since everything is backwards compatible, it shouldn't be an issue.

Well, as the API's I am using is not really in any form properly
formalized, I will not put to much money on BitBake staying backwards
compatible on them.

This leads to my #1 wishlist item for BitBake.  A real split between
BitBake as a parser and BitBake as a cooker (called baker in OE-lite,
just to stay in the bakery :).

Opposite to what seems to be the common belief, the current BitBake has
a rather strong linkage with OE (and thus Poky) meta-data, but all of
this seems to be concentrated in the cooker/runqueue code which has a
lot of assumptions on the dependency model used. So for a project like
OE-lite, using a different dependenncy model, the cooker/runqueue code
is not really usable. And I do not believe it would be sane to try and
code up a "super cooker" that handles multiple/any dependency models
thrown at it.  It would simply be to complex, and thereby making it
unreasonably difficult for innocent meta-data developers to figure out
what is going on. KISS.

> > 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.
> 
> Its what the bitbake developers have always wanted/intended. It doesn't
> mean bitbake won't change as the need for functionality appears but we
> will do our best to keep things backwards compatible within reason
> (although replaced functionality will still get phased out over time if
> nobody needs it).

I feel confident that yours "within reasons" is much stronger than I
would find reasonable, so no worries here ;-)

> I would suggest it would be time well spent for you to find a way to be
> able to use a standard upstream bitbake rather than requiring any patch
> set as it will then be easier to understand what functionality and APIs
> are being used and what impact changes to bitbake have.

I actually already did 99.9% of that work.  The first work was some kind
of work-in-progress/prototype, with a lot of ugly hacking to get the
cooker/runqueue code to do what I needed.  I have now reimplemented this
entirely in OE-lite, and using an (almost) upstream BitBake for parsing
and task execution.

The main change is a rather innocent addition of recdeptask (similar to
recrdeptask, just for build dependencies), and recadeptask (a special
kind of "any" recursive dependency I need for fetchall and stuff like
that).

The __init__.py code is a fix or workaround, I would like to discuss
here on list, as I am not sure if that is a proper fix for upstream, and
if not, how to fix it properly (or if it is even considered a bug in
BitBake).

eha@fire:~/oe-lite/master/bitbake$ git diff oe/master|diffstat
 __init__.py       |    1 +
 build.py          |    2 ++
 fetch/__init__.py |    3 +++
 3 files changed, 6 insertions(+)

I should be safe and make sense to get the recdeptask/recadeptask into
upstream, but on the other hand, it is not really a big issue to keep it
in an OE-lite branch.  But having this in upstream BitBake would make it
possible for users to use any new upstream BitBake, although a big YMMV
boiler plate will have to be placed on it.

> > If possible, perhaps we could have a small BitBake meeting at FOSDEM,
> > trying to coordinate the way forward?
> 
> I think I will be at FOSDEM and as always, am happy to talk :). I don't
> think Chris is likely to be there based on previous F
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
> OSDEMs but I could
> be wrong.

With Chris being the most active BitBake maintainer right now, I hope to
find him there as well.

But I will of-course be very much interested in talking with you about
the future of BitBake anyways.  See you there!
 
/Esben

Re: Bitbake Architecture, Roadmap, Maintainers and the future

[Chris Larson]

On Sat, Jan 1, 2011 at 12:49 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> The split between the code in general in bitbake is in general ever
> improving in my opinion. Chris has some some really great work on
> bitbake recently, particularly making it more pythonic. Some of the
> changes just before the holidays, particularly the UI changes on the
> cooker to UI relationship make me uncomfortable, particularly if they
> mean the xmlrpc client/server code no longer works. My concern is that
> they cross the boundary into what I'd class as regressing an API
> boundary, particularly one that is only in the early stages of being
> properly established and that we very much need. I don't know if this is
> an API you use or not but its the kind of thing we need to be careful
> about. FWIW, its independent of the parallel parsing code and other
> changes which is partly why I'm so concerned it was merged as is :(.

Unless you think parallel parsing is the only work I've done on
bitbake, I fail to see what it being independent of parallel parsing
has to do with anything.  Of course it's independent.  It's entirely
different work for an entirely different purpose, done on different
branches, and trying to compare them is pointless and means nothing.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [Bitbake-dev] Bitbake Architecture, Roadmap, Maintainers and the future

[Richard Purdie]

On Tue, 2011-01-04 at 07:56 -0700, Chris Larson wrote:
> On Sat, Jan 1, 2011 at 12:49 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > The split between the code in general in bitbake is in general ever
> > improving in my opinion. Chris has some some really great work on
> > bitbake recently, particularly making it more pythonic. Some of the
> > changes just before the holidays, particularly the UI changes on the
> > cooker to UI relationship make me uncomfortable, particularly if they
> > mean the xmlrpc client/server code no longer works. My concern is that
> > they cross the boundary into what I'd class as regressing an API
> > boundary, particularly one that is only in the early stages of being
> > properly established and that we very much need. I don't know if this is
> > an API you use or not but its the kind of thing we need to be careful
> > about. FWIW, its independent of the parallel parsing code and other
> > changes which is partly why I'm so concerned it was merged as is :(.
> 
> Unless you think parallel parsing is the only work I've done on
> bitbake, I fail to see what it being independent of parallel parsing
> has to do with anything.  Of course it's independent.  It's entirely
> different work for an entirely different purpose, done on different
> branches, and trying to compare them is pointless and means nothing.

I'd implied it might have been related in a previous email and I was
correcting that implication, nothing more, nothing less.

Trying to establish whether the threading code in the parallel parsing
is related or unrelated to the threading code for the UI is a perfectly
reasonable technical question. It is possible there were
interdependencies, it turns out there aren't.

This kind of response from you is frustrating. Trying to ask any
question results in a response like this and I don't think its
productive or helpful.

Cheers,

Richard

Re: [Bitbake-dev] Bitbake Architecture, Roadmap, Maintainers and the future

[Otavio Salvador]

On Tue, Jan 4, 2011 at 13:39, Richard Purdie <rpurdie@rpsys.net> wrote:
...
> This kind of response from you is frustrating. Trying to ask any
> question results in a response like this and I don't think its
> productive or helpful.

Can we try to get something done instead of this useless type of discussion?

-- 
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: [Bitbake-dev] Bitbake Architecture, Roadmap, Maintainers and the future

[Richard Purdie]

On Tue, 2011-01-04 at 15:00 -0200, Otavio Salvador wrote:
> On Tue, Jan 4, 2011 at 13:39, Richard Purdie <rpurdie@rpsys.net> wrote:
> ...
> > This kind of response from you is frustrating. Trying to ask any
> > question results in a response like this and I don't think its
> > productive or helpful.
> 
> Can we try to get something done instead of this useless type of discussion?

I really don't know what Chris is/isn't prepared to do in future to
ensure this doesn't happen again but I'm doing what I can in that
regard.

I'm pleased to report Poky's copy of bitbake is now much more in sync
with bitbake master as of earlier today. This has resulted in some
issues for Poky but thats life and we're working through them, its not a
problem.

I've asked Chris what the status of his poky-sync branch is and assuming
some further testing pans out I think that will get merged into bitbake
master soon.

This leaves some small details to sort out as I think there are still
some tweaks bitbake upsteam needs from Poky. I'm trying to work out
those details and will follow up in other emails. I've already started
some of the discussion in the logging thread for one of the areas there
are differences in approach.

I'm also going to look at getting back the XMLRPC interfaces and
abstraction that the removal of triggered this discussion. There does
appear to be some differences in opinion on the future of bitbake from
the server/UI perspective and I will do what I can to ensure we all have
common goals.

I've also agreed that I'm going to pay close attention to the
bitbake-dev list. I've asked that any major roadmap/architecture changes
do get discussed there.

Cheers,

Richard

Re: [Bitbake-dev] Bitbake Architecture, Roadmap, Maintainers and the future

[Chris Larson]

On Tue, Jan 4, 2011 at 4:17 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> I'm also going to look at getting back the XMLRPC interfaces and
> abstraction that the removal of triggered this discussion. There does
> appear to be some differences in opinion on the future of bitbake from
> the server/UI perspective and I will do what I can to ensure we all have
> common goals.
>

To clarify, the abstraction is not gone, only the server is.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics