[agl-discussions] Open issues with gerrit and git usage from Agile Albacore

Stephane Desneux stephane.desneux at iot.bzh
Mon Jan 18 11:08:48 UTC 2016


Hi Walt,

To prepare the dev meeting tomorrow where we could hopefully get a
consensus, let me summarize a proposal on how the various git projects
could be handled depending on their nature:

* AGL component project (doesn't exist yet)
   - considered as the main upstream source for a given AGL component
   - examples: Application Framework, MOST driver, Security Framework,
upcoming APIs implementations ...
   - path in gerrit: AGL/components/$NAME or AGL/components/$CATEGORY/$NAME
(or alternatively AGL/src/$CATEGORY/$NAME to identity that these are git
repos containing source code :))
     $CATEGORY could be
'network','multimedia',(graphics','audio','system','tools','qa' ...
   - life span: very long (>15 years)
   - gerrit policy:
      + a specific group is created for each project and contains the
*component maintainers*, all with full rights on the repo, including
pushing without review, branching, erasing etc. Equivalent to "owners"
on github.
      + *additional reviewers* could be added from existing groups
depending on the component type (ex: "connectivity group","multimedia
group", "telephony group" ...) These reviewers should have merge rights
(no 'push --force').
      + an *identified user* can push patches for reviews on various
branches
      + anonymous users can't push anything

* AGL integration repository
   - contains anything related to integration and build (layers,
manifests, build metadata, jenkins stuff, CI specifics ...) => no source
code except patches if quantity is reasonable.
   - examples: meta-agl, meta-renesas, AGL-repo ...
   - path in gerrit: AGL/meta-$NAME for metas, AGL/$NAME for other repos
   - life span: very long (>15 years) : we want to be able to patch and
rebuild an old AGL version at any time
   - gerrit policy:
      + a member of the "integrators group" can merge submissions
      + a specific group of maintainers could be created to add merge
permissions to additional users
      + an *identified user* can push patches for reviews on the main
branch or on release branches only
      + *anonymous users* can't push anything

* AGL demo repository
   - contains POC projects, demo components or apps, demo integration
layers on top of other layers
   - examples: meta-agl-demo, AGL/DemoApps
   - path in gerrit: AGL/demo/$NAME
   - life span: quite short (<1 year)
   - gerrit policy:
      + a group of *demo maintainers* is declared and members have full
rights on demo repositories (so push without review anywhere)
      + *identified users* can push patches without review on the master
branch ('push --force' must be forbidden)
      + *anonymous users* can't push anything

Globally, we'll get more freedom on the components repos than on
integration repos, which seems coherent. On their side, demos are
considered as short lifetime stuff and handled very differently.
Please note that Gerrit policies must be adjusted given the existing
ones as I just wanted to highlight the essential permissions.

--------------------

Also, let me propose an additional feature *for identified users only*:
a user could always push in a self-owned branch named
'sandbox/<login>/<branch_name>'. This will help a lot if in various
situations. For example, I'm working on a new patch on a component and I
want to build an image that will include my modified component to debug
it at runtime on my target board.

I would do it in 2 steps:

[ in the component repo ]
* I change the source code to include a new feature
* then I push in my sandbox:
   $ git push origin HEAD:sandbox/sdesneux/feature_1664
   ...
* push is done directly, no review - new remote branch is created
and the revision is available on the remote

[ in the meta repo ]
* I update the component recipe to point to my branch/revision
* I run an image build, deploy an image, test my feature at runtime etc.
* optional: if I want to share this build with other developers, I could
also push my updated recipe in my sandbox (but this time, on the meta repo)

Then later, when I'm satisfied with the new feature and I think it could
be integrated in the main branches, I simply push my branches for review
onto the main branches (for both gits, component and meta). Then I can
drop my sandboxes (or keep them if my feature is not finished).

--------------------

HTH
--
Stephane Desneux - CTO
sdx at iot.bzh - +33.257.620.237 - http://iot.bzh

On 15/01/2016 17:31, Walt Miner wrote:
> Hi Fulup, 
> Great thoughts. First - can you add this as a comment to the Jira issue
> so we do not lose it. I added some thoughts in-line. 
> 
> Regards,
> Walt
> 
> 
> On Fri, Jan 15, 2016 at 7:39 AM, Fulup Ar Foll <fulup.arfoll at iot.bzh
> <mailto:fulup.arfoll at iot.bzh>> wrote:
> 
>     Walt,
> 
>     About a generic solution to manage AGL source code. I think we need
>     more than a simple temporary repo to avoid code within meta layers.
>     We should extend this to support any "AGL components" that we could
>     create collaboratively.
> 
>     As today at Iot.bzh we use github for AGL components like
>     application-framework. While this perfectly works for us, it
>     nevertheless has few defaults:
>      - some companies block github
>      - it does not provide visibility to AGL collaborative work
>      - a shared AGL space could help community to understand that a
>     component is not owned by a given company, but is really a shared
>     effort.
> 
>     I think AGL would benefit from a shared space for components we are
>     developing. Obviously we may continue to use github or any other
>     public repository. Nevertheless as said before I doubt this is the
>     best option to provide visibility to AGL. Technically it should not
>     be too complex to create a dedicated space for "in-dev" AGL
>     components. I think that within those repos:
>      - every AGL member should have the right to propose a patch, report
>     a bug, etc.
>      - in order to limit load on AGL technical staff, repo maintenance
>     like accept/deny of patches, creation of sub-repositories, branches
>     management, etc. should be delegate to maintainers of corresponding
>     component.
> 
> <Walt> Two separate issues here. First there is the case we had with
> MOST driver where there is something getting back ported or added to
> project. We need somewhere in AGL for that.
> 
> For the second topic (creating an in-dev space), this is basically what
> we did for the demo apps. Anyone with access could push to the master
> without a review. We could create  something like a Prototype repo with
> directories for different proposals and add people as requested per
> project. 
>  
> 
>     Note: I do not think pushing something on those "in-dev"
>     repositories should go through Gerrit. Pushing a proposal should be
>     very light. Any member from AGL should be able to propose something
>     and a simple OK from one of the maintainer should be enough to
>     accept the merge. On the other hand review process through Jira for
>     patches on meta/layer should be kept identical as today for both
>     external and internal to AGL repositories.
> 
> <Walt> I think you meant gerrit and not Jira in the last sentence. Like
> I said above we had a simplified review process for demo apps that we
> can adapt any prototype projects. I would prefer to keep in gerrit with
> a simplified process for now.  
>  
> 
>     Fulup
> 
> 
> 
>     On 14/01/16 00:58, Walt Miner wrote:
> 
>         I want to collect the open issues with git and gerrit usage we had
>         during the final month of integration for the Agile Albacore
>         release.
>         Going through my notes we had:
> 
>         1) We need to settle on how we will manage kernel patches such
>         as the
>         MOST USB driver that was back ported from kernel 4.3 to AGL by
>         Christian. We temporarily put it in meta-agl-demo but we need a
>         place to
>         put these types of changes  I created Jira issue SPEC-92 [1] for
>         this.
>         We need a general solution that applies to code changes made to
>         packages
>         that currently only exist in meta layers.
> 
>         2) Now that we have an albacore branch we need a way to identify
>         patches
>         to be merged to that branch as we continue on Master for Brilliant
>         Blowfish. We probably need a maintainer identified for Albacore.
>         For now
>         I assume it is Jan-Simon and any patches to be merged to
>         Albacore will
>         need to be sent through him in gerrit for review.
> 
>         3) We need a mechanism for assigning defects. I have the action
>         item to
>         do this. For now I am assigning defects to the subsystem team
>         that seems
>         to be affected by the issue and letting the subsystem owner
>         delegate the
>         issue further. My concern is that this will overwhelm the subsystem
>         leads and that it may discourage people who want to pick up
>         defects to
>         work on if they think someone is already working on a defect
>         because it
>         is assigned to the subsystem lead.  Any thoughts on this?
> 
>         Please remind me of any other issues I over looked.
> 
>         Regards,
>         Walt
> 
>         [1] https://jira.automotivelinux.org/browse/SPEC-92
> 
> 
>         --
>         Walt Miner
>         Engineering Project Manager
>         The Linux Foundation
>         mobile: +1.847.502.7087 <tel:%2B1.847.502.7087>
>         skype: vstarwalt
> 
>         Visit us at:
>         automotive.linuxfoundation.org
>         <http://automotive.linuxfoundation.org>
>         <http://automotive.linuxfoundation.org>
>         www.linuxfoundation.org <http://www.linuxfoundation.org>
>         <http://www.linuxfoundation.org>
> 
> 
> 
> 
>         _______________________________________________
>         automotive-discussions mailing list
>         automotive-discussions at lists.linuxfoundation.org
>         <mailto:automotive-discussions at lists.linuxfoundation.org>
>         https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
> 
> 
> 
> 
> 
> -- 
> Walt Miner
> Engineering Project Manager
> The Linux Foundation
> mobile: +1.847.502.7087
> skype: vstarwalt
> 
> Visit us at:
> automotive.linuxfoundation.org <http://automotive.linuxfoundation.org>
> www.linuxfoundation.org <http://www.linuxfoundation.org>
> 
> 
> 
> 
> _______________________________________________
> automotive-discussions mailing list
> automotive-discussions at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
> 


More information about the automotive-discussions mailing list