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

Richard Purdie rpurdie at rpsys.net
Tue Jan 4 15:39:29 UTC 2011


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






More information about the Openembedded-devel mailing list