Excerpts from Jeremy Stanley's message of 2016-07-01 13:50:30 +0000: > On 2016-07-01 11:24:27 +0200 (+0200), Thierry Carrez wrote: > > Short answer is: release:managed doesn't mean that much anymore (all > > official projects are "managed"), so we'll likely retire it ASAP. > [...] > > If the meaning has been reduced to "this project is allowed to > request tagging by the Release Management team" then I agree it's no > longer necessary since any official project _can_ do that. If the > meaning is "this project is _only_ allowed to be tagged by the > Release Management team" then I can still see some use for it, since > there are plenty of official projects that currently follow their > own independent release process and push their own tags instead.
I've been telling folks throughout this cycle that we weren't going to add the "managed" tag to any new projects because we were considering redefining the tag and we would want to do that first. While discussing how to redefine it, we realized its meaning is now covered by other tags, so we've proposed to drop it instead [1]. The "release:managed" tag used to convey information about how much the release team did for the project team in a way that was (we hoped) useful to consumers of the project. That included things we no longer do at all for anyone, like update bug milestones and upload artifacts to launchpad, as well as things that are now encoded in the other release tags like "perform the tagging of the release". At the start of this cycle we updated the gerrit ACLs so that all projects using a cycle-with* release model *must* have the release team process their releases (if we have any such projects who we missed, or who were added later and not updated, we need to fix that). Projects using the independent release model may process their own releases or may ask the release team to do it. Either way, since those projects are by definition not part of the cycle releases we don't consider it "interesting" to their consumers to say who is actually doing the releases (feedback on that assumption is of course welcome). Doug [1] https://review.openstack.org/#/c/335440/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
