Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Trevor Woerner <trevor.woerner@linaro.org>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [RFC PATCH 0/7] Developer workflow improvements
Date: Mon, 01 Dec 2014 23:36:23 -0500	[thread overview]
Message-ID: <547D41C7.5020303@linaro.org> (raw)
In-Reply-To: <11435118.DSGP9nSeOe@peggleto-mobl5.ger.corp.intel.com>


On 12/01/14 05:11, Paul Eggleton wrote:
> On Friday 28 November 2014 12:28:00 Trevor Woerner wrote:
>> Perhaps any recipe you're working on could be automatically included via
>> an IMAGE_INSTALL_append in conf/local.conf (or maybe that's too intrusive?)?
> This is something I'd wanted to do - it's certainly something that should be 
> made easy, but I was concerned about causing a full reparse just because of 
> adding that to local.conf. (There might be a workaround through some sort of 
> packagegroup for containing the packages produced by the recipes in the 
> workspace that is added once when we create the workspace - maybe that's the 
> answer?)

Maybe even just printing a bit of text after a successful "add" to
inform the user that the just-added project isn't part of any image and
what they might want to do to include it?

The packagegroup sounds good too. But if the user doesn't want it
included, they might be confused about how it magically appeared, and
have some trouble finding how to remove it.

>> Do you envision users creating multiple workspaces? I'm wondering why
>> "devtool create-workspace" is required. Is there any advantage to
>> requiring users to create the workspace explicitly instead of just
>> having it be created implicitly?
> I wouldn't expect users to want to create multiple workspaces, but I did want 
> users to be able to (a) choose where their workspace would go and (b) know 
> that it has been created, so that the workspace layer showing up in the 
> configuration isn't a surprise.

I can't help think that there's no harm in an unused workspace (is
there?). Maybe the empty workspace from "create-workspace" should just
be created by default by the "oe-init-build-env" tool (or whatever a
given project is using).

If I were writing the documentation for this workflow, or giving a
presentation on it... I'm just trying to figure out how to justify the
extra, empty (but necessary) step of creating the environment before
using it. Maybe if someone tries to add a project before creating the
workspace, instead of erroring out, just run the create-workspace for
them with the defaults. If they're a power user who wants to put the
workspace somewhere specific then they're free to explicitly call
create-workspace on their own, otherwise it'll get called with the
defaults for them (or created automatically as part of the
oe-init-build-env).

To borrow the analogy from git: create-workspace is part of the pluming;
it's there if people what to call it explicitly, otherwise it gets
called implicitly with defaults?


  reply	other threads:[~2014-12-02  4:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25 17:28 [RFC PATCH 0/7] Developer workflow improvements Paul Eggleton
2014-11-25 17:28 ` [RFC PATCH 1/7] lib/oe/patch: fall back to patch if git apply fails Paul Eggleton
2014-11-25 17:40   ` Paul Barker
2014-11-25 17:58     ` Paul Eggleton
2014-11-25 17:28 ` [RFC PATCH 2/7] lib/oe/patch: auto-commit when falling back from git am Paul Eggleton
2014-11-25 17:28 ` [RFC PATCH 3/7] lib/oe/patch: use --keep-cr with " Paul Eggleton
2014-11-25 17:28 ` [RFC PATCH 4/7] scripts/recipetool: Add a recipe auto-creation script Paul Eggleton
2014-11-25 17:28 ` [RFC PATCH 5/7] lib/oe: add recipeutils module Paul Eggleton
2014-11-25 17:28 ` [RFC PATCH 6/7] scripts/devtool: add development helper tool Paul Eggleton
2014-11-25 17:28 ` [RFC PATCH 7/7] scripts/devtool: Support deploy/undeploy function Paul Eggleton
2014-11-25 17:51 ` [RFC PATCH 0/7] Developer workflow improvements Paul Barker
2014-11-25 18:34   ` Paul Eggleton
2014-11-25 19:56 ` Trevor Woerner
2014-11-26  9:02   ` Paul Eggleton
2014-11-28 17:28 ` Trevor Woerner
2014-12-01 10:11   ` Paul Eggleton
2014-12-02  4:36     ` Trevor Woerner [this message]
2014-12-02 11:46       ` Paul Eggleton
2014-12-04 14:03         ` Trevor Woerner
2014-12-04 15:33           ` Paul Eggleton
2014-12-02  4:54 ` Trevor Woerner
2014-12-02 14:01   ` Paul Eggleton
2014-12-09 15:47     ` Trevor Woerner
2014-12-11 23:10       ` Trevor Woerner
2014-12-12 12:39         ` Paul Eggleton
     [not found] ` <54866CD7.1050102@linaro.org>
     [not found]   ` <7839390.odV1UMkpj8@peggleto-mobl5.ger.corp.intel.com>
2014-12-09 15:00     ` Trevor Woerner
2014-12-09 15:10       ` Paul Eggleton
2014-12-09 15:39         ` Trevor Woerner
2014-12-09 16:08           ` Paul Eggleton
2014-12-09 18:58             ` Trevor Woerner
2014-12-10 17:51               ` Paul Eggleton
2014-12-11 17:14                 ` Paul Eggleton
2014-12-11 18:30                   ` Trevor Woerner
2014-12-11 18:55                     ` Paul Eggleton
2014-12-11 19:16                       ` Trevor Woerner
2014-12-11 19:43                         ` Trevor Woerner
2014-12-11 21:35                           ` Paul Eggleton
2014-12-11 23:14                             ` Trevor Woerner
2014-12-12 13:01                             ` Otavio Salvador
2014-12-14  3:47                   ` Trevor Woerner

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=547D41C7.5020303@linaro.org \
    --to=trevor.woerner@linaro.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox