All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Samuelsson <ulf@emagii.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: RFC: Support for R/W git in bitbake
Date: Wed, 18 Apr 2012 10:12:29 +0200	[thread overview]
Message-ID: <4F8E776D.5020005@emagii.com> (raw)
In-Reply-To: <7419249.iRUESFeaJl@helios>

On 2012-04-18 09:28, Paul Eggleton wrote:
> On Wednesday 18 April 2012 03:34:27 Ulf Samuelsson wrote:
>> 1. If I am busy working on an application, then it simplifies the
>> development process.
>>       I can modify the code in the tree and push.
>>       This is mainly for kernel development.
>>
>> 2. If I work on a prerelease of some S/W drivers/Applications under NDA,
>>       then I cannot make that code publicly available
>>       but I still want to put  that on my Internet accessible git server.
>>       Typicailly this is before the release of a new chip and info about
>> the chip should not be
>>       made public before the chip is released.
>>
>> 3.  I want to be able to ship something similar to the Angstrom setup
>> scripts
>>        to someone else, and have them build an image, but it should not
>> be available
>>        to anyone not accepted (without public key at the git server).
>>
>> There are other uses for such a functionality, but those are my
>> immediate needs.
>>
>> As you see, this is mostly for development.
>> Once the code is released, then the recipe would be changed to the
>> normal git access.
>>
>> Didn't know anything about the externalsrc bbclass, but after checking,
>> I would say no.
>> It won't do the two things above. I do see the use of it though.
> externalsrc should handle everything except automatically fetching the source;
> for that you need to have your own local git clone (which of course can be
> r/w). I guess it depends on whether you expect to be sending such recipes to
> non-developers; for developers it ought not to be too much of a hassle to have
> their own local git clone.
>
> The only problem with having an r/w checkout you are doing development in
> under WORKDIR is that if you bitbake -c clean the recipe you will lose
> whatever you are working on - externalsrc avoids this.
>
> Cheers,
> Paul
>
I am working with a company, which OEMs their solution to other companies.
They get tons of questions from those customers, and based on that
I would like to avoid anything which requires manual intervention
of the developer.

As for cleaning out changes, it might happen, but I am prepared to take 
the risk.
Today I am initializing a git after the extract anyway.

I am sure I will use externalsrc for something.

-- 

Best Regards
Ulf Samuelsson
ulf@emagii.com
+46 722 427437




      reply	other threads:[~2012-04-18  8:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-17 22:35 RFC: Support for R/W git in bitbake Ulf Samuelsson
2012-04-17 23:07 ` Paul Eggleton
2012-04-18  1:34   ` Ulf Samuelsson
2012-04-18  6:24     ` Antonio Ospite
2012-04-19  7:25       ` Anders Darander
2012-04-18  7:28     ` Paul Eggleton
2012-04-18  8:12       ` Ulf Samuelsson [this message]

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=4F8E776D.5020005@emagii.com \
    --to=ulf@emagii.com \
    --cc=openembedded-devel@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 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.