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

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


One other thought. The wiki page needs to be update to differentiate
between the integration repos and the other repos.


https://wiki.automotivelinux.org/agl-distro/contributing

On Mon, Jan 18, 2016 at 6:36 PM, Walt Miner <wminer at linuxfoundation.org>
wrote:

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


-- 
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/98751278/attachment-0001.html>


More information about the automotive-discussions mailing list