On Thu, Apr 28, 2011 at 10:28 PM, Lu, Lianhao <lianhao...@intel.com> wrote:
> 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?
>
I am in favor of reseting it to 0
> Best Regards,
> Lianhao
>
>
> _______________________________________________
> poky mailing list
> p...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
