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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
