Juno Nova PTL Candidacy

Share

This is a repost of an email to the openstack-dev list, which is mostly here for historical reasons.

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 recognize 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!
Share

The Hot Gate

Share

This book follows on from Live Free or Die and Citadel. This time we focus solely on Dana as she is transferred to a new unit. The story is interesting, although perhaps it focusses on the dysfunction of the Latin American countries a little more than is really necessary. More interestingly, the book ends the series (as best as I can tell) in an unusual manner for a book like this, with the humans not winning a simple out right victory — moral or otherwise. Overall, a fun light read.

The Hot Gate Book Cover The Hot Gate
John Ringo
Fiction
Baen
April 24, 2012
560

New York Times best seller in hardcover. Armed forces veteran and seven-time New York Times best-selling author John Ringo delivers the third entry in his blockbuster Troy Rising SF series. Humanity fights back against a devastating Trojan-horse-like alien invasion of Earth and takes the fight to the stars by creating a vast battlestation as large as a planet. The third entry in the best-selling Troy Rising saga and follow-up to blockbuster Citadel from multiple New York Times and USA Today bestseller and military SF master, John Ringo. When the orbital gates first materialized in the outer Solar System, all seemed well, but a devastating invasion ensued. Now humans have battled back from the conquest by a tyrannical alien species to become a force to reckon with in the galaxy. On a crash-building course, humanity has created a near-impregnable battlestation of Deathstar proportions to prove it. But the enemy is remorseless and to survive humans must take the fight to the heart of their empire and prevail–a feat no previous species has ever accomplished. Instead, the bones and burnt hulks of those who have tried litter the star-ways. But these galactic imperialists have never contended with humans, a foe who is their match in sheer ferocity and desire to win. About the Troy Rising series: “[I]nfused with plenty of old-fashioned two-fisted can-do attitude . . .” –Publishers Weekly “[I]rresistible action-sf . . .[filled with] Ringo’s amazingly fertile imagination.” –Booklist About John Ringo: “[O]ne of the best…practitioners. . .of military SF.” –Publishers Weekly "[F]ast-paced military SF peopled with three-dimensional characters and spiced with personal drama as well as tactical finesse" –Library Journal “[Ringo’s work] “attains a terrible beauty not unlike that of the Norse Eddas…” –Publishers Weekly "If Tom Clancy were writing SF, it would read much like John Ringo.” –Philadelphia Weekly Press

Share

Citadel

Share

This book follows on from Live Free or Die. I like the approach of this book, as it follows a couple of relatively normal people trying to get by, and how the main protagonist from the last book’s actions affect them. Its an engaging read, while still progressing the overall arc of the series. I really enjoyed it.

Citadel Book Cover Citadel
John Ringo
Fiction
Baen Books
October 25, 2011
560

Hostilities escalate between the Rangora Empire and Earth defenders who seek to recapture the Sol system, a conflict that prompts military and civilian forces to render the Troy battle station an interactive war engine.

Share

The Runaway Jury

Share

This is an older book now, and I read it many many years ago but re-read it this last couple of weeks. I enjoyed this book. Its believable (if a little dated now), and interesting. It certainly made me think more about the first amendment and how it affects dangerous products like cigarettes than I would have otherwise.

The Runaway Jury Book Cover The Runaway Jury
John Grisham
Fiction
Dell Publishing Company
1997
550

A member of the jury for the century's most explosive trial against a giant tobacco company, Juror #2, a mysterious man with a past and a hidden agenda, joins forces with a beautiful woman on the outside to get the verdict he wants, no matter what the cost. Reissue. (A 20th Century Fox film, releasing Fall 2003, starring Gene Hackman, Dustin Hoffman, & John Cusack) (Suspense)

Share