+1 from Searchlight since we have only a small number of changes. Thanks,
On Fri, Oct 12, 2018 at 5:07 AM Sean McGinnis <sean.mcgin...@gmx.com> wrote: > 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 > -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*
__________________________________________________________________________ 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
