<div dir="ltr">+2 =)</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 28, 2014 at 11:21 PM, Michael Still <span dir="ltr"><<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br>
<br>
I would like to run for the OpenStack Compute PTL position as well.<br>
<br>
I have been an active nova developer since late 2011, and have been a<br>
core reviewer for quite a while. I am currently serving on the<br>
Technical Committee, where I have recently been spending my time<br>
liaising with the board about how to define what software should be<br>
able to use the OpenStack trade mark. I've also served on the<br>
vulnerability management team, and as nova bug czar in the past.<br>
<br>
I have extensive experience running Open Source community groups,<br>
having served on the TC, been the Director for <a href="http://linux.conf.au" target="_blank">linux.conf.au</a> 2013, as<br>
well as serving on the boards of various community groups over the<br>
years.<br>
<br>
In Icehouse I hired a team of nine software engineers who are all<br>
working 100% on OpenStack at Rackspace Australia, developed and<br>
deployed the turbo hipster third party CI system along with Joshua<br>
Hesketh, as well as writing nova code. I recognise that if I am<br>
successful I will need to rearrange my work responsibilities, and my<br>
management is supportive of that.<br>
<br>
The future<br>
--------------<br>
<br>
To be honest, I've thought for a while that the PTL role in OpenStack<br>
is poorly named. Specifically, its the T that bothers me. Sure, we<br>
need strong technical direction for our programs, but putting it in<br>
the title raises technical direction above the other aspects of the<br>
job. Compute at the moment is in an interesting position -- we're<br>
actually pretty good on technical direction and we're doing<br>
interesting things. What we're not doing well on is the social aspects<br>
of the PTL role.<br>
<br>
When I first started hacking on nova I came from an operations<br>
background where I hadn't written open source code in quite a while. I<br>
feel like I'm reasonably smart, but nova was certainly the largest<br>
python project I'd ever seen. I submitted my first patch, and it was<br>
rejected -- as it should have been. However, Vishy then took the time<br>
to sit down with me and chat about what needed to change, and how to<br>
improve the patch. That's really why I'm still involved with<br>
OpenStack, Vishy took an interest and was always happy to chat. I'm<br>
told by others that they have had similar experiences.<br>
<br>
I think that's what compute is lacking at the moment. For the last few<br>
cycles we're focused on the technical, and now the social aspects are<br>
our biggest problem. I think this is a pendulum, and perhaps in a<br>
release or two we'll swing back to needing to re-emphasise on<br>
technical aspects, but for now we're doing poorly on social things.<br>
Some examples:<br>
<br>
- we're not keeping up with code reviews because we're reviewing the<br>
wrong things. We have a high volume of patches which are unlikely to<br>
ever land, but we just reject them. So far in the Icehouse cycle we've<br>
seen 2,334 patchsets proposed, of which we approved 1,233. Along the<br>
way, we needed to review 11,747 revisions. We don't spend enough time<br>
working with the proposers to improve the quality of their code so<br>
that it will land. Specifically, whilst review comments in gerrit are<br>
helpful, we need to identify up and coming contributors and help them<br>
build a relationship with a mentor outside gerrit. We can reduce the<br>
number of reviews we need to do by improving the quality of initial<br>
proposals.<br>
<br>
- we're not keeping up with bug triage, or worse actually closing<br>
bugs. I think part of this is that people want to land their features,<br>
but part of it is also that closing bugs is super frustrating at the<br>
moment. It can take hours (or days) to replicate and then diagnose a<br>
bug. You propose a fix, and then it takes weeks to get reviewed. I'd<br>
like to see us tweak the code review process to prioritise bug fixes<br>
over new features for the Juno cycle. We should still land features,<br>
but we should obsessively track review latency for bug fixes. Compute<br>
fails if we're not producing reliable production grade code.<br>
<br>
- I'd like to see us focus more on consensus building. We're a team<br>
after all, and when we argue about solely the technical aspects of a<br>
problem we ignore the fact that we're teaching the people involved a<br>
behaviour that will continue on. Ultimately if we're not a welcoming<br>
project that people want to code on, we'll run out of developers. I<br>
personally want to be working on compute in five years, and I want the<br>
compute of the future to be a vibrant, friendly, supportive place. We<br>
get there by modelling the behaviour we want to see in the future.<br>
<br>
So, some specific actions I think we should take:<br>
<br>
- when we reject a review from a relatively new contributor, we should<br>
try and pair them up with a more experienced developer to get some<br>
coaching. That experienced dev should take point on code reviews for<br>
the new person so that they receive low-latency feedback as they<br>
learn. Once the experienced dev is ok with a review, nova-core can<br>
pile on to actually get the code approved. This will reduce the<br>
workload for nova-core (we're only reviewing things which are of a<br>
known good standard), while improving the experience for new<br>
contributors.<br>
<br>
- we should obsessively track review performance for bug fixes, and<br>
prioritise them where possible. Let's not ignore features, but let's<br>
agree that each core should spend at least 50% of their review time<br>
reviewing bug fixes.<br>
<br>
- we should work on consensus building, and tracking the progress of<br>
large blueprints. We should not wait until the end of the cycle to<br>
re-assess the v3 API and discover we have concerns. We should be<br>
talking about progress in the weekly meetings and making sure we're<br>
all on the same page. Let's reduce the level of surprise. This also<br>
flows into being clearer about the types of patches we don't want to<br>
see proposed -- for example, if we think that patches that only change<br>
whitespace are a bad idea, then let's document that somewhere so<br>
people know before they put a lot of effort in.<br>
<br>
Thanks for taking the time to read this email!<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
<br>
--<br>
Rackspace Australia<br>
<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>
</font></span></blockquote></div><br></div>