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...@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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core