74 lines
4.3 KiB
Plaintext
74 lines
4.3 KiB
Plaintext
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 candidancy 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)
|