Thanks, Lance! Also, the more I think about it, the more I think Maintainer has too much baggage to use that term for this role. It really is “continuity” that we are looking for. Continuous important fixes, continuous updates of tools used to produce the SW.
Keep this in the back of your minds for the discussion. And yes, this is a discussion to see if we are interested, and only if there is interest, how to move forward. --Rocky From: Lance Bragstad [mailto:lbrags...@gmail.com] Sent: Friday, May 18, 2018 2:03 PM To: Rochelle Grober <rochelle.gro...@huawei.com>; openstack-dev <openstack-...@lists.openstack.org>; openstack-operators <openstack-operators@lists.openstack.org>; user-committee <user-commit...@lists.openstack.org> Subject: Re: [User-committee] [Forum] [all] [Stable] OpenStack is "mature" -- time to get serious on Maintainers -- Session etherpad and food for thought for discussion Here is the link to the session in case you'd like to add it to your schedule [0]. [0] https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21759/openstack-is-mature-time-to-get-serious-on-maintainers On 05/17/2018 07:55 PM, Rochelle Grober wrote: Folks, TL;DR 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: https://etherpad.openstack.org/p/YVR-openstack-maintainers-maint-pt3 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. --rocky ________________________________ 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo] Rochelle Grober Sr. Staff Architect, Open Source Office Phone:408-330-5472 Email:rochelle.gro...@huawei.com<mailto:Email:rochelle.gro...@huawei.com> ________________________________ 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which 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 or partial 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! _______________________________________________ User-committee mailing list user-commit...@lists.openstack.org<mailto:user-commit...@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
