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

Walt Miner wminer at linuxfoundation.org
Tue Jan 19 00:36:36 UTC 2016


Thanks Stefan and Jan-Simon,
Comments in-line.

Walt

On Mon, Jan 18, 2016 at 11:19 AM, Stephane Desneux <stephane.desneux at iot.bzh
> wrote:

> Some feedback inline.
> Thanks
>
> Stephane Desneux - CTO
> sdx at iot.bzh - +33.257.620.237 - http://iot.bzh
>
> On 18/01/2016 15:37, Jan-SImon Möller wrote:
> > 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.
> >
>
> Yes, shorter names are fine too !
>
> That was my first idea, but it may get messy when we'll have hundreds of
> projects 8^D
>
> >>    - 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.
>
<Walt> I think we have something similar in place for DemoApps. The idea is
to extend that to the component teams and their individual components.
Erasing is probably missing. See the wiki page.
https://wiki.automotivelinux.org/agl-distro/contributing

We should update to reflect that AGL-... roles can be for subsystems or
projects as well.



> >>       + *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
> >
>
<Walt> I believe this matches the current plan.


> > 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.
> >
>
> 'push without review' and 'push --force' help to speed up things in the
> development phase, as you would on github: as the owner of the repo, you
> do what you want with it, including errors :\.
>
> I fully agree that some mistakes must be avoided on the released
> branches. As the main purpose of the mode 'no review, push --force
> allowed' is for development, we could restrict this policy to the
> development branch, be it 'master','devel' or any chosen common name
> amongst repositories.
>
> >> * 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 ...
>
> Again, trying to go faster. This is a bit like the policy for a
> 'component repo' but for all repos related to demo, be it a component, a
> layer or whatever (example: more freedom/flexibility on meta-agl-demo,
> but NOT on meta-agl).
>
> Alternatively, we could treat the demo repos as the other ones: some can
> be 'demo components' and other are 'demo layers'... But given the life
> span, we don't need to be too strict.
>
> >>       + *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.
> >
> >
>
> I'm not sure it's a good idea to rename the existing repos, as they are
> already referenced.
>
> If we really want to restart from a clean tree for AGL 2.0, we can still
> make a copy and mark the old repos as obsolete for future developments
> by adding a "DO-NOT-USE.txt" file and a very clear commit message
> redirecting to the appropriate repo. Later, when releasing 2.0, it'll
> probably be possible to drop those old repos.
>
> <Walt> I really do not want to start with a clean tree or rename existing
repos.


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



-- 
Walt Miner
Engineering Project Manager
The Linux Foundation
mobile: +1.847.502.7087
skype: vstarwalt

Visit us at:
automotive.linuxfoundation.org
www.linuxfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20160118/e97cd45c/attachment.html>


More information about the automotive-discussions mailing list