Open Stack

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