Libraries should be released early and often so their consumers can pick up merged changes, and issues with those changes can be identified close to when the change is made. To help with this, we are considering forcing at least one library release per milestone (if there are unreleased merged changes).
Planned Changes --------------- The proposed change would be that for each cycle-with-intermediary library deliverable, if it was not released during that milestone timeframe, the release team would automatically generate a release request early in the week of the milestone deadline. For example, at Stein milestone 1, if the library was not released at all in the Stein cycle yet, we would trigger a release the week of the milestone. At Stein milestone 2, if the library was not released since milestone 1, we would trigger another release, etc. That autogenerated patch would be used as a base to communicate with the team: if a team knows it is not a good time to do a release for that library, someone from the team can -1 the patch to have it held, or update that patch with a different commit SHA where they think it would be better to release from. 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 on the Thursday milestone deadline. Frequently Asked Questions (we're guessing) ------------------------------------------- Q: Our team likes to release libraries often. We don't want to wait for each milestone. Why are you ruining our lives? A: Teams are encouraged to request library releases regularly, and at any point in time that makes sense. The automatic release patches only serve as a safeguard to guarantee that library changes are released and consumed early and often, in case no release is actively requested. Q: Our library has no change, that's why we are not requesting changes. Why are you forcing meaningless releases? You need a hobby. A: If the library has not had any change merged since the previous tag, we would not generate a release patch for it. Q: My team is responsible for this library. I don't feel comfortable having an autogenerated patch grab a random commit to release. Can we opt out of this? A: The team can do their own releases when they are ready. If we generate a release patch and you don't think you are ready, just -1 the patch. Then when you are ready, you can update the patch with the new commit to use. Please ask questions or raise concerns here and/or in the #openstack-release channel. Thanks! The Release Management Team __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
