Re: [RFC PATCH] base.bbclass: Deprecate the PRINC logic

[Mark Hatle <mark.hatle@windriver.com>]

On 5/29/13 4:24 PM, Richard Purdie wrote:
> 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@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...

I prefer the warning for one release approach.  What I'm afraid will happen is 
oe-core is released in the Fall, and a group of users migrates to it from the 
last release and suddenly all of their layers break.  These are the people who 
do not keep up with day to day development.

With the warning, they won't be immediately blocked -- but will be sufficiently 
annoyed (and warned) that they need to fix something or it will break.

--Mark

> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>