Re: RFC: design of network based PR service

[Joshua Lock <josh@linux.intel.com>]

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.

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Center