Juno TC Candidacy

Share

Another email archived for historical reasons.

I'd also like to announce my TC candidacy. I am currently a member of
the TC, and I would like to continue to serve.

I first started hacking on Nova during the Diablo release, with my
first code contributions appearing in the Essex release. Since then
I've hacked mostly on Nova and Oslo, although I have also contributed
to many other projects as my travels have required. For example, I've
tried hard to keep various projects in sync with their imports of
parts of Oslo I maintain.

I work full time on OpenStack at Rackspace, leading a team of
developers who work solely on upstream open source OpenStack. I am a
Nova and Oslo core reviewer and the Nova PTL.

I have been serving on the TC for the last year, and in the Icehouse
release started acting as the liaison for the board "defcore"
committee along with Anne Gentle. "defcore" is the board effort to
define what parts of OpenStack we require vendors to ship in order to
be able to use the OpenStack trade mark, so it involves both the board
and the TC. That liaison relationship is very new and only starting to
be effective now, so I'd like to keep working on that if you're
willing to allow it.
Share

Thoughts from the PTL

Share

I sent this through to the openstack-dev mailing list (you can see the thread here), but I want to put it here as well for people who don’t actively follow the mailing list.

First off, thanks for electing me as the Nova PTL for Juno. I find the
outcome of the election both flattering and daunting. I'd like to
thank Dan and John for running as PTL candidates as well -- I strongly
believe that a solid democratic process is part of what makes
OpenStack so successful, and that isn't possible without people being
will to stand up during the election cycle.

I'm hoping to send out regular emails to this list with my thoughts
about our current position in the release process. Its early in the
cycle, so the ideas here aren't fully formed yet -- however I'd rather
get feedback early and often, in case I'm off on the wrong path. What
am I thinking about at the moment? The following things:

* a mid cycle meetup. I think the Icehouse meetup was a great success,
and I'd like to see us do this again in Juno. I'd also like to get the
location and venue nailed down as early as possible, so that people
who have complex travel approval processes have a chance to get travel
sorted out. I think its pretty much a foregone conclusion this meetup
will be somewhere in the continental US. If you're interested in
hosting a meetup in approximately August, please mail me privately so
we can chat.

* specs review. The new blueprint process is a work of genius, and I
think its already working better than what we've had in previous
releases. However, there are a lot of blueprints there in review, and
we need to focus on making sure these get looked at sooner rather than
later. I'd especially like to encourage operators to take a look at
blueprints relevant to their interests. Phil Day from HP has been
doing a really good job at this, and I'd like to see more of it.

* I promised to look at mentoring newcomers. The first step there is
working out how to identify what newcomers to mentor, and who mentors
them. There's not a lot of point in mentoring someone who writes a
single drive by patch, so working out who to invest in isn't as
obvious as it might seem at first. Discussing this process for
identifying mentoring targets is a good candidate for a summit
session, so have a ponder. However, if you have ideas let's get
talking about them now instead of waiting for the summit.

* summit session proposals. The deadline for proposing summit sessions
for Nova is April 20, which means we only have a little under a week
to get that done. So, if you're sitting on a summit session proposal,
now is the time to get it in.

* business as usual. We also need to find the time for bug fix code
review, blueprint implementation code review, bug triage and so forth.
Personally, I'm going to focus on bug fix code review more than I have
in the past. I'd like to see cores spend 50% of their code review time
reviewing bug fixes, to make the Juno release as solid as possible.
However, I don't intend to enforce that, its just me asking real nice.

Thanks for taking the time to read this email, and please do let me
know if you think this sort of communication is useful.
Share