Hello operators!
I'm trying to reach out to more folks that this might impact. There are nitty
gritty details below, but to summarize - the release team is looking at
changing the way we currently do releases for the main service projects. So
far, we have been doing three milestone releases throughout a development
cycle, one or more release candidates, then the final release for the cycle.
From what we could tell, these milestone releases were really not being used by
anyone (mostly) so to a degree, they were just busy work that we were imposing
on the project teams.
We are thinking of changing the release model to get rid of the milestones and
just do the release candidates as we finalize the release. Those can be
considered close to done for the purposes of those wanting to get an early
start on testing deployments and doing any kind of packaging.
The only problem we've seen is without the milestone releases during the cycle,
there is quite a gap before the version numbers get incremented for anyone
doing more frequent testing. We wanted to reach out the operator community
since I know there are at least a few of you that do "roll your own" for
deploying upstream code.
If anyone knows this change would have a negative impact for you, please do let
us know so we can take that into consideration or can make any tweaks to our
plans. We want to reduce work put on the teams, but we don't want to do that at
the expense of preventing others from being able to get their work done.
Thanks!
Sean
----- Forwarded message from Sean McGinnis <sean.mcginnis@gmx.com> -----
Date: Wed, 26 Sep 2018 09:22:30 -0500
From: Sean McGinnis <sean.mcginnis@gmx.com>
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
During the Stein PTG in Denver, the release management team talked about ways
we can make things simpler and reduce the "paper pushing" work that all teams
need to do right now. One topic that came up was the usefulness of pushing tags
around milestones during the cycle.
There were a couple of needs identified for doing such "milestone releases":
1) It tests the release automation machinery to identify problems before
the RC and final release crunch time.
2) It creates a nice cadence throughout the cycle to help teams stay on
track and focus on the right things for each phase of the cycle.
3) It gives us an indication that teams are healthy, active, and planning
to include their components in the final release.
One of the big motivators in the past was also to have output that downstream
distros and users could pick up for testing and early packaging. Based on our
admittedly anecdotal small sample, it doesn't appear this is actually a big
need, so we propose to stop tagging milestone releases for the
cycle-with-milestone projects.
We would still have "milestones" during the cycle to facilitate work
organization and create a cadence: teams should still be aware of them, and we
will continue to communicate those dates in the schedule and in the release
countdown emails. But you would no longer be required to request a release for
each milestone.
Beta releases would be optional: if teams do want to have some beta version
tags before the final release they can still request them - whether on one of
the milestone dates, or whenever there is the need for the project.
Release candidates would still require a tag. To facilitate that step and
guarantee we have a release candidate for every deliverable, the release team
proposes to automatically generate a release request early in the week of the
RC deadline. That patch would be used as a base to communicate with the team:
if a team wants to wait for a specific patch to make it to the RC, someone from
the team can -1 the patch to have it held, or update that patch with a
different commit SHA. If there are no issues, ideally we would want a +1 from
the PTL and/or release liaison to indicate approval, but we would also consider
no negative feedback as an indicator that the automatically proposed patches
without a -1 can all be approved at the end of the RC deadline week.
To cover point (3) above, and clearly know that a project is healthy and should
be included in the coordinated release, we are thinking of requiring a person
for each team to add their name to a "manifest" of sorts for the release cycle.
That "final release liaison" person would be the designated person to follow
through on finishing out the releases for that team, and would be designated
ahead of the final release phases.
With all these changes, we would rename the cycle-with-milestones release
model to something like cycle-with-rc.
FAQ:
Q: Does this mean I don't need to pay attention to releases any more and the
release team will just take care of everything?
A: No. We still want teams engaged in the release cycle and would feel much
more comfortable if we get an explicit +1 from the team on any proposed tags
or releases.
Q: Who should sign up to be the final release liaison ?
A: Anyone in the team really. Could be the PTL, the standing release liaison,
or someone else stepping up to cover that role.
--
Thanks!
The Release Team
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
----- End forwarded message -----
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
I'm trying to reach out to more folks that this might impact. There are nitty
gritty details below, but to summarize - the release team is looking at
changing the way we currently do releases for the main service projects. So
far, we have been doing three milestone releases throughout a development
cycle, one or more release candidates, then the final release for the cycle.
From what we could tell, these milestone releases were really not being used by
anyone (mostly) so to a degree, they were just busy work that we were imposing
on the project teams.
We are thinking of changing the release model to get rid of the milestones and
just do the release candidates as we finalize the release. Those can be
considered close to done for the purposes of those wanting to get an early
start on testing deployments and doing any kind of packaging.
The only problem we've seen is without the milestone releases during the cycle,
there is quite a gap before the version numbers get incremented for anyone
doing more frequent testing. We wanted to reach out the operator community
since I know there are at least a few of you that do "roll your own" for
deploying upstream code.
If anyone knows this change would have a negative impact for you, please do let
us know so we can take that into consideration or can make any tweaks to our
plans. We want to reduce work put on the teams, but we don't want to do that at
the expense of preventing others from being able to get their work done.
Thanks!
Sean
----- Forwarded message from Sean McGinnis <sean.mcginnis@gmx.com> -----
Date: Wed, 26 Sep 2018 09:22:30 -0500
From: Sean McGinnis <sean.mcginnis@gmx.com>
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
During the Stein PTG in Denver, the release management team talked about ways
we can make things simpler and reduce the "paper pushing" work that all teams
need to do right now. One topic that came up was the usefulness of pushing tags
around milestones during the cycle.
There were a couple of needs identified for doing such "milestone releases":
1) It tests the release automation machinery to identify problems before
the RC and final release crunch time.
2) It creates a nice cadence throughout the cycle to help teams stay on
track and focus on the right things for each phase of the cycle.
3) It gives us an indication that teams are healthy, active, and planning
to include their components in the final release.
One of the big motivators in the past was also to have output that downstream
distros and users could pick up for testing and early packaging. Based on our
admittedly anecdotal small sample, it doesn't appear this is actually a big
need, so we propose to stop tagging milestone releases for the
cycle-with-milestone projects.
We would still have "milestones" during the cycle to facilitate work
organization and create a cadence: teams should still be aware of them, and we
will continue to communicate those dates in the schedule and in the release
countdown emails. But you would no longer be required to request a release for
each milestone.
Beta releases would be optional: if teams do want to have some beta version
tags before the final release they can still request them - whether on one of
the milestone dates, or whenever there is the need for the project.
Release candidates would still require a tag. To facilitate that step and
guarantee we have a release candidate for every deliverable, the release team
proposes to automatically generate a release request early in the week of the
RC deadline. That patch would be used as a base to communicate with the team:
if a team wants to wait for a specific patch to make it to the RC, someone from
the team can -1 the patch to have it held, or update that patch with a
different commit SHA. If there are no issues, ideally we would want a +1 from
the PTL and/or release liaison to indicate approval, but we would also consider
no negative feedback as an indicator that the automatically proposed patches
without a -1 can all be approved at the end of the RC deadline week.
To cover point (3) above, and clearly know that a project is healthy and should
be included in the coordinated release, we are thinking of requiring a person
for each team to add their name to a "manifest" of sorts for the release cycle.
That "final release liaison" person would be the designated person to follow
through on finishing out the releases for that team, and would be designated
ahead of the final release phases.
With all these changes, we would rename the cycle-with-milestones release
model to something like cycle-with-rc.
FAQ:
Q: Does this mean I don't need to pay attention to releases any more and the
release team will just take care of everything?
A: No. We still want teams engaged in the release cycle and would feel much
more comfortable if we get an explicit +1 from the team on any proposed tags
or releases.
Q: Who should sign up to be the final release liaison ?
A: Anyone in the team really. Could be the PTL, the standing release liaison,
or someone else stepping up to cover that role.
--
Thanks!
The Release Team
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
----- End forwarded message -----
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators