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

[Jan-SImon Möller]

Hi !

A few notes ...

Am Montag, 18. Januar 2016, 12:08:48 schrieb Stephane Desneux:
> 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)

What about shorter names ... we already have the AGL container in gerrit.
We could do  AGL/src/<name>  as the repo name and add the ACL to AGL/src/
as per the policy below.

>    - 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

Most is in place and we just need to finetune the ACL. 
Question: why would you need "push without review" and erase. Unless there is 
some cleanup needed, no "fancy" actions should happen on published/release 
repos (its AGL/src/<name>, so its ). Should be discussed from that 
perspective.

> * 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

Ok, this is what we have right now in AGL/ . Integrator group is atm "AGL-
mergers" . 

> * 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)
- why push without review ...
>       + *identified users* can push patches without review on the master
> branch ('push --force' must be forbidden)
>       + *anonymous users* can't push anything

Consolidation of the AGL/DemoApps into AGL/demo +1 .
But watch out for URLs in existing recipes (AA release!)

Wrt meta-agl-demo ... we use that layer atm more heavily (do you build just 
with meta-agl ??). The AA release manifests reference it from AGL/ .
So I don't think we can move it w/o republishing AA. 


> 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.
> 



Best,
Jan-Simon