[oe] [OE-core] [RFC PATCH] base.bbclass: Deprecate the PRINC logic
Richard Purdie
richard.purdie at linuxfoundation.org
Wed May 29 21:24:28 UTC 2013
On Wed, 2013-05-29 at 14:00 -0300, Otavio Salvador wrote:
> On Wed, May 29, 2013 at 11:47 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2013-05-29 at 16:37 +0200, Martin Jansa wrote:
> > On Wed, May 29, 2013 at 08:51:36AM -0500, Mark Hatle wrote:
> > > Background:
> > >
> > > At the recent TSC meeting we were discussing ways of
> removing the PRINC
> > > in favor of the PR server, which should now be standard.
> The first step
> > > in this process is coming up with a simple patch that
> declared PRINC as
> > > deprecated. If this type of patch is successful, the
> block of code could
> > > be replaced with a bb.error eventually.
> > >
> > > It is not expected that this patch will go in by itself,
> but instead
> > > should be coordinated with changes to the recipes in
> common layers such
> > > as openembedded-core, meta-openembedded/meta-* and other
> community layers.
> >
> > This doesn't say what's the process of getting all PR
> increments
> > applied.
> >
> > Should we send list of recipes and required PR increments
> per layer (and
> > someone will sum these increments and create actual PR bump
> from it). Or
> > will we take turns and send actual PR bump patches per layer
> and someone
> > will define order of layers to go in (so that we prevent
> many conflicts
> > while merging)?
>
>
> This is something we need to figure out. The realistic process
> is
> probably do this layer by layer. If we can batch some up
> together that
> would obviously be better...
> If this is the case, to ensure we have the PR in sync we should have
> it PRINC as a bb.error; this will cause some pain but will avoid
> PRServer picking the layer PRINC and losing it in next build. Or does
> PRServer handle this gracefully?
I proposed this but other TSC members didn't like the approach and would
prefer a grace/warning period, maybe spanning until after the next
release.
I can see the arguments both ways...
Cheers,
Richard
More information about the Openembedded-devel
mailing list