<p dir="ltr">I volunteer for the team.</p>
<div class="gmail_quote">On 10 Jun 2015 5:25 am, "Doug Hellmann" <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Until now we have encouraged project teams to prepare their own<br>
library releases as new versions of projects were needed. We've<br>
started running into a couple of problems with that, with releases<br>
not coming often enough, or at a bad time in the release cycle, or<br>
with version numbering not being applied consistently, or without<br>
proper announcements. To address these issues, the release management<br>
team is proposing to create a small team of library release managers<br>
to handle the process around all library releases (clients,<br>
non-application projects, middleware, Oslo libraries, etc.). This<br>
will give us a chance to collaborate and review the version numbers<br>
for new releases, as well as stay on top of "stale" libraries with<br>
fixes or features that sit unreleased for a period of time. It will<br>
also be the first step to creating an automated review process for<br>
release tags.<br>
<br>
The process still needs to be worked out, but I envision it working<br>
something like this:<br>
<br>
The release liaison/PTL for the project team submits a request for<br>
a new release, including the repo name, the SHA, the series (liberty,<br>
kilo, etc.), and the proposed version number. The release team<br>
checks the proposed version number against the unreleased changes<br>
up to that SHA, and then either updates it to reflect semver or<br>
uses it as it is provided. The release team would then handle the<br>
tag push and the resulting announcements.<br>
<br>
There would be a few conditions under which a new release might not<br>
be immediately approved, but really only when the gate is wedged<br>
and during freeze periods. The point of the change isn't to block<br>
releases, just ensure consistency and good timing.<br>
<br>
We have some tools to let us look for unreleased changes, and<br>
eventually we can set up a recurring job to build that report so<br>
we can propose releases to project teams with a large release<br>
backlog. That will likely come later, though.<br>
<br>
We can also pre-announce proposed releases if folks find that useful.<br>
<br>
We will need a small number of volunteers to join this team, and<br>
start building the required expertise in understanding the overall<br>
state of the project, and in semantic versioning. We do not necessarily<br>
want a liaison from every project -- think of this as the proto-team<br>
for the group that eventually has core reviewer rights on the release<br>
automation repository.<br>
<br>
Doug<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>