Open Stack

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.

Doug