Open Stack

confirmed

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