Re: [meta-arm][PATCH] meta-arm: Remove meta-python dependency

["Jon Mason" <jdmason@kudzu.us>]

On Mon, Jun 01, 2020 at 04:55:24PM -0500, Joshua Watt wrote:
> 
> On 6/1/20 4:31 PM, Jon Mason wrote:
> > On Sat, May 30, 2020 at 01:39:49PM -0500, Joshua Watt wrote:
> > > On Fri, May 29, 2020, 10:37 AM Bertrand Marquis <Bertrand.Marquis@arm.com>
> > > wrote:
> > > 
> > > > 
> > > > > On 29 May 2020, at 16:32, Joshua Watt <JPEWhacker@gmail.com> wrote:
> > > > > 
> > > > > 
> > > > > On 5/29/20 10:21 AM, Bertrand Marquis wrote:
> > > > > > > On 29 May 2020, at 16:14, Joshua Watt via lists.yoctoproject.org
> > > > <JPEWhacker=gmail.com@lists.yoctoproject.org> wrote:
> > > > > > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> > > > > > > ---
> > > > > > > meta-arm/conf/layer.conf | 3 +--
> > > > > > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/meta-arm/conf/layer.conf b/meta-arm/conf/layer.conf
> > > > > > > index d96e9f1..1c241d4 100644
> > > > > > > --- a/meta-arm/conf/layer.conf
> > > > > > > +++ b/meta-arm/conf/layer.conf
> > > > > > > @@ -11,6 +11,5 @@ BBFILE_PRIORITY_meta-arm = "6"
> > > > > > > 
> > > > > > > LAYERDEPENDS_meta-arm = " \
> > > > > > >      core \
> > > > > > > -    meta-python \
> > > > > > > "
> > > > > > > -LAYERSERIES_COMPAT_meta-arm = "warrior zeus dunfell"
> > > > > > > +LAYERSERIES_COMPAT_meta-arm = "gatesgarth"
> > > > > > Could you explain why you want to remove dunfell compatibility ?
> > > > > dunfell doesn't have the required python recipes in oe-core, so it isn't
> > > > compatible with it anymore.
> > > > 
> > > > Nothing has been tested or is compatible with gatesgarth right now so this
> > > > change will really have a breaking impact.
> > > > 
> > > Right, you certainly wouldn't want to backport it to the dunfell branch;
> > > this is just for master where the next release would be gatesgarth anyway.
> > > 
> > > Also, with the qemu support I added, I think we have reasonable testing
> > > coverage on meta-arm, and in particular enough to have high confidence in
> > > this change.
> > > 
> > > Finally, FWIW, upstream oe-core and meta-python have already made these
> > > changes on their master branches, so it seems like we wouldn't want a
> > > useless dependency on meta-python in meta-arm, *especially* if the idea is
> > > to get other bsp layers to depend on meta-arm to consolidate things like
> > > TF-A and optee.
> > We currently have a requirement for dunfell compatability on the
> > meta-arm master branch for Arm's BSP software releases (which will
> > be YP based going forward).  To make a stable release for our
> > customers, we need to draw a line between stablity of our dependent
> > layers and the latest code in the meta-arm layer.  This especially
> > relates to the BSPs Arm will be adding to meta-arm-bsp in this
> > release.
> > 
> > We do not have to keep dunfell support in master after the release of
> > gatesgarth, but we will need it until then.  So, please stash this
> > patch until October (which will be here sooner than you think).
> 
> Hmm, that's really unfortunate. That makes me think this layer is not
> actually intended to be a centralized location for ARM related things, and
> I'm probably not going to try and consolidate things from other layers here
> anymore. Not having a master branch that can be used with the master branch
> of OE-core really eliminates the possibility for me to use a BSP layer like
> e.g. meta-rockchip for upstream development and testing if that BSP layer
> depends on meta-arm and meta-arm is perpetually stuck on the last release.

I'm in no way saying that meta-arm master should not work with
upstream master.  I'm saying that we want to keep compatability with
the previous release so that we can cut stable releases for customers.

We have a requirement to release BSP SW based on YP.  Just like I
would expect other vendors/people who want to use meta-arm.  So, there
are a few ways we can approach this issue.

1.  Merge patches onto dunfell branch
2.  A development branch based on dunfell
3.  Use master meta-arm-bsp and dunfell branches for meta-arm and
meta-arm-toolchain
4.  Keep master compatible with dunfell

One is simple, we actually do our development on the dunfell branch.
However, this breaks it from being a stable branch.  So, this is a
non-starter

Two is still simple, we do all of our internal development on a second
dunfell branch ("dunfell-dev") and make any releases we have off of
that.  The problem with this is the integration and testing.  If there
are multiple branches to test, can we expect developers to test every
combination?  Also, there might be a need for different versions of
the patches depending on how much master and dunfell-dev diverge.

Three is more complex.  Since only meta-arm-bsp needs releases, we can
simply let that one float and fix the others on the stable branches.
The problem with this is that we are currently needing to add recipes
for things into meta-arm that others might need (like SCP, EDK2, etc).
So, this will work once we have more stability in meta-arm, but right
now we are adding too much stuff to make it viable for the next
release.

Four is simple, we keep compatability with dunfell and make the
releases off of that.  The potential hazard with this is if something
in YP master requires that compatability to be broken.

I presonally would like #4, because it is simple.  However, if this
will prevent others from using meta-arm, then let's have a discussion
on it.  Perhaps I am not understanding something fundamental.

Thanks,
Jon

> 
> 
> > 
> > Thanks,
> > Jon
> > 
> > 
> > > 
> > > > Bertrand
> > > > 
> > > > > 
> > > > > > Bertrand
> > > > > > 
> > > > > > > --
> > > > > > > 2.17.1
> > > > > > > 
> > > > > > > 
> > > > 
> > >