Re: [Starlingx-discuss] RFC: StarlingX release cadence proposal
Given we have a planning board, what would be the mechanism to vote the contents (stories) as the targets of monthly release or quarterly release? Could it be acceptable if we break down a big story into several small items which come out in following multiple months, or even quarters? Regards Yong From: "Jones, Bruce E" <bruce.e.jones@intel.com> Date: Thursday, 28 June 2018 at 7:48 AM To: "starlingx-discuss@lists.starlingx.io" <starlingx-discuss@lists.starlingx.io> Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal At our weekly call today we discussed release plans and release cadence. It was a long discussion and a good one. In the end we agreed that we’d like to follow the “bus stop” model of time based releases, and the Ubuntu model of an annual major (LTS) release with quarterly updates. Note that we did not suggest or agree that our currently planned “Release 2” should be a LTS. We all agreed that would be premature. We will declare an LTS at some point in the future. After separate discussions with David, Dean and Ada, rather than just proposing that “our current November release is the first quarterly release”, I have a modified proposal to make for how we should handle releases. This is an RFC looking for feedback, questions and comments. Monthly milestone builds -------------------------------- Each month in the 2nd week of the month we will pull a branch. Dean and I suggest using year/month as the branch names, for simplicity. For example, we propose that the branch name for a July 2018 milestone build would be “stx.2018.07”. The version number of that build would be “stx.2018.07.0x”, where “0x” is a patch number. Yes, that’s a change to how version numbers are handled. See below. The purpose of the monthly build is to 1) provide a stable build for long running test cycles 2) provide a “latest known to be good” build for users and partners, and 3) feed into the quarterly release. Fixes for show stopping bugs found in monthly build testing should be done on master and cherry-picked to the branch, increasing the patch number with each one. Quarterly release -------------------- Each quarter’s quarterly release will be the monthly milestone build from the 2nd month in the quarter. This gives us 4-6 weeks of time to run test cycles and fix bugs for the release. For each quarterly release, the code freeze for that release is the 2nd week in the 2nd month in the quarter. Branch handling -------------- Branches from the 1st and 3rd month in a quarter can be short-lived. Branches for the 2nd month’s (quarterly) build will live longer and I would suggest at any given time we keep the N and N-1 quarterly release branches open for bug fixes. If/when we declare a LTS release, that branch would of course live much longer. Why? ----- Why do we release a build from the 2nd week of the 2nd month? In part because that schedule misses the major holiday weeks. No one likes to do releases over the summer or winter holidays. Impact ------- The planning for release content for what we are currently calling “Release 2” will need to change. If this proposal is accepted, we won’t have a “release 2” anymore, just a “release stx.2018.08.x” released in September and “release stx 2018.11.x” released in December. This changes the content we’d have in the release for the November summit (which would be the September release) but anyone there looking for the bleeding edge could pick up the RC for the December build, which would be in testing at that time. Branching also means that key bug fixes would need to be cherry picked to the older branches. New feature code should always go to master only. Version numbers ---------------- This proposal also includes a version number change from what the underlying TC product uses today. I think it’s inevitable that the StarlingX project has separate / different version numbers from TC, but I don’t know what it means to the system to actually get there, or what headaches it might cause. We should key that up as a separate discussion.
Yong, the proposal is for time based releases. When the features are ready, they get released. In terms of what gets released when, I’d like to see us do bottoms up planning, and yes it’s OK to break large efforts up into multiple items. Please feel free to do so. brucej From: Hu, Yong Sent: Wednesday, June 27, 2018 5:52 PM To: Jones, Bruce E <bruce.e.jones@intel.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] RFC: StarlingX release cadence proposal Given we have a planning board, what would be the mechanism to vote the contents (stories) as the targets of monthly release or quarterly release? Could it be acceptable if we break down a big story into several small items which come out in following multiple months, or even quarters? Regards Yong From: "Jones, Bruce E" <bruce.e.jones@intel.com<mailto:bruce.e.jones@intel.com>> Date: Thursday, 28 June 2018 at 7:48 AM To: "starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>" <starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>> Subject: [Starlingx-discuss] RFC: StarlingX release cadence proposal At our weekly call today we discussed release plans and release cadence. It was a long discussion and a good one. In the end we agreed that we’d like to follow the “bus stop” model of time based releases, and the Ubuntu model of an annual major (LTS) release with quarterly updates. Note that we did not suggest or agree that our currently planned “Release 2” should be a LTS. We all agreed that would be premature. We will declare an LTS at some point in the future. After separate discussions with David, Dean and Ada, rather than just proposing that “our current November release is the first quarterly release”, I have a modified proposal to make for how we should handle releases. This is an RFC looking for feedback, questions and comments. Monthly milestone builds -------------------------------- Each month in the 2nd week of the month we will pull a branch. Dean and I suggest using year/month as the branch names, for simplicity. For example, we propose that the branch name for a July 2018 milestone build would be “stx.2018.07”. The version number of that build would be “stx.2018.07.0x”, where “0x” is a patch number. Yes, that’s a change to how version numbers are handled. See below. The purpose of the monthly build is to 1) provide a stable build for long running test cycles 2) provide a “latest known to be good” build for users and partners, and 3) feed into the quarterly release. Fixes for show stopping bugs found in monthly build testing should be done on master and cherry-picked to the branch, increasing the patch number with each one. Quarterly release -------------------- Each quarter’s quarterly release will be the monthly milestone build from the 2nd month in the quarter. This gives us 4-6 weeks of time to run test cycles and fix bugs for the release. For each quarterly release, the code freeze for that release is the 2nd week in the 2nd month in the quarter. Branch handling -------------- Branches from the 1st and 3rd month in a quarter can be short-lived. Branches for the 2nd month’s (quarterly) build will live longer and I would suggest at any given time we keep the N and N-1 quarterly release branches open for bug fixes. If/when we declare a LTS release, that branch would of course live much longer. Why? ----- Why do we release a build from the 2nd week of the 2nd month? In part because that schedule misses the major holiday weeks. No one likes to do releases over the summer or winter holidays. Impact ------- The planning for release content for what we are currently calling “Release 2” will need to change. If this proposal is accepted, we won’t have a “release 2” anymore, just a “release stx.2018.08.x” released in September and “release stx 2018.11.x” released in December. This changes the content we’d have in the release for the November summit (which would be the September release) but anyone there looking for the bleeding edge could pick up the RC for the December build, which would be in testing at that time. Branching also means that key bug fixes would need to be cherry picked to the older branches. New feature code should always go to master only. Version numbers ---------------- This proposal also includes a version number change from what the underlying TC product uses today. I think it’s inevitable that the StarlingX project has separate / different version numbers from TC, but I don’t know what it means to the system to actually get there, or what headaches it might cause. We should key that up as a separate discussion.
On Wed, Jun 27, 2018 at 7:51 PM, Hu, Yong <yong.hu@intel.com> wrote:
Given we have a planning board, what would be the mechanism to vote the contents (stories) as the targets of monthly release or quarterly release?
To be clear, we don't really have a planning board. There is no official governance yet. What we do have is consensus among the two primary groups (Wind River and Intel) involved in the project before the public release to continue our work openly in basically our current fashion until we do have governance. My brain parses that as our mechanism is now to have the discussions here (on the mailing list) and in IRC to find the consensus for the questions that come up, like the topic Bruce is raising in this thread. dt P.S. We still have "the weekly meeting problem" (this is the call on Wednesday evening UTC that Bruce refers to) that has yet to be solved. The transition from the current practice to a new one is not going to be instant and I think we can learn a lot from the experiences of other communities (contrast current OpenStack and Kubernetes practices for example) but in the end I fear we will have to learn these lessons the long way around. -- Dean Troyer dtroyer@gmail.com
Okay, understood. We would get consensus by mailing list and IRC. I am thinking how we make the discussion efficient. For example, probably before kicking off the discussion, we need to create a "story" in which we at least describe what the requirement is about and why we need it. Regards, Yong On 28/06/2018, 9:26 PM, "Dean Troyer" <dtroyer@gmail.com> wrote: On Wed, Jun 27, 2018 at 7:51 PM, Hu, Yong <yong.hu@intel.com> wrote: > Given we have a planning board, what would be the mechanism to vote the > contents (stories) as the targets of monthly release or quarterly release? To be clear, we don't really have a planning board. There is no official governance yet. What we do have is consensus among the two primary groups (Wind River and Intel) involved in the project before the public release to continue our work openly in basically our current fashion until we do have governance. My brain parses that as our mechanism is now to have the discussions here (on the mailing list) and in IRC to find the consensus for the questions that come up, like the topic Bruce is raising in this thread. dt P.S. We still have "the weekly meeting problem" (this is the call on Wednesday evening UTC that Bruce refers to) that has yet to be solved. The transition from the current practice to a new one is not going to be instant and I think we can learn a lot from the experiences of other communities (contrast current OpenStack and Kubernetes practices for example) but in the end I fear we will have to learn these lessons the long way around. -- Dean Troyer dtroyer@gmail.com
On Thu, Jun 28, 2018 at 8:57 AM, Hu, Yong <yong.hu@intel.com> wrote:
For example, probably before kicking off the discussion, we need to create a "story" in which we at least describe what the requirement is about and why we need it.
That is a good idea particularly if it is a large feature. Storyboard, ether pad, wiki are all possibilities to put these, each with advantages and disadvantages.[0] Just posting here is also valid, this list is logged and links to a specific message are easy to get.[1] I personally think etherpad is a great way to start out for brainstorming or notes from an in-person or IRC discussion, particularly when working in near-real-time (design summit/forum sessions are a great example here). Once an idea has solidified moving it to a more permanent and discoverable location is good (wiki, SB, review). Even though etherpad is backed up and they exist "forever" they are intentionally not indexed or discoverable and the history isn't the easiest thing to dig through. There are other ways that suit other people or situations better. dt [0] I've found by experience that large features generate a small-to-modest amount of discussion while we (developers) are capable of bike shedding a small thing to death. [1] start here: http://lists.starlingx.io/pipermail/starlingx-discuss/ -- Dean Troyer dtroyer@gmail.com
participants (3)
-
Dean Troyer
-
Hu, Yong
-
Jones, Bruce E