[OE-core] Switch to PR server model for PR bumps - 1 week

Martin Jansa martin.jansa at gmail.com
Wed Dec 5 14:45:39 UTC 2012


On Wed, Dec 05, 2012 at 02:13:59PM +0000, Richard Purdie wrote:
> I've made it clear we want and need to switch to the PR service for
> handling PR bumps. I'd now like to put a deadline in place for doing
> this, namely that I'm going to stop requiring PR bumps in patches as of
> 1 week's time. The TSC did discuss this and our conclusion was that we
> need to switch early in this release cycle to give time for any issues
> to get resolved. Now is a good time to do this as I think we're ready.
> 
> There were a number of open bugs related to the PR service[1]. We've
> looked through them and they are now resolved with the exception of one
> related to the incremental git PV issue for which we have a plan in
> place and patches ready.
> 
> We've taken on board feedback about documentation and the following wiki
> page has been setup which details the current situation:
> 
> https://wiki.yoctoproject.org/wiki/PR_Service
> 
> I appreciate this is going to be a disruptive change for some but I
> believe it is in the best interests of the project longer term and that
> we will have a better system as an end result of this. If people do run
> into problems, please send email or file bugs. I'm trying to ensure
> there are some people with time available to look into these issues as a
> priority so we can make a smooth transition.

After reading this wiki page I have few questions (I admit I haven't
tried it yet).

1) How do you limit access to shared prserv instance?
   Can you define some group as RO, some RW?
   For RO access it would be great to export state from remote PRSERV 
   on first connection and then continue to increment locally (with
   PRSERV running on localhost)
2) If you have slightly different builder (e.g. someone with extra BSP
   or different host distro), then he will have different checksums, so
   different AUTOPR values and you cannot share binary feed with such
   builder, right? I know this wasn't possible (or at least safe) to use
   before too. But it should be more clear from documentation.
3) Is it possible to use OEBasic together with PRSERV or should bitbake
   show fatal error when PRSERV is used toghether with OEBasic?
4) Is there plan to import current PR values from recipes, so that
   bitbake can parse all enabled layers, gather checksum-PR values and
   export it for bitbake-prserv-tool to import it as inital state?
5) Is there plan to remove PR from all recipes or are they ignored with
   PRSERV in use and can stay in for some time? If there is functionality 
   for 4) then we should tag all layers just before PR/PRINC are removed, 
   so someone can create own initial export from last known PR state.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121205/ec837d8b/attachment-0002.sig>


More information about the Openembedded-core mailing list