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

[Paul Eggleton]

On Thursday 27 February 2014 17:32:29 Alex J Lennon wrote:
> 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"?

Yes, see:

 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-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?

Specific build farm; it may be made externally accessible if necessary
however.

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

PR values needn't match up between different distros. The point is they should
get increased when a material change to the recipe's output happens; and this
can happen for example when:

* A class that the recipe inherits is changed 

* A dependency of the recipe that influences how the recipe is built gets
changed

* Some global configuration changed that affects how the recipe is built
e.g. DISTRO_FEATURES

* A bbappend is added or removed

In all of these cases the recipe itself does not get changed at all - prior to
the PR server we had to remember to manually bump PR in the affected recipes,
or (more often) we'd forget to handle it properly altogether. With the PR
server, PR bumps happen automatically in response to signatures changing,
which is about as accurate an indicator as we can get as far as determining
whether the output has changed, and certainly much less prone to mistakes.

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

Yes. Luckily it's not a particularly complicated piece of software; the only
extra thing you need to preserve is the sqlite database that contains the
hashes and corresponding PR values.
 
> And my packages will have different revisions from somebody elses's
> packages when they are running their own network based PR service?

Yes. If bbappends were involved all bets were off prior to the PR service
anyway since they were supposed to modify PR.
 
> 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 ?

The PR server doesn't track this - however, all of this information does go
into buildhistory if you enable that.

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

We're not talking about dropping all PR values in existing recipes, we're
talking about dropping them on upgrade (i.e. when PV changes), where
previously we'd have done that anyway or set them to "r0".

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre