The last session related to extended releases is: OpenStack is "mature" -- time
to get serious on Maintainers
It will be in room 220 at 11:00-11:40
The etherpad for the last session in the series on Extended releases is here:
There are links to info on other communities’ maintainer
process/role/responsibilities also, as reference material on how other have
made it work (or not).
The nitty gritty details:
The upcoming Forum is filled with sessions that are focused on issues needed to
improve and maintain the sustainability of OpenStack projects for the long
term. We have discussion on reducing technical debt, extended releases, fast
forward installs, bringing Ops and User communities closer together, etc. The
community is showing it is now invested in activities that are often part of
“Sustaining Engineering” teams (corporate speak) or “Maintainers (OSS speak).
We are doing this; we are thinking about the moving parts to do this; let’s
think about the contributors who want to do these and bring some clarity to
their roles and the processes they need to be successful. I am hoping you read
this and keep these ideas in mind as you participate in the various Forum
sessions. Then you can bring the ideas generated during all these discussions
to the Maintainers session near the end of the Summit to brainstorm how to
visualize and define this new(ish) component of our technical community.
So, who has been doing the maintenance work so far? Mostly (mostly) unsung
heroes like the Stable Release team, Release team, Oslo team, project liaisons
and the community goals champions (yes, moving to py3 is a
sustaining/maintenance type of activity). And some operators (Hi, mnaser!).
We need to lean on their experience and what we think the community will need
to reduce that technical debt to outline what the common tasks of maintainers
should be, what else might fall in their purview, and how to partner with them
to better serve them.
With API lower limits, new tool versions, placement, py3, and even projects
reaching “code complete” or “maintenance mode,” there is a lot of work for
maintainers to do (I really don’t like that term, but is there one that fits
OpenStack’s community?). It would be great if we could find a way to share the
load such that we can have part time contributors here. We know that operators
know how to cherrypick, test in there clouds, do bug fixes. How do we pair
with them to get fixes upstreamed without requiring them to be full on
developers? We have a bunch of alumni who have stopped being “cores” and
sometimes even developers, but who love our community and might be willing and
able to put in a few hours a week, maybe reviewing small patches, providing
help with user/ops submitted patch requests, or whatever. They were trusted
with +2 and +W in the past, so we should at least be able to trust they know
what they know. We would need some way to identify them to Cores, since they
would be sort of 1.5 on the voting scale, but……
So, burn out is high in other communities for maintainers. We need to find a
way to make sustaining the stable parts of OpenStack sustainable.
Hope you can make the talk, or add to the etherpad, or both. The etherpad is
very musch still a work in progress (trying to organize it to make sense). If
you want to jump in now, go for it, otherwise it should be in reasonable shape
for use at the session. I hope we get a good mix of community and a good
collection of those who are already doing the job without title.
Thanks and see you next week.
华为技术有限公司 Huawei Technologies Co., Ltd.
Sr. Staff Architect, Open Source
This e-mail and its attachments contain confidential information from HUAWEI,
is intended only for the person or entity whose address is listed above. Any
use of the
information contained herein in any way (including, but not limited to, total
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify
the sender by
phone or email immediately and delete it!
OpenStack-operators mailing list