[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    [OE-core] [poky] RFC: design of network based PR service
From:       lianhao.lu () intel ! com (Lu, Lianhao)
Date:       2011-04-29 5:28:39
Message-ID: C10D3FB0CD45994C8A51FEC1227CE22F2316D02BB5 () shsmsx502 ! ccr ! corp ! intel ! com
[Download RAW message or body]

Mark Hatle wrote on 2011-04-29:
> (adding oe-core back to the list as it got dropped off my previous reply)
> 
> On 4/28/11 4:04 PM, Joshua Lock wrote:
> > On Thu, 2011-04-28 at 10:19 -0500, Mark Hatle wrote:
> > > On 4/28/11 4:22 AM, Martin Jansa wrote:
> > > > On Thu, Apr 28, 2011 at 03:08:03PM +0800, Lu, Lianhao wrote:
> > > > > Hi Guys,
> > > > > 
> > > > > Here is the design of network based PR service, please help to
> > > > > review and give you comment. Thanks a lot!
> > > > 
> > > > Hi,
> > > > 
> > > > looks good, just wondering if we can use the same mechanism for
> > > > LOCALCOUNT numbers in SRCPV, we can even use same table if we
> > > > prefix first column ie LOCALCOUNT_${PN} and CheckSum in 2nd column
> > > > would be actuall git hash (from SRCREV or HEAD for AUTOREV) or 2nd
> > > > table with similar structure.
> > > > 
> > > > But it wont work very well if one builder is using AUTOREV and
> > > > another one isn't, but that can be resolved by allowing only
> > > > trusted builders with same configuration (wrt AUTOREV) to send such tuples.
> > > > 
> > > > Do we have at least 2 groups of "users".
> > > > 1) trusted which increments PR when hash is not found
> > > > 2) public which can query PR for given hash (not sure what they should
> > > > do if hash is not found)
> > > 
> > > I think this points our something necessary.  There are manual
> > > indications of a change.  I.e. the current "PR" usage.  If I change
> > > the recipe, patches, etc I should expect to update the 'PR' to the
> > > next value.  However, if something ELSE changes (affecting the
> > > checksum), or an end user forgets to change the PR, the auto
> > > increment
> should be used.
> > 
> > Why would you need to update the PR manually? Detecting changes in
> > the recipe/patches/etc should all be handled by the checksumming.
> 
> Checksums and timestamps are not enough to determine a logical
> progression of the components.
> 
> We need something that informs the user where these changes fit in the
> grand scheme of things.  Are they newer or older then a recipe of the
> same name (and package version)?
> 
> So this really allows us to visualize multiple levels of upstream work:
> 
> Level 1 - Upstream "version"  (PV)
> 
> Level 2 - Upstream (oe-core) recipe versioning (PR)
> 
> ...
> 
> Level N - Local build and configuration versioning (checksum based &
> auto incrementing)
> 
> 
> In a lot of projects 1, 2 and N are enough.. but it's understandable
> to add in other intermediate levels to indicate different upstreams along the way.
> (Such as if a company has their own internal distribution..)
> 
> I've seen cases where a level 3 exists to indicate a "distribution version"..
> 
> Level N (when done manually) has usually captured major system
> configuration changes and rebuilding in order to enable solver tools to upgrade \
> properly. 
> 
> While the checksum will be able to point a unique instance of the
> recipe to a given PR... it doesn't guaranty any type of logical
> numbering.. other then a new checksum is a new (presumably larger) PR
> number.  By adding in the various levels of version information the
> checksum becomes "more" unique as it only refers to specific
> 'upstream' revisions, and make it more logical that a level 1, 2, ... N change \
> means it's a "newer" version of the package. 

If a new PV(and/or PR) value comes, does the level N value need to be reset to 0? Or \
should it continue to increase?

Best Regards,
Lianhao


[prev in list] [next in list] [prev in thread] [next in thread]