<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Filipe-<div><br></div><div>Welcome to the Networking team. You've correctly followed the work flow for code submissions that were not discussed at the design summit. </div><div><br></div><div><br></div><div><div><div><blockquote type="cite"><div dir="ltr"><div style="">I submitted a Quantum blueprint (<a href="https://blueprints.launchpad.net/quantum/+spec/provider-router">here</a>) and already started working on it.</div>
<div style=""><br></div><div style="">To ease the review process I divided the blueprint in work items and I'm submitting a change to each of the work items. Is this the right way, or should I just keep ammending the same change?</div></div></blockquote><div><br></div><div>In general, your commits should be atomic changes that follow the linked blueprint or bug. As the code is reviewed, you should amend the commit with any changes made based on review. Using an amended commit makes it easier to track the change history of a proposal. I'd recommend </div><br><blockquote type="cite"><div dir="ltr">
<div style=""><br></div><div style="">Using different changes I will have to add dependencies which I'm trying to do according to the wiki (<a href="https://wiki.openstack.org/wiki/GerritWorkflow#Add_dependency">here</a>). But when I try to submit the second change git review asks me if I really want to submitt both commits. Is this intended or am I doing something wrong?</div></div></blockquote><div><br></div><div>This is how our review system works. The dependent branches contain revisions that are not merged into master, so dependent revisions are required to keep track of the which version you based your dependency on (these can change see above).</div><div><br></div><blockquote type="cite"><div dir="ltr">
<div style=""><br></div><div style="">Another question is how do I request my code to be integrated in OpenStack. Should I request the core devs to review and accept (or not) my blueprint, or they will look at it at some point and make decisions?</div></div></blockquote><div><br></div><div>The Havana-1 interim milestone is due next week, so I've temporarily assigned a -2 to this review. I want the core team to focus on currently approved H1 blueprints, so the negative review is solely based on timing. When we begin to focus on H2 work late next week, I'll remove the -2 and the team can discuss the blueprint and the review the code.</div><div><br></div><div>If you have any questions, feel free to message me off list.</div><div><br></div></div></div></div><div>mark</div></body></html>