[yocto] [meta-mono] [PATCH 1/1] gtk-sharp: Updated to GTK# 2.12.21

Alex J Lennon ajlennon at dynamicdevices.co.uk
Thu Feb 27 09:32:29 PST 2014


On 27/02/2014 17:09, Paul Eggleton wrote:
> On Thursday 27 February 2014 08:30:10 Khem Raj wrote:
>> On Feb 27, 2014, at 7:59 AM, Alex J Lennon <ajlennon at dynamicdevices.co.uk>
>> wrote:
>>> On 27/02/2014 15:50, Khem Raj wrote:
>>>       > On Feb 27, 2014, at 6:16 AM, Alex J Lennon
>>>       
>>>       <ajlennon at dynamicdevices.co.uk> wrote:
>>>       >> +PR = "r1"
>>>       >> 
>>>       >> +
>>>       > 
>>>       > get rid of that
>>>
>>> Why is that Khem?
>> we have automatic PR server now a days, its enabled by default.
> FWIW, I don't think it's enabled by default, at least not in OE-Core/Poky. The 
> point still stands though, it's the way PR should be managed rather than 
> manual bumping.
>

<googling/> Are we talking about the "network based PR service"? 

Is this a single globally available nework service or a service that's
intended to be running local to a specific build farm?

My reading of the wiki page seems to imply it's intended to be local to
a build farm, or system, rather than globally unique?

So if I'm releasing packages to production this now becomes a critical
part of my infrastructure as I'll lose all my package revisions if
something goes wrong with it?

And my packages will have different revisions from somebody elses's
packages when they are running their own network based PR service?

I suppose the other question is, if I release a package of revision X,
then another which is up-rev'd' to Y as I made a change to the recipe
and so the NBPRS up-revs, then somebody comes back to me and tells me
they are having a problem with Xm then how do I link that rev X to the
specific commit that went to build it so I can audit ?

I haven't enabled this here, so does that mean all my package revisions
will be r0 as I remove the PR variables from recipes ?

Thanks,

Alex
 



More information about the yocto mailing list