Open Stack

Excerpts from Doug Hellmann's message of 2015-06-09 16:08:16 -0400:
> Excerpts from Doug Hellmann's message of 2015-06-09 13:25:26 -0400:
> > 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.
> 
> The change to update the ACLs is https://review.openstack.org/189856
> 
> I would appreciate a review to ensure I've not missed any library-like
> things, and so that all projects understand which repositories this
> affects.

The spec describing a repository and tools for starting to automate tag
reviewing is in gerrit at https://review.openstack.org/#/c/191193/

If you have any interest in library releases, please review and comment
on the spec.

Doug