<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 September 2016 at 10:20, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
As we work to finish the last remaining tasks for Newton, it's a good time<br>
to look back over the cycle, and recognize the excellent work done by<br>
several new contributors.<br>
<br>
We've seen a different contributor pattern develop recently, where many<br>
folks are subsystem experts and mostly focus on a particular project or<br>
area of functionality. I think this is a good thing, and it's hopefully<br>
going to allow our community to scale more effectively over time (and it<br>
fits pretty nicely with our new composable/modular architecture).<br>
<br>
We do still need folks who can review with the entire TripleO architecture<br>
in mind, but I'm very confident folks will start out as subsystem experts<br>
and over time broaden their area of experience to encompass more of<br>
the TripleO projects (we're already starting to see this IMO).<br>
<br>
We've had some discussion in the past[1] about strictly defining subteams,<br>
vs just adding folks to tripleo-core and expecting good judgement to be<br>
used (e.g only approve/+2 stuff you're familiar with - and note that it's<br>
totally fine for a core reviewer to continue to +1 things if the patch<br>
looks OK but is outside their area of experience).<br>
<br>
So, I'm in favor of continuing that pattern and just welcoming some of our<br>
subsystem expert friends to tripleo-core, let me know if folks feel<br>
strongly otherwise :)<br>
<br>
The nominations, are based partly on the stats[2] and partly on my own<br>
experience looking at reviews, patches and IRC discussion with these folks<br>
- I've included details of the subsystems I expect these folks to focus<br>
their +2A power on (at least initially):<br>
<br>
1. Brent Eagles<br>
<br>
Brent has been doing some excellent work mostly related to Neutron this<br>
cycle - his reviews have been increasingly detailed, and show a solid<br>
understanding of our composable services architecture. He's also provided<br>
a lot of valuable feedback on specs such as dpdk and sr-iov. I propose<br>
Brent continues this exellent Neutron focussed work, while also expanding<br>
his review focus such as the good feedback he's been providing on new<br>
Mistral actions in tripleo-common for custom-roles.<br>
<br>
2. Pradeep Kilambi<br>
<br>
Pradeep has done a large amount of pretty complex work around Ceilomenter<br>
and Aodh over the last two cycles - he's dealt with some pretty tough<br>
challenges around upgrades and has consistently provided good review<br>
feedback and solid analysis via discussion on IRC. I propose Prad<br>
continues this excellent Ceilomenter/Aodh focussed work, while also<br>
expanding review focus aiming to cover more of t-h-t and other repos over<br>
time.<br>
<br>
3. Carlos Camacho<br>
<br>
Carlos has been mostly focussed on composability, and has done a great job<br>
of working through the initial architecture implementation, including<br>
writing some very detailed initial docs[3] to help folks make the transition<br>
to the new architecture. I'd suggest that Carlos looks to maintain this<br>
focus on composable services, while also building depth of reviews in other<br>
repos.<br>
<br>
4. Ryan Brady<br>
<br>
Ryan has been one of the main contributors implementing the new Mistral<br>
based API in tripleo-common. His reviews, patches and IRC discussion have<br>
consistently demonstrated that he's an expert on the mistral<br>
actions/workflows and I think it makes sense for him to help with review<br>
velocity in this area, and also look to help with those subsystems<br>
interacting with the API such as tripleoclient.<br>
<br>
5. Dan Sneddon<br>
<br>
For many cycles, Dan has been driving direction around our network<br>
architecture, and he's been consistently doing a relatively small number of<br>
very high-quality and insightful reviews on both os-net-config and the<br>
network templates for tripleo-heat-templates. I'd suggest Dan continues<br>
this focus, and he's indicated he may have more bandwidth to help with<br>
reviews around networking in future.<br>
<br>
Please can I get feedback from exisitng core reviewers - you're free to +1<br>
these nominations (or abstain), but any -1 will veto the process. I'll<br>
wait one week, and if we have consensus add the above folks to<br>
tripleo-core.<br>
<br>
Finally, there are quite a few folks doing great work that are not on this<br>
list, but seem to be well on track towards core status. Some of those<br>
folks I've already reached out to, but if you're not nominated now, please<br>
don't be disheartened, and feel free to chat to me on IRC about it. Also<br>
note the following:<br>
<br>
- We need folks to regularly show up, establishing a long-term pattern of<br>
doing useful reviews, but core status isn't about raw number of reviews,<br>
it's about consistent downvotes and detailed, well considered and<br>
insightful feedback that helps increase quality and catch issues early.<br>
<br>
- Try to spend some time reviewing stuff outside your normal area of<br>
expertise, to build understanding of the broader TripleO system - as<br>
discussed above subsystem experts are a good thing, but we also need<br>
to see some appreciation of the broader Tripleo archticture &<br>
interfaces (all the folks above have demonstrated solid knowledge of one<br>
or more of our primary interfaces, e.g the Heat or the Mistral layer)<br>
<br>
Thanks to everyone for the hard work during Newton, I'm looking forward to<br>
seeing what we can achieve during Ocata!<br>
<br>
Steve<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-June/096968.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2016-<wbr>June/096968.html</a><br>
[2] <a href="http://stackalytics.com/report/contribution/tripleo-group/90" rel="noreferrer" target="_blank">http://stackalytics.com/<wbr>report/contribution/tripleo-<wbr>group/90</a><br>
[3] <a href="http://docs.openstack.org/developer/tripleo-docs/developer/tht_walkthrough/tht_walkthrough.html" rel="noreferrer" target="_blank">http://docs.openstack.org/<wbr>developer/tripleo-docs/<wbr>developer/tht_walkthrough/tht_<wbr>walkthrough.html</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a></blockquote><div><br></div><div>+1 to all from me. <br></div></div><br></div></div>