Open Stack

I would like to propose my candidacy for the Neutron PTL.

I have been the Neutron PTL for the Mitaka release, and I would like to
continue the journey on which I have embarked upon a little over six months
ago.

Back then, I had a number of objectives which I wanted to achieve with the
help of the Neutron team, and with this candidacy statement I would like to
take the opportunity to look back and see what we have accomplished and
what else is waiting ahead of us:

   - Stability is the priority: I have introduced a rotation mechanism for
   triaging and staying on top of bugs; with that, we have a very little
   percentage of bugs that go unacknowledged, and even though we only managed
   to fix only 60% of all bugs reported in the Mitaka timeframe, some might
   regard this as a remarkable achievement. I also made sure the Neutron
   projects was amongst the most stable one, by aggressively addressing
   intermittent failures, and by ensuring that failures did not impact the
   integrated gate. As of today, the success rate for Neutron (alone) is at
   >98%. We also worked hard to extend test coverage to DVR, Linuxbridge and
   Grenade multinode. Going forward, I'd like to focus on improving the
   stability of multinode jobs, and look at how we can do more reliable and
   exhaustive performance testing on a more regular basis.
   - Narrow the focus: we all know by now my attempt to address the needs
   and the issues of the Stadium, and the team effort aimed at standing up
   neutron-lib to allow for Neutron projects to loosely couple together. The
   journey is far from being over and I will continue to work towards a
   resolution that strikes a good compromise for everybody. On the other end,
   I worked hard with the rest of the drivers team members to ensure a
   coherent strategy and vision when assessing and approving RFE's. I proposed
   process changes to ensure that reviewers and contributors can be more
   focussed and work together towards a well defined goal.
   - Consistency is paramount: promoting the documentation of our practices
   (like our deputy, blueprint/rfe guidelines and release postmortem), as well
   as starting the 'Effective Neutron' guide have been two key areas that
   allowed our developers to have a common understanding on how we operate,
   review, develop and manage our project. More needs to be done to ensure we
   become 'more predictable' in terms of the software we produce and the
   quality associated with it, including end-user facing documentation.
   - Define long term strategy: when I started looking at this area,
   Neutron had 400+ blueprints targeted. I tried to put some sanity back into
   the feature submission process by limiting who can actually submit feature
   proposals (the drivers team) and by cleaning up the huge backlog of
   blueprints we had (currently we have 15 blueprints and 19 RFEs). That said
   this is an area where I feel I have not made enough of a dent to be
   satisfied. This is somewhat tangential to the needs of the Stadium, but I
   think we need more time to execute a plan of action that can yield positive
   results.
   - Keep developers and reviewers _aware_: I worked relentlessly to remind
   our reviewers to stay focussed and review what matters for a given release.
   I think we have achieved this with mixed success, and I know that some of
   us worked hard to give us the tools to help us stay more aware.
   - I would like to promote a 'you merge it, you own it' type of
   mentality: this is typically done by leading by example, and I am pleased
   to see that many of us take great pride in the code they review and merge.
   We need to continue to promote this attitude.

And last but not least:

   - Improve the relationships with other projects: Nova and QA primarily.
   I personally feel that we went a long way to improve these relationships,
   from the technical front (for example by improving the provisioning
   workflow of networking resources for Nova instances - aka get-me-a-network,
   and by tackling the testing issues affecting Neutron) to the the social
   front, by having a good representation of contributors across multiple
   projects at the various mid-cycle events. There is always room for
   improvement, of course!

If you liked what I did/said, then allow me to continue.

Thanks for reading and, as usual, forgive the typos!
Armando Migliaccio (aka armax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160316/4a0972b5/attachment.html>