[Starlingx-discuss] CENGN Build Aging
All, The build team has been discussing the frequency of the build and how long they are maintained on the Mirror. Our initial ideas are capture here: https://wiki.openstack.org/wiki/StarlingX/Build/EventBuildCadence This captures the initial view of the team. We can evolve this as we get clear direction from the Release team and the community as whole. Comments welcome. Regards, Ken Y
This looks entirely sensible to me. Very well done, thanks Ken & team! brucej From: Young, Ken [mailto:Ken.Young@windriver.com] Sent: Friday, January 4, 2019 10:57 AM To: starlingx <starlingx-discuss@lists.starlingx.io> Subject: [Starlingx-discuss] CENGN Build Aging All, The build team has been discussing the frequency of the build and how long they are maintained on the Mirror. Our initial ideas are capture here: https://wiki.openstack.org/wiki/StarlingX/Build/EventBuildCadence This captures the initial view of the team. We can evolve this as we get clear direction from the Release team and the community as whole. Comments welcome. Regards, Ken Y
On Fri, Jan 4, 2019 at 12:57 PM Young, Ken <Ken.Young@windriver.com> wrote:
The build team has been discussing the frequency of the build and how long they are maintained on the Mirror. Our initial ideas are capture here:
I think that generally looks good, thanks! One clarification I have is with the release point builds. Do I read that right that if we have a 2019.05.1 release and then do a .2 the .1 would go away immediately? As a user I would want to be able to get to my older install if I need to re-create a deployment. As a smart user I would have a local copy but I'm not always a smart user :) It is only because these are the releases we expect people to actually use and depend on that I think we need to be really conservative about removing them. Think about our experiences with binary RPMs being replaced but we still want a specific version. This feels like the same issue only at a higher layer. dt -- Dean Troyer dtroyer@gmail.com
See inline. On 2019-01-07, 5:41 PM, "Dean Troyer" <dtroyer@gmail.com> wrote: On Fri, Jan 4, 2019 at 12:57 PM Young, Ken <Ken.Young@windriver.com> wrote: > The build team has been discussing the frequency of the build and how long they are maintained on the Mirror. Our initial ideas are capture here: I think that generally looks good, thanks! One clarification I have is with the release point builds. Do I read that right that if we have a 2019.05.1 release and then do a .2 the .1 would go away immediately? As a user I would want to be able to get to my older install if I need to re-create a deployment. As a smart user I would have a local copy but I'm not always a smart user :) It is only because these are the releases we expect people to actually use and depend on that I think we need to be really conservative about removing them. Think about our experiences with binary RPMs being replaced but we still want a specific version. This feels like the same issue only at a higher layer. That is not the intent. Maybe I can make that clearer in the slides. What I meant to say is that both loads are available at the same point in the timeline. I could expose that as two lines both sitting in the same position. Both loads are available until that *release* ages out. dt -- Dean Troyer dtroyer@gmail.com
On Mon, Jan 7, 2019 at 6:49 PM Young, Ken <Ken.Young@windriver.com> wrote:
That is not the intent. Maybe I can make that clearer in the slides. What I meant to say is that both loads are available at the same point in the timeline. I could expose that as two lines both sitting in the same position. Both loads are available until that *release* ages out.
Good deal, thanks for the clarification dt -- Dean Troyer dtroyer@gmail.com
participants (3)
-
Dean Troyer
-
Jones, Bruce E
-
Young, Ken