Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Trevor Woerner <twoerner@gmail.com>
Cc: openembedded-architecture
	<openembedded-architecture@lists.openembedded.org>,
	Alexander Kanavin <alexander.kanavin@intel.com>,
	openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [Openembedded-architecture] LAYERSERIES
Date: Fri, 06 Apr 2018 16:29:47 +0100	[thread overview]
Message-ID: <1523028587.2942.13.camel@linuxfoundation.org> (raw)
In-Reply-To: <20180406141647.GA19068@linux-uys3>

On Fri, 2018-04-06 at 10:16 -0400, Trevor Woerner wrote:
> A) Some layers only switch to an official branch name when the find a
> reason to. E.g. branch "sumo" is created on openembedded-core but
> meta-A keeps working on master unless an incompatible change is
> created in openembedded-core that forces meta-A to create a "sumo"
> branch.
> 
> B) Other layers create official branches the moment they exist. E.g.
> branch "sumo" is created on openembedded-core and meta-B instantly
> creates a "sumo" branch to mark this point in time, and continues
> working on master. If meta-B's "sumo" branch fails to build against
> openembedded-core's "sumo" branch because an incompatible change is
> made to openembedded-core's sumo branch, meta-B fixes the issue on
> the sumo branch.
> 
> 
> I can see how the change you've implemented will be very useful for
> the A)
> cases. Will it be needed for the B) cases? In other words, does the
> code
> you're adding implicitly assume:
> 
> 	LAYERSERIES_COMPAT_<...> = "layer"
> 
> for any given "layer"?

No, there is no implicit assumption.

In both A) and B) cases the maintainer adds the new "codename" to the
list of compatible layer series in LAYERSERIES_COMPAT_<layer> for their
layer. They can list multiple layers in there, e.g. "rocko sumo".

The one annoying thing about all this is the layer maintainers do have
to update layer.conf each time a new release codename comes out. I
think that is a reasonable compromise to be able to give users a much
better idea of which layers are compatible or incomaptible with their
setup though. It means someone has looked at it and believes it will
work with a given release series.

Just to be clear, "layer" would never be a valid value there, it will
always be the release/branch codenames.

Cheers,

Richard




  reply	other threads:[~2018-04-06 15:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06 10:37 LAYERSERIES Richard Purdie
2018-04-06 14:16 ` [Openembedded-architecture] LAYERSERIES Trevor Woerner
2018-04-06 15:29   ` Richard Purdie [this message]
2018-04-06 18:16     ` Scott Rifenbark
2018-04-06 22:25       ` Richard Purdie
2018-04-06 22:44         ` Scott Rifenbark
2018-04-07 14:13           ` Richard Purdie
2018-04-06 18:25     ` Martin Jansa
2018-04-06 22:00       ` Richard Purdie
2018-04-06 20:46     ` akuster808
2018-04-06 21:56       ` Richard Purdie
2018-04-14 21:48         ` Trevor Woerner
2018-04-15 21:12           ` Richard Purdie
2018-04-06 18:58 ` Denys Dmytriyenko
2018-04-06 21:52   ` Richard Purdie

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=1523028587.2942.13.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=alexander.kanavin@intel.com \
    --cc=openembedded-architecture@lists.openembedded.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=twoerner@gmail.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