I volunteer for the team. On 10 Jun 2015 5:25 am, "Doug Hellmann" <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
