<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 29, 2013 at 6:29 PM, Mark Hatle <span dir="ltr">&lt;<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 5/29/13 4:24 PM, Richard Purdie wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Wed, 2013-05-29 at 14:00 -0300, Otavio Salvador wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Wed, May 29, 2013 at 11:47 AM, Richard Purdie<br>
&lt;<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@<u></u>linuxfoundation.org</a>&gt; wrote:<br>
         On Wed, 2013-05-29 at 16:37 +0200, Martin Jansa wrote:<br>
         &gt; On Wed, May 29, 2013 at 08:51:36AM -0500, Mark Hatle wrote:<br>
         &gt; &gt; Background:<br>
         &gt; &gt;<br>
         &gt; &gt; At the recent TSC meeting we were discussing ways of<br>
         removing the PRINC<br>
         &gt; &gt; in favor of the PR server, which should now be standard.<br>
          The first step<br>
         &gt; &gt; in this process is coming up with a simple patch that<br>
         declared PRINC as<br>
         &gt; &gt; deprecated.  If this type of patch is successful, the<br>
         block of code could<br>
         &gt; &gt; be replaced with a bb.error eventually.<br>
         &gt; &gt;<br>
         &gt; &gt; It is not expected that this patch will go in by itself,<br>
         but instead<br>
         &gt; &gt; should be coordinated with changes to the recipes in<br>
         common layers such<br>
         &gt; &gt; as openembedded-core, meta-openembedded/meta-* and other<br>
         community layers.<br>
         &gt;<br>
         &gt; This doesn&#39;t say what&#39;s the process of getting all PR<br>
         increments<br>
         &gt; applied.<br>
         &gt;<br>
         &gt; Should we send list of recipes and required PR increments<br>
         per layer (and<br>
         &gt; someone will sum these increments and create actual PR bump<br>
         from it). Or<br>
         &gt; will we take turns and send actual PR bump patches per layer<br>
         and someone<br>
         &gt; will define order of layers to go in (so that we prevent<br>
         many conflicts<br>
         &gt; while merging)?<br>
<br>
<br>
         This is something we need to figure out. The realistic process<br>
         is<br>
         probably do this layer by layer. If we can batch some up<br>
         together that<br>
         would obviously be better...<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If this is the case, to ensure we have the PR in sync we should have<br>
it PRINC as a bb.error; this will cause some pain but will avoid<br>
PRServer picking the layer PRINC and losing it in next build. Or does<br>
PRServer handle this gracefully?<br>
</blockquote>
<br>
I proposed this but other TSC members didn&#39;t like the approach and would<br>
prefer a grace/warning period, maybe spanning until after the next<br>
release.<br>
<br>
I can see the arguments both ways...<br>
</blockquote>
<br></div></div>
I prefer the warning for one release approach.  What I&#39;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.<br>

<br>
With the warning, they won&#39;t be immediately blocked -- but will be sufficiently annoyed (and warned) that they need to fix something or it will break.</blockquote><div><br></div><div style>The problem is the following:</div>
<div style><br></div><div style>OE-Core adds warning;</div><div style>Layer1 submit the PR bump request and drop the internal PRINC</div><div style>Layer1 gets PRINC removal commited</div><div style>User1 updates Layer1 (and OE-Core didn&#39;t yet apply the PR bump)</div>
<div style><br></div><div style>PR goes backwards.</div><div style><br></div><div style>Now the inverse:</div><div style><br></div><div>OE-Core adds warning;</div><div>Layer1 submit the PR bump request and drop the internal PRINC</div>
<div style>OE-Core commits PR bump</div><div>User1 updates Layer1 (and OE-Core didn&#39;t yet apply the PR bump)</div><div style><br></div><div style>PR goes forward as PRINC didn&#39;t yet been removed so when Layer1 is updated again, it will go backwards</div>
</div><div><br></div>-- <br>Otavio Salvador                             O.S. Systems<br><a href="http://www.ossystems.com.br" target="_blank">http://www.ossystems.com.br</a>        <a href="http://projetos.ossystems.com.br" target="_blank">http://projetos.ossystems.com.br</a><br>
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750<br>
</div></div>