[Starlingx-discuss] DRAFT release policy

[Khalil, Ghada]

Hi Bruce,
I have a comment regarding this point:

The severity and number of bugs open against the release
Proposal: No open Critical or High severity bugs against the release candidate.  Or maybe 1-3 Highs if we have a clear resolution plan (and a plan to release a patch against the release?)

         (ghada) We use an explicit tag to identify which bugs gate a particular release (regardless of severity). The whole list will have to be reviewed and scrubbed prior to reaching the release milestone. I don't feel it is sufficient to only review Critical / Major issues. [Example: On April 1/2019, there are 85 release gating bugs: only 13 are Critical/High. Yet it wouldn't be sufficient to only fix those 13 to ensure a quality release].
         In the Release Planning wiki[1] , we have previously stated this policy: 
All release gating issues are addressed or reviewed/accepted for deferral
I feel we need to keep this.

[1] https://wiki.openstack.org/wiki/StarlingX/Release_Plan


-----Original Message-----
From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] 
Sent: Friday, March 29, 2019 2:10 PM
To: Jones, Bruce E; Dean Troyer; Seiler, Glenn
Cc: starlingx-discuss
Subject: Re: [Starlingx-discuss] DRAFT release policy

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 at intel.com] 
Sent: Friday, March 29, 2019 10:06 AM
To: Dean Troyer <dtroyer at gmail.com>; Seiler, Glenn <glenn.seiler at windriver.com>
Cc: starlingx-discuss <starlingx-discuss at 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 at gmail.com] 
Sent: Thursday, March 28, 2019 7:29 PM
To: Seiler, Glenn <glenn.seiler at windriver.com>
Cc: Jones, Bruce E <bruce.e.jones at intel.com>; starlingx-discuss <starlingx-discuss at lists.starlingx.io>
Subject: Re: [Starlingx-discuss] DRAFT release policy

On Thu, Mar 28, 2019 at 6:39 PM Seiler, Glenn <glenn.seiler at 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 at gmail.com
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss