I've updated the etherpad with changes that reflect the current feedback. Please review and add any additional feedback there. Thank you! https://etherpad.openstack.org/p/stx-release-policy-draft brucej -----Original Message----- From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Friday, March 29, 2019 10:06 AM To: Dean Troyer <dtroyer@gmail.com>; Seiler, Glenn <glenn.seiler@windriver.com> Cc: starlingx-discuss <starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] DRAFT release policy Dean, Glenn - thank you for the feedback. I agree with it. There is also some feedback in the etherpad. I'm going to respond to both sets in the etherpad and try to improve the policy and the wording. https://etherpad.openstack.org/p/stx-release-policy-draft Thanks! brucej -----Original Message----- From: Dean Troyer [mailto:dtroyer@gmail.com] Sent: Thursday, March 28, 2019 7:29 PM To: Seiler, Glenn <glenn.seiler@windriver.com> Cc: Jones, Bruce E <bruce.e.jones@intel.com>; starlingx-discuss <starlingx-discuss@lists.starlingx.io> Subject: Re: [Starlingx-discuss] DRAFT release policy On Thu, Mar 28, 2019 at 6:39 PM Seiler, Glenn <glenn.seiler@windriver.com> wrote:
1- We need to move away from time-based releases 2- We need to do twice a year releases. This stmt, by definition, implies a time-gated release. Maybe it isn’t a specific date, but it is still time-gated.
The wording does need work, yes. After a short conversation with Bruce this afternoon (Bruce, correct me if I'm wrong here) I came away with the intention being more of increasing the lag from OpenStack releases rather than separating completely from the OpenStack release cycle which is likely to stay at approx 6 months for a while (that's a rabbit hole under the bike shed I'd like to avoid just now).
As a nascent project, I think we need to show gradual and consistent progress.
++
I did listen to much of the release team meeting today, and realize the trade-offs between big-rocks and timing are very difficult.
Given the difficult choice of functionality versus timing, I personally think we need to show progress in getting to Stein and a container based distribution as major milestones in 1H and perhaps defer the Distributed Cloud capability to a 2H release.
I don’t see anything intrinsically wrong with moving a specific date out; it happens all the time. But I also think a release should have some gate; i.e. we don’t move out of 1H. And if some functionality isn’t ready, then we move the functionality to another release in 2H.
We took a stab at estimating and missed, making adjustments now is normal and to be expected. I agree with considering pushing distcloud to the next release because it is a) new functionality, and b) devs overlap with the container work and I think making the k8s infrastructure rock solid is much more important. If we are too far off with system stability the ramifications will be harder to overcome than delaying a new feature.
Anyway, that would be my vote, if I have one.
You totally have a voice as part of the community, I would like to hear from more folks here... dt -- Dean Troyer dtroyer@gmail.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss