<div dir="ltr"><div class="gmail_default" style="font-size:small">+1 from Searchlight since we have only a small number of changes.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks,</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 12, 2018 at 5:07 AM Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Libraries should be released early and often so their consumers can pick up<br>
merged changes, and issues with those changes can be identified close to when<br>
the change is made. To help with this, we are considering forcing at least one<br>
library release per milestone (if there are unreleased merged changes).<br>
<br>
Planned Changes<br>
---------------<br>
<br>
The proposed change would be that for each cycle-with-intermediary library<br>
deliverable, if it was not released during that milestone timeframe, the<br>
release team would automatically generate a release request early in the week<br>
of the milestone deadline. For example, at Stein milestone 1, if the library<br>
was not released at all in the Stein cycle yet, we would trigger a release the<br>
week of the milestone. At Stein milestone 2, if the library was not released<br>
since milestone 1, we would trigger another release, etc.<br>
<br>
That autogenerated patch would be used as a base to communicate with the team:<br>
if a team knows it is not a good time to do a release for that library, someone<br>
from the team can -1 the patch to have it held, or update that patch with a<br>
different commit SHA where they think it would be better to release from. If<br>
there are no issues, ideally we would want a +1 from the PTL and/or release<br>
liaison to indicate approval, but we would also consider no negative feedback<br>
as an indicator that the automatically proposed patches without a -1 can all be<br>
approved on the Thursday milestone deadline.<br>
<br>
Frequently Asked Questions (we're guessing)<br>
-------------------------------------------<br>
<br>
Q: Our team likes to release libraries often. We don't want to wait for each<br>
   milestone. Why are you ruining our lives?<br>
A: Teams are encouraged to request library releases regularly, and at any point<br>
   in time that makes sense. The automatic release patches only serve as a<br>
   safeguard to guarantee that library changes are released and consumed early<br>
   and often, in case no release is actively requested.<br>
<br>
Q: Our library has no change, that's why we are not requesting changes. Why are<br>
   you forcing meaningless releases? You need a hobby.<br>
A: If the library has not had any change merged since the previous tag, we<br>
   would not generate a release patch for it.<br>
<br>
Q: My team is responsible for this library. I don't feel comfortable having an<br>
   autogenerated patch grab a random commit to release. Can we opt out of this?<br>
A: The team can do their own releases when they are ready. If we generate a<br>
   release patch and you don't think you are ready, just -1 the patch. Then<br>
   when you are ready, you can update the patch with the new commit to use.<br>
<br>
<br>
Please ask questions or raise concerns here and/or in the #openstack-release<br>
channel.<br>
<br>
Thanks!<br>
<br>
The Release Management Team<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><b style="font-size:small;color:rgb(51,51,51)">Trinh Nguyen</b><br></div><div><u style="font-size:12.8px;color:rgb(0,0,0)"><a href="https://www.edlab.xyz" target="_blank">www.edlab.xyz</a></u><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>