[OE-core] [poky] RFC: design of network based PR service

[Lu, Lianhao]

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