All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trevor Woerner <trevor.woerner@linaro.org>
To: "yocto@yoctoproject.org" <yocto@yoctoproject.org>,
	 Richard.Leitner@skidata.com
Subject: Re: SRCREV for BBLAYERS
Date: Mon, 03 Feb 2014 10:40:42 -0500	[thread overview]
Message-ID: <52EFB87A.4070303@linaro.org> (raw)
In-Reply-To: <CAALGJZb_jfkTvfN9XT5Q=+jUB8j3b=d5HkigN9+cHWWSwi3C8g@mail.gmail.com>

On 02/03/14 10:20, Christian Ege wrote:
>> But now I've got another question:
>> Is there any possibility to submit something like a feature request for this?
>> And is there a (realistic) chance that this feature gets implemented?
>> If so, where should this request go? To the bitbake-devel list?
> I am not sure If I got your point. If you intend to handle different
> versions of layers you are using you may can use the setup-scripts
> from Angstrom
> They do use an "layer manager"

Some projects which use git face this "how to manage sets of git
repositories" issue[1]. Unless a project's sources are all contained in
one monster git repository, there will always be some sort of need for
management. The understanding is that not every single commit point in
every repository will work with every other commit point in all the
other repositories making up a project. There will be "way-points" where
things work and/or are tested, and all other combinations are to be used
at one's own risk ;-)

As pointed out above, angstrom has its own system. Other projects (e.g.
gumstix[2] and fsl[3]) make use of "repo". Another option is "git
submodules".

Whether a mechanism like this would be, could be, or should be added to
OE? That's a tough one. Personally I would lean towards "yes". I think
it would make OE much easier to use (especially for newcomers) if the
combinations of layers and which commits to use from those layers were
specified as part of a, say, DISTRO's metadata. On the other hand others
would object simply because this is a not-uncommon git issue that is
already solved by existing, external tools.

Best regards,
    Trevor


[1] http://stackoverflow.com/questions/816619/managing-many-git-repositories
[2]
https://github.com/gumstix/Gumstix-YoctoProject-Repo/blob/master/README.md
[3] https://github.com/Freescale/fsl-community-bsp-platform


  reply	other threads:[~2014-02-03 15:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 12:17 SRCREV for BBLAYERS Richard Leitner - SKIDATA
2014-02-03 14:46 ` Paul Eggleton
2014-02-03 15:06   ` Richard Leitner - SKIDATA
2014-02-03 15:20     ` Christian Ege
2014-02-03 15:40       ` Trevor Woerner [this message]
2014-02-03 17:41         ` Khem Raj
2014-02-03 18:04           ` 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=52EFB87A.4070303@linaro.org \
    --to=trevor.woerner@linaro.org \
    --cc=Richard.Leitner@skidata.com \
    --cc=yocto@yoctoproject.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.