Open Stack

+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.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>