openstack
/
election
Code Issues Proposed changes

Merge "Sylvain Bauza candidacy for TC"

This commit is contained in:
Zuul 2024-02-27 22:49:27 +00:00 committed by Gerrit Code Review
parent 58aeadcbcc d13e048b9c
commit a1856fb190
1 changed files with 51 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
candidates/2024.2/TC/sbauza@redhat.com Normal file
View File

@ -0,0 +1,51 @@
Howdy folks,
That's now been a long time I'm thinking about running for a TC seat but I
never really thought about it until today. Now, I think this is the best time
for me asking you to accept me as a TC member and I'll explain why below.
First, in case you don't know me yet, I'm Sylvain Bauza (bauzas on IRC),
working on OpenStack since... wow, 11 years already ? I first started to test
OpenStack Diablo and Essex for a SME company but eventually moved to another
(and then another) position and became contributor, first to the Blazar (that
time named Climate) project and then Nova for 10 years now, eventually becoming
nova-core and PTL.
Time flies and now I'm still there, happy with what OpenStack became. Of
course, it changed. But honestly, I haven't seen more operators using it
previously than now, which means that we succeeded as a team to make OpenStack
useful for our users. As a Nova PTL for the previous cycles, I know how
important it is to get feedback from our operators and how much this is crucial
to provide help for them.
The last discussions I had with the community led to me think that this motto
needs to be addressed as a whole and not only on a per-project basis, hence
convincing myself that I should run for a TC seat. As someone evolving from a
operations position in a SME company to a core developer working with large
cloud deployments, I wish I could help the TC driving some efforts into
shortening the feedback loop within the community. I'd also want to help the TC
provide some guidance on the new SLURP release cadence model to all the
projects so that we could really achieve a skip-release upgrade that would
benefit to our operators.
There are a couple of other stuff I do really care and I wish to help them.
CI gate stability is one of them. Having transient failures close to a
milestone is not a good experience for us and we need to really address
those failures as top priorities when they occur. We should somehow recognize
the very fews who dedicate time on chasing those issues and fixing them, as
their contributors are mostly valuable, since not a single code of code can't
merge when a gate is down.
Maintaining our code is another important aspect to me. Recent experiences on
not-so-well-maintained dependencies led us force to evaluate all the options
and those decisions aren't easy to make. As someone caring about maintaining
our code for stable releases, I wish I could help the TC to correctly identify
risks and benefits of breaking changes and evaluate the impact it may have
on our feature delivery.
Enough talk, I'll end up here, saying that after those 10 years in the
community, I'm still enjoying being part of it and how much I do love working
with all of you.
Cheers,
-Sylvain