Re: [PATCH 0/5] network based PR service

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2011-05-19 at 13:51 +0200, Koen Kooi wrote:
> Op 19 mei 2011, om 13:38 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2011-05-19 at 12:54 +0200, Koen Kooi wrote:
> >> Op 19 mei 2011, om 12:29 heeft Lianhao Lu het volgende geschreven:
> >> 
> >>> From: Lianhao Lu <lianhao.lu@intel.com>
> >>> 
> >>> This series of 5 patches implemented the network based PR service and enabled 
> >>> the poky to use it during the task do_package and do_package_write_xxx. By 
> >>> using the network based PR service and the basichash for BB_SIGNATURE_HANDLER, 
> >>> the poky user may not need to bump the PR manually everytime he/she changes 
> >>> the recipe. The package will get automatically rebuilt and new revision number 
> >>> reflecting the change will be included in the package feed.
> >> 
> >> Does it have a public/private mode? In the angstrom case, we only want
> >> developers to 'submit' PR bumps and users only retrieve them.
> > 
> > It doesn't look like it but it wouldn't be hard to only submit PR
> > changes if some kind of token was present.
> > 
> > The big question would be, if a user tried building something for which
> > PR no record was on the server and didn't have submit privileges, what
> > should the server return and how should the build behave? Hard error?
> > 
> > If its not a hard error, you are likely to run into local
> > reproducibility issues and also conflicts with the server?
> 
> I would go for a warning on the client side and an error in the log in
> the server side. If the server people care enough they'll check the
> log for errors and add the missing info.

How is the client meant to continue on when the value it gets from the
server is effectively a "don't know" reply? Default to 0?

Thinking about it, its probably fine as long as it defaulted back to
"lr" or something to show there was likely a local change that caused it
to deviate from what was on the server. It just needs to be clear it
doesn't correspond to the upstream server.

> I think we need to give this a try and see what improvements we need.

Agreed.

Cheers,

Richard