Open Stack

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?

We don't have the issues around stable branches mentioned in the
readme, nor do we worry about the requirements/constraints (proposal
bot has always been sufficient?).

> Centralizing tagging also helps us ensure consistent versioning
> rules, good timing, good release announcements, etc.

We so far haven't had issues keeping the version number straight.

As mentioned, the timing has extra constraints due to use in periodic
infra jobs that I don't think the release team want to be involved
with.  It's not like the release team will be going through the
changes in a new release and deciding if they seem OK or not (although
they're welcome to do dib reviews, before things get committed :) So I
don't see what timing constraints will be monitored in this case.

When you look at this from my point of view, dib was left/is in an
unreleasable state that I've had to clean up [1], we've now missed yet
another day's build [2] and I'm not sure what's different except I now
have to add probably 2 days latency to the process of getting fixes
out there.

To try and be constructive : is what we want a proposal-bot job that
polls for the latest release and adds it to the diskimage-builder.yaml
file?  That seems to cover the documentation component of this.

Or, if you want to give diskimage-builder-release group permissions on
the repo, so we can +2 changes on the diskimage-builder.yaml file, we
could do that. [3]

-i

[1] https://review.openstack.org/#/c/306925/
[2] https://review.openstack.org/#/c/307542/
[3] my actual expectation of this happening is about zero