Re: [openstack-dev] (re)centralizing library release management
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] (re)centralizing library release management
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 __ 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
Re: [openstack-dev] (re)centralizing library release management
On 06/09/2015 01:25 PM, Doug Hellmann 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 While I haven't participated in release management before, I'd like to volunteer my services to help. Where is the best place (IRC) to collaborate? PB __ 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
Re: [openstack-dev] (re)centralizing library release management
Paul Belanger wrote: While I haven't participated in release management before, I'd like to volunteer my services to help. Where is the best place (IRC) to collaborate? I would encourage prospective release managers to join #openstack-relmgr-office where Doug and I discuss that sort of things, and (if timing allows) attend the release team meeting, or read the logs afterwards if you can't attend. It's currently set to a EU-friendly Monday 1300 UTC. Thanks, -- Thierry Carrez (ttx) __ 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
[openstack-dev] (re)centralizing library release management
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] (re)centralizing library release management
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
