Hey everyone, There was some discussion about this in the operator community, so I just wanted to make sure folks were aware of this recap that Thierry did. I think it nicely captures and summarizes some of the issues brought up in the long thread in openstack-dev.
Thanks, Sean ----- Forwarded message from Thierry Carrez <thie...@openstack.org> ----- Date: Mon, 18 Dec 2017 15:08:45 +0100 From: Thierry Carrez <thie...@openstack.org> To: OpenStack Development Mailing List <openstack-...@lists.openstack.org> Subject: [openstack-dev] [all] TL;DR: Switching to longer dev cycles ? Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-...@lists.openstack.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 A lot of people chose to stay away from the 118-message long thread and wish there was a summary of it and the discussions on IRC around it. Mike posted one on the -dev digest: https://www.openstack.org/blog/2017/12/developer-mailing-list-digest-december-9-15th/ Here is my try at summarizing, in hope it will be helpful. First, you should read the initial proposal at: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125473.html Most of the +1s appear to come from people that would welcome less of a "taxing treadmill" (in jgriffith's words). A significant share of them are in the packaging space, where the quantity of work is more directly correlated to the release cadence. A lot of objections were posted on the ML or on IRC (and for the record, I agree with most of them): 1/ Treating the symptom rather than underlying cause While increasing overall cycle length would ease the pain resulting from a number of issues, it does not directly treat the underlying causes, and it has other consequences that may not be as beneficial. The most obvious of those being that we'd get less done overall, due to having less forced rhythm/deadlines. 2/ Nobody would consume intermediary releases, resulting in longer feedback loops The proposal encourages releasing intermediary releases more often, as a way to keep releasing early and often. However, for most projects, users would likely wait for the "real" releases (those with proper feature freezes, stabilization period and stable branches for post-release bugfixes) rather than use the intermediaries. This would likely result in a deteriorated longer feedback loop, with devs waiting up to one year to get real-world usage / bugs on a feature they just added. So 6-month "real" releases might still be the right sweet spot between what we can deliver and a reasonable feedback loop length. 3/ The change would not simplify the life of part-time contributors The main driver for the proposal is to make OpenStack development more doable by people who can only spend 20% of their work time on OpenStack upstream development, as our current pace can be overwhelming. However, most of the difficulty to keep up is linked to change velocity, and change velocity is not directly driven by cycle length, so it may stay mostly the same. If a change is too big to land in 6-month work by a part-time contributor, it can be split. And if a change misses the boat, it's a one-year wait rather than a 6-month one. 4/ The overhead of cycle events is not that overwhelming One goal of the proposal is to reduce the amount of time spent in a year around development cycle events and process (PTL election, PTG preparation, feature freeze, release process...) in order to get some extra time back. Some objected that these don't take that much time, that feature freeze or PTG prep are actually good things to do, or that boilerplate can be reconsidered without lengthening the cycle. We could, for example, only run one PTL election per year without increasing the dev cycle length. 5/ Most issues that the proposal aims to solve can be solved with better project management Getting more realistic at planning the work that can get done within a cycle would go a long way to make people feel better about the available time they have. Actively engaging with part-time contributors and making them feel welcome and valuable would probably drive more direct results than an extrinsic change like increasing the cycle length. This may point to the need to spend more time together in a productive environment like the PTG rather than less. 6/ Larger events are easier to justify and get to For a number of people it is easier to justify traveling to PTGs than to smaller midcycles team meetups. Removing one PTG might therefore limit valuable face-to-face time for team members. It would definitely reduce the amount of time we spend on cross-project collaboration. 7/ Focus on the real solutions Fast-forward upgrades (and supporting selected branches past their end of life) are the real solutions for helping users and vendors keep up with the rate of releases, not making less of them. We should focus on that, and the proposal might actually make that more difficult (or a longer endeavor). We could also try to make releases cycles less of a "taxing treadmill" by removing as much boilerplate as possible within a cycle and implementing other low-hanging fruit changes. I hope I captured most of the objections. If you feel like one of the objections was not mentioned (or not adequately represented), please add to this thread :) -- Thierry Carrez (ttx) __________________________________________________________________________ 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 ----- End forwarded message ----- _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators