Excerpts from Ian Wienand's message of 2016-04-20 06:25:17 +1000: > On 04/20/2016 03:25 AM, Doug Hellmann wrote: > > It's not just about control, it's also about communication. One of > > the most frequent refrains we hear is "what is OpenStack", and one > > way we're trying to answer that is to publicize all of the things > > we release through releases.openstack.org. > > So for dib, this is mostly about documentation?
This isn't about DIB in particular. The change wasn't made because you were doing anything wrong, or not doing something. It's about not having a bunch of special case exceptions so that all projects work the same way and everyone understands what it means to be part of the official project list. DIB, as an official project, was included in the list of repositories for which I adjusted the ACLs. After discussing it with the release team, we're proposing that we revert the ACL changes for projects using the release:independent model. Those projects are already declaring, through that model, that they are not part of the openstack release cycle, and hence not part of what is being managed by the release team. To that end, I've proposed https://review.openstack.org/308044. I've also proposed updates to the governance tag definitions to document the expectations related to this issue for the release tags: https://review.openstack.org/308045 So, consider what model you want to use. If release:independent works for you, then you can keep tagging when you want, and if you care to advertise those releases you can propose changes to openstack/releases after the fact. If you want a release:cycle-* tag, we'll have to figure out how to incorporate the review step in your release process because project tagged as part of the cycle are very definitely things we're managing as part of the product. That said, another goal of the automation work was to provide a way to have tags reviewed before they were applied, though, so I do expect that some time in the future we will have *all* deliverables for all projects going through the tag review process. That will wait until the automation is completed and we have a larger team of reviewers (it will be easier to add members to the team when it isn't necessary to set up a bunch of tools to run locally). At that point I would expect to have enough folks on the team doing those reviews that there would be no schedule-based reason for a project to be unable to manage its tags that way. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
