All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: Chris Larson <clarson@kergoth.com>
Cc: bitbake-dev <bitbake-dev@lists.berlios.de>,
	openembedded-devel@lists.openembedded.org
Subject: Re: [Bitbake-dev] Bitbake Architecture, Roadmap, Maintainers and the future
Date: Tue, 04 Jan 2011 15:39:29 +0000	[thread overview]
Message-ID: <1294155569.17519.21577.camel@rex> (raw)
In-Reply-To: <AANLkTi=YuEBqPtCGnutaW_-JF0F=ZwmT8OS8rCmr9886@mail.gmail.com>

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





  reply	other threads:[~2011-01-04 15:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-31  2:42 Bitbake Architecture, Roadmap, Maintainers and the future Richard Purdie
2010-12-31  3:33 ` [Bitbake-dev] " Khem Raj
2010-12-31 10:26 ` Andrea Adami
2011-01-01 19:59   ` Richard Purdie
2010-12-31 14:24 ` Esben Haabendal
2011-01-01 19:49   ` Richard Purdie
2011-01-02  8:18     ` Esben Haabendal
2011-01-04 14:56     ` Chris Larson
2011-01-04 15:39       ` Richard Purdie [this message]
2011-01-04 17:00         ` [Bitbake-dev] " Otavio Salvador
2011-01-04 23:17           ` Richard Purdie
2011-01-04 23:30             ` Chris Larson
2011-01-01 19:05 ` Marcin Juszkiewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1294155569.17519.21577.camel@rex \
    --to=rpurdie@rpsys.net \
    --cc=bitbake-dev@lists.berlios.de \
    --cc=clarson@kergoth.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.