<div dir="ltr"><font color="#0000ff">Thanks Stefan and Jan-Simon, </font><div><font color="#0000ff">Comments in-line. </font></div><div><font color="#0000ff"><br></font></div><div><font color="#0000ff">Walt</font></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 18, 2016 at 11:19 AM, Stephane Desneux <span dir="ltr"><<a href="mailto:stephane.desneux@iot.bzh" target="_blank">stephane.desneux@iot.bzh</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Some feedback inline.<br>
Thanks<br>
<span class=""><br>
Stephane Desneux - CTO<br>
sdx@iot.bzh - <a href="tel:%2B33.257.620.237" value="+33257620237">+33.257.620.237</a> - <a href="http://iot.bzh" rel="noreferrer" target="_blank">http://iot.bzh</a><br>
<br>
</span><span class="">On 18/01/2016 15:37, Jan-SImon Möller wrote:<br>
> Hi !<br>
><br>
> A few notes ...<br>
><br>
> Am Montag, 18. Januar 2016, 12:08:48 schrieb Stephane Desneux:<br>
>> Hi Walt,<br>
>><br>
>> To prepare the dev meeting tomorrow where we could hopefully get a<br>
>> consensus, let me summarize a proposal on how the various git projects<br>
>> could be handled depending on their nature:<br>
>><br>
>> * AGL component project (doesn't exist yet)<br>
>> - considered as the main upstream source for a given AGL component<br>
>> - examples: Application Framework, MOST driver, Security Framework,<br>
>> upcoming APIs implementations ...<br>
>> - path in gerrit: AGL/components/$NAME or AGL/components/$CATEGORY/$NAME<br>
>> (or alternatively AGL/src/$CATEGORY/$NAME to identity that these are git<br>
>> repos containing source code :))<br>
>> $CATEGORY could be<br>
>> 'network','multimedia',(graphics','audio','system','tools','qa' ...<br>
>> - life span: very long (>15 years)<br>
><br>
> What about shorter names ... we already have the AGL container in gerrit.<br>
> We could do AGL/src/<name> as the repo name and add the ACL to AGL/src/<br>
> as per the policy below.<br>
><br>
<br>
</span>Yes, shorter names are fine too !<br>
<br>
That was my first idea, but it may get messy when we'll have hundreds of<br>
projects 8^D<br>
<span class=""><br>
>> - gerrit policy:<br>
>> + a specific group is created for each project and contains the<br>
>> *component maintainers*, all with full rights on the repo, including<br>
>> pushing without review, branching, erasing etc. Equivalent to "owners"<br>
>> on github.<br></span></blockquote><div><font color="#0000ff"><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. </font></div><div><a href="https://wiki.automotivelinux.org/agl-distro/contributing">https://wiki.automotivelinux.org/agl-distro/contributing</a><font color="#0000ff"><br></font></div><div><font color="#0000ff"><br></font></div><div><font color="#0000ff">We should update to reflect that AGL-... roles can be for subsystems or projects as well. </font></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
>> + *additional reviewers* could be added from existing groups<br>
>> depending on the component type (ex: "connectivity group","multimedia<br>
>> group", "telephony group" ...) These reviewers should have merge rights<br>
>> (no 'push --force').<br>
>> + an *identified user* can push patches for reviews on various<br>
>> branches<br>
>> + anonymous users can't push anything<br>
><br></span></blockquote><div><font color="#0000ff"><Walt> I believe this matches the current plan. </font></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> Most is in place and we just need to finetune the ACL.<br>
> Question: why would you need "push without review" and erase. Unless there is<br>
> some cleanup needed, no "fancy" actions should happen on published/release<br>
> repos (its AGL/src/<name>, so its ). Should be discussed from that<br>
> perspective.<br>
><br>
<br>
</span>'push without review' and 'push --force' help to speed up things in the<br>
development phase, as you would on github: as the owner of the repo, you<br>
do what you want with it, including errors :\.<br>
<br>
I fully agree that some mistakes must be avoided on the released<br>
branches. As the main purpose of the mode 'no review, push --force<br>
allowed' is for development, we could restrict this policy to the<br>
development branch, be it 'master','devel' or any chosen common name<br>
amongst repositories.<br>
<div><div class="h5"><br>
>> * AGL integration repository<br>
>> - contains anything related to integration and build (layers,<br>
>> manifests, build metadata, jenkins stuff, CI specifics ...) => no source<br>
>> code except patches if quantity is reasonable.<br>
>> - examples: meta-agl, meta-renesas, AGL-repo ...<br>
>> - path in gerrit: AGL/meta-$NAME for metas, AGL/$NAME for other repos<br>
>> - life span: very long (>15 years) : we want to be able to patch and<br>
>> rebuild an old AGL version at any time<br>
>> - gerrit policy:<br>
>> + a member of the "integrators group" can merge submissions<br>
>> + a specific group of maintainers could be created to add merge<br>
>> permissions to additional users<br>
>> + an *identified user* can push patches for reviews on the main<br>
>> branch or on release branches only<br>
>> + *anonymous users* can't push anything<br>
><br>
> Ok, this is what we have right now in AGL/ . Integrator group is atm "AGL-<br>
> mergers" .<br>
><br>
>> * AGL demo repository<br>
>> - contains POC projects, demo components or apps, demo integration<br>
>> layers on top of other layers<br>
>> - examples: meta-agl-demo, AGL/DemoApps<br>
>> - path in gerrit: AGL/demo/$NAME<br>
>> - life span: quite short (<1 year)<br>
>> - gerrit policy:<br>
>> + a group of *demo maintainers* is declared and members have full<br>
>> rights on demo repositories (so push without review anywhere)<br>
> - why push without review ...<br>
<br>
</div></div>Again, trying to go faster. This is a bit like the policy for a<br>
'component repo' but for all repos related to demo, be it a component, a<br>
layer or whatever (example: more freedom/flexibility on meta-agl-demo,<br>
but NOT on meta-agl).<br>
<br>
Alternatively, we could treat the demo repos as the other ones: some can<br>
be 'demo components' and other are 'demo layers'... But given the life<br>
span, we don't need to be too strict.<br>
<span class=""><br>
>> + *identified users* can push patches without review on the master<br>
>> branch ('push --force' must be forbidden)<br>
>> + *anonymous users* can't push anything<br>
><br>
> Consolidation of the AGL/DemoApps into AGL/demo +1 .<br>
> But watch out for URLs in existing recipes (AA release!)<br>
><br>
> Wrt meta-agl-demo ... we use that layer atm more heavily (do you build just<br>
> with meta-agl ??). The AA release manifests reference it from AGL/ .<br>
> So I don't think we can move it w/o republishing AA.<br>
><br>
><br>
<br>
</span>I'm not sure it's a good idea to rename the existing repos, as they are<br>
already referenced.<br>
<br>
If we really want to restart from a clean tree for AGL 2.0, we can still<br>
make a copy and mark the old repos as obsolete for future developments<br>
by adding a "DO-NOT-USE.txt" file and a very clear commit message<br>
redirecting to the appropriate repo. Later, when releasing 2.0, it'll<br>
probably be possible to drop those old repos.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><font color="#0000ff"><Walt> I really do not want to start with a clean tree or rename existing repos. </font></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
>> Globally, we'll get more freedom on the components repos than on<br>
>> integration repos, which seems coherent. On their side, demos are<br>
>> considered as short lifetime stuff and handled very differently.<br>
>> Please note that Gerrit policies must be adjusted given the existing<br>
>> ones as I just wanted to highlight the essential permissions.<br>
>><br>
><br>
><br>
><br>
> Best,<br>
> Jan-Simon<br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="color:rgb(136,136,136)">Walt Miner</span><div style="color:rgb(136,136,136)">Engineering Project Manager</div><div style="color:rgb(136,136,136)">The Linux Foundation<br></div><div style="color:rgb(136,136,136)">mobile: <a value="+14086234789" style="color:rgb(17,85,204)">+1.847.502.7087</a></div><div style="color:rgb(136,136,136)">skype: vstarwalt</div><div style="color:rgb(136,136,136)"><br></div><div style="color:rgb(136,136,136)">Visit us at:</div><div style="color:rgb(136,136,136)"><a href="http://automotive.linuxfoundation.org" target="_blank">automotive.linuxfoundation.org</a><br></div><div style="color:rgb(136,136,136)"><a href="http://www.linuxfoundation.org" target="_blank">www.linuxfoundation.org</a></div><div style="color:rgb(136,136,136)"><br></div><div style="color:rgb(136,136,136)"><br></div></div></div>
</div></div>