[Starlingx-discuss] Proposal: Release Plan
I would like to propose the following dates and milestones for the first StarlingX release. All of this is documented at https://etherpad.openstack.org/p/stx-planning. Please review and provide feedback. Going forward I'd like to figure out how to align with the overall OpenStack release cadence. That topic will be discussed at the September PTG - you can find the draft agenda at https://etherpad.openstack.org/p/stx-PTG-agenda. Please feel free to add any topics you'd like to see discussed there. brucej Release Planning We would like to complete our first release in time to have it available (and be able to talk about how cool it is!) at the OpenStack Summit in Berlin on November 13, 2018. Proposed schedule RC1: August 29th RC2: September 26th - Feature Freeze RC3: October 24th - Bug freeze - only absolutely critical bug fixes after this RC4: November 7th - Final release candidate Theme: Deliver a release of StarlingX that supports containers and meets our KPI targets while creating the basic project infrastructure, building the community and pushing carried patches to their upstream communities Our goals for this release are: * Create, define and document all of the basic project infrastructure * Recruit, attract and retain a community of developers and operators * Begin the process of pushing carried patches upstream and reducing technical debt * Add support for containerized Openstack Services and containerized workloads (stretch goal!)
Jones, Bruce E wrote:
[...] Going forward I’d like to figure out how to align with the overall OpenStack release cadence. That topic will be discussed at the September PTG – you can find the draft agenda at https://etherpad.openstack.org/p/stx-PTG-agenda. Please feel free to add any topics you’d like to see discussed there.
I'll try to join on that discussion !
[...] *Proposed schedule*
RC1: August 29th
RC2: September 26th - Feature Freeze
RC3: October 24th - Bug freeze - only absolutely critical bug fixes after this
RC4: November 7th - Final release candidate
If that is something you can change, I'd recommend that you keep the "RC" term for real release candidates -- things that could, at least in theory, be used as final releases. At the very least, RCs should be feature complete. Otherwise if you use them as basic development milestones, you dilute their meaning, which makes it harder to encourage people outside of your core group to actually test them. So I'd recommend using "beta1", "beta2"... for feature-incomplete milestones, and switch to "rc1" once you reach bug freeze :) Regards, -- Thierry Carrez (ttx) OpenStack Release Management team
Thierry, thank you for the feedback! You're recommending something like this, right? Beta1: August 29th Beta2: September 26th - Feature Freeze RC1, 2, 3...: October 24th - Bug freeze - only absolutely critical bug fixes RCx: November 7th - Final release candidate Brucej -----Original Message----- From: Thierry Carrez [mailto:thierry@openstack.org] Sent: Friday, June 22, 2018 5:18 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Proposal: Release Plan Jones, Bruce E wrote:
[...] Going forward I’d like to figure out how to align with the overall OpenStack release cadence. That topic will be discussed at the September PTG – you can find the draft agenda at https://etherpad.openstack.org/p/stx-PTG-agenda. Please feel free to add any topics you’d like to see discussed there.
I'll try to join on that discussion !
[...] *Proposed schedule*
RC1: August 29th
RC2: September 26th - Feature Freeze
RC3: October 24th - Bug freeze - only absolutely critical bug fixes after this
RC4: November 7th - Final release candidate
If that is something you can change, I'd recommend that you keep the "RC" term for real release candidates -- things that could, at least in theory, be used as final releases. At the very least, RCs should be feature complete. Otherwise if you use them as basic development milestones, you dilute their meaning, which makes it harder to encourage people outside of your core group to actually test them. So I'd recommend using "beta1", "beta2"... for feature-incomplete milestones, and switch to "rc1" once you reach bug freeze :) Regards, -- Thierry Carrez (ttx) OpenStack Release Management team _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Jones, Bruce E wrote:
Thierry, thank you for the feedback!
You're recommending something like this, right? Beta1: August 29th Beta2: September 26th - Feature Freeze RC1, 2, 3...: October 24th - Bug freeze - only absolutely critical bug fixes RCx: November 7th - Final release candidate
Yes, that would be my recommendation. Regards, -- Thierry Carrez (ttx)
participants (2)
-
Jones, Bruce E
-
Thierry Carrez