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

[Trinh Nguyen]

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

Thanks,

On Fri, Oct 12, 2018 at 5:07 AM Sean McGinnis  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 *
__
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

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

[Sean McGinnis]

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