[OE-core] [RFC PATCH] base.bbclass: Deprecate the PRINC logic

[Otavio Salvador]

On Wed, May 29, 2013 at 6:29 PM, Mark Hatle <mark.hatle at windriver.com>wrote:

> 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<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...
>>
>
> 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.


The problem is the following:

OE-Core adds warning;
Layer1 submit the PR bump request and drop the internal PRINC
Layer1 gets PRINC removal commited
User1 updates Layer1 (and OE-Core didn't yet apply the PR bump)

PR goes backwards.

Now the inverse:

OE-Core adds warning;
Layer1 submit the PR bump request and drop the internal PRINC
OE-Core commits PR bump
User1 updates Layer1 (and OE-Core didn't yet apply the PR bump)

PR goes forward as PRINC didn't yet been removed so when Layer1 is updated
again, it will go backwards

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130529/d20a0673/attachment-0002.html>