Open Stack

I volunteer for the team.
On 10 Jun 2015 5:25 am, "Doug Hellmann" <doug at doughellmann.com> wrote:

> Until now we have encouraged project teams to prepare their own
> library releases as new versions of projects were needed. We've
> started running into a couple of problems with that, with releases
> not coming often enough, or at a bad time in the release cycle, or
> with version numbering not being applied consistently, or without
> proper announcements. To address these issues, the release management
> team is proposing to create a small team of library release managers
> to handle the process around all library releases (clients,
> non-application projects, middleware, Oslo libraries, etc.). This
> will give us a chance to collaborate and review the version numbers
> for new releases, as well as stay on top of "stale" libraries with
> fixes or features that sit unreleased for a period of time. It will
> also be the first step to creating an automated review process for
> release tags.
>
> The process still needs to be worked out, but I envision it working
> something like this:
>
> The release liaison/PTL for the project team submits a request for
> a new release, including the repo name, the SHA, the series (liberty,
> kilo, etc.), and the proposed version number. The release team
> checks the proposed version number against the unreleased changes
> up to that SHA, and then either updates it to reflect semver or
> uses it as it is provided. The release team would then handle the
> tag push and the resulting announcements.
>
> There would be a few conditions under which a new release might not
> be immediately approved, but really only when the gate is wedged
> and during freeze periods. The point of the change isn't to block
> releases, just ensure consistency and good timing.
>
> We have some tools to let us look for unreleased changes, and
> eventually we can set up a recurring job to build that report so
> we can propose releases to project teams with a large release
> backlog. That will likely come later, though.
>
> We can also pre-announce proposed releases if folks find that useful.
>
> We will need a small number of volunteers to join this team, and
> start building the required expertise in understanding the overall
> state of the project, and in semantic versioning. We do not necessarily
> want a liaison from every project -- think of this as the proto-team
> for the group that eventually has core reviewer rights on the release
> automation repository.
>
> Doug
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150610/457805c6/attachment.html>