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. > > Doug >
The ACLs change has landed, and the new library-release team is set up including the Release Managers group, along with dims and lifeless, who volunteered to join the new team. https://review.openstack.org/#/admin/groups/967,members Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
