On Wed, May 29, 2013 at 6:29 PM, Mark Hatle <[email protected]>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<[email protected]>> >>> 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
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
