<div dir="ltr">Code review is a vital part of the Openstack CI workflow, and as such the git repos managed by Openstack CI Gerrit are the authorative sources.<div><br></div><div>It looks to me you don't want to have Gerrit to be the authorative git server to avoid doing code reviews in experiments or to share code among developers, but going down that route will put you in a </div><div>situation hard to maintain, as Dolph alredy mentioned.</div><div><br></div><div>I recommend you follow the same layout as upstream (Gerrit being the authorative git server with other git servers mirroring it) and you install something like GitLab to have your developers make experiments and long lived branches that they do not want to go thru code review for sharing.</div><div><br></div><div>Regards</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-29 22:43 GMT+01:00 Stefano Maffulli <span dir="ltr"><<a href="mailto:stefano@openstack.org" target="_blank">stefano@openstack.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/29/2014 07:02 AM, Ondrej Wisniewski wrote:<br>
> If I understand correctly, we cannot use the OpenStack community Git<br>
> servers as our central Git repository since developers cannot push to<br>
> them. And we don't want to go through Gerrit and the code review<br>
> procedure just to share a bit of code with somebody else in the team.<br>
> Thus the need for a local mirror.<br>
<br>
</span>I have been having similar questions as Dolph. Are you going to Paris by<br>
chance? It'd be great to have a chat in person and understand exactly<br>
your needs.<br>
<span class=""><br>
> Additionally also a local Gerrit server was set up to allow for internal<br>
> code review within the team before submitting anything to the community<br>
</span>> server <a href="http://review.openstack.org" target="_blank">review.openstack.org</a> <<a href="http://review.openstack.org" target="_blank">http://review.openstack.org</a>> (which will be<br>
> done eventually).<br>
<br>
As Dolph mentioned, you may be able to use <a href="http://review.openstack.org" target="_blank">review.openstack.org</a> for<br>
that, keeping the patches as Work In Progress (workflow-1): your<br>
developers can all participate in the reviews and mark the change as<br>
'Ready for review' when ready. This will allow you to stay close to<br>
trunk and avoid complex setup on your side. It also allows your<br>
developers to participate more in the 'openstack way' of doing things,<br>
maybe even do some code reviews for other patches while they're on<br>
<a href="http://review.openstack.org" target="_blank">review.openstack.org</a>, it's less likely that your team will show up with<br>
a large patch after a long internal conversation.<br>
<span class=""><br>
> This is also helpful in case our Internet connection<br>
> goes down, as we will still be able to follow the complete workflow<br>
> inside the LAN.<br>
<br>
</span>Fair enough: how often does your Internet connection drop?<br>
<br>
/stef<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Ask and answer questions on <a href="https://ask.openstack.org" target="_blank">https://ask.openstack.org</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>