[openstack-dev] [ptl][release] Proposed changes for library releases

Trinh Nguyen dangtrinhnt at gmail.com
Fri Oct 12 02:26:11 UTC 2018

+1 from Searchlight since we have only a small number of changes.


On Fri, Oct 12, 2018 at 5:07 AM Sean McGinnis <sean.mcginnis at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181012/2037d187/attachment.html>

More information about the OpenStack-dev mailing list