Excerpts from Drew Fisher's message of 2017-05-03 14:00:53 -0600: > This email is meant to be the ML discussion of a question I brought up > during the TC meeting on April 25th.; [1]
Thanks for starting this thread, Drew. I'll try to respond, but I know a lot of folks are preparing for the summit next week, so it may be a little quiet around here until after everyone is home. > > The TL;DR version is: > > > Reading the user survey [2], I see the same issues time and time again. > Pages 18-19 of the survey are especially common points. I was also interested in those comments and noticed that, as you say, some are recurring themes. That reinforces in my mind that we haven't adequately communicated the background behind some decisions we've made in the past, or what we would need to do to make progress on stalled initiatives. I've started trying to address some of those issues [1], and I'll be continuing that work after the summit. [1] https://doughellmann.com/blog/2017/04/20/lessons-learned-from-working-on-large-scale-cross-project-initiatives-in-openstack/ > Things move too fast, I have to say, after so many years of hearing that we weren't moving fast enough this one was a big surprise. :-) I'm not sure if that's good or bad, or if it just means we now have a completely different set of people responding to the user survey. > no LTS release, Over the past couple of years we have shifted the majority of the backport review work off of a centralized team so that the individual project teams are responsible for establishing their own stable review groups. We've also changed the way we handle stable releases, so that we now encourage projects to tag a release when they need it instead of waiting and trying to tag all of the projects together at the same time. As a result of these changes, we've been seeing more stable releases for the branches we do maintain, giving users more actual bug fix releases for those series. That said, there are two main reasons we are unlikely to add more stable releases or maintain any releases for longer: we need more people to do the work, and we need to find a way to do that work that doesn't hurt our ability to work on master. We do still have a stable team responsible for ensuring that projects are following the policies for stable releases, and that team needs more participation. I'm sure the project teams would appreciate having more help with backports and reviews on their stable branches, too. Getting contributors to work on those tasks has been difficult since the very beginning of the project. It has been difficult to attract contributors to this area in part due to the scope of work that is necessary to say that the community supports those releases. We need the older versions of the deployment platforms available in our CI systems to run the automated tests. We need supported versions of the development tools (setuptools and pip are especially problemmatic). We need supported versions of the various libraries and system-level dependencies like libvirt. I'm sure the stable maintenance team could add to that list, but the point is that it's not just a matter of saying we want to do it, or even that we *will* do it. > upgrades are terrifying for anything that isn't N-1 -> N. The OpenStack community has a strong culture of testing. We have reasonable testing in place to balance our ability to ensure that N-1 -> N upgrades work and as a result upgrades are easier than ever. It seems quite a few users are still on the older versions of the software that don't have some of those improvements. It's not the ideal answer, but their experience will continue to improve as they move forward onto newer releases. Meanwhile, adding more combinations of upgrades to handle N-M -> N changes our ability to simplify the applications by removing technical debt and by deprecating configuration options (reducing complexity by cutting the number of configuration options has also been a long-standing request from users). It also means more people are needed to keep those older releases running in CI, so that the upgrade jobs are reliable (see the discussion above about why that is an issue). > These come up time and time again > How is the TC working with the dev teams to address these critical issues? > > I asked this because on page 18 is this comment: > > "Most large customers move slowly and thus are running older versions, > which are EOL upstream sometimes before they even deploy them." > > This is exactly what we're seeing with some of our customers and I > wanted to ask the TC about it. The contributors to OpenStack are not a free labor pool for the consumers of the project. Just like with any other open source project, the work is done by the people who show up, and we're all motivated to work on different things. Many (most?) of us are paid by companies selling products or services based on OpenStack. Those companies apply resources, in the form of contributor time and attention, based on their users' needs. The TC and other community leaders have tried to respond to that particular source of contributor motivation while still honoring contributions of all forms by organizing the project to enable *all* contributors to achieve their goals, regardless of whether they are working for a "vendor" of some sort, or are a user building their own packages and relying on the community for support. Having done both while I've been active with OpenStack, I can honestly say that the best way to get what you want is to participate in creating it. If there were people trying to do this work, I expect that we would find a way to make it possible. For anyone interested in contributing to stable release maintenance, the best course of action is to get involved with the team responsible for organizing that work to learn our current processes and policies. When that team grows large enough that it's clear we can sustain more stable releases or upgrade combinations, the people involved will have a clear enough understanding of the problem space that they will be able to design the necessary policy and process changes. Doug > > Thanks, > > -Drew > > > > > [1] > http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-177 > [2] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
