Open Stack

On Tue, Apr 19, 2016, at 01:25 PM, Ian Wienand wrote:
> 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

I think I have a handle on the different release tags after some reading
/ IRC chat, and AIUI - as long as DIB is an official project then in the
current system it's releases will be going through the release team.
Therefore, the discussion about release tag type isn't really relevant
to the concerns we seem to be bringing up which mostly center around us
worrying over the new step required to get a release out - there doesn't
exist a tag which will change this.

My concern with this extra step is mostly wondering what the practical
benefit to us is? Obviously there is some complexity being added to us
getting out a release, and were also involving a whole new team of folks
in doing this, so I think this absolutely warrants some benefit over the
existing system to us. There's a couple obvious things (having releases
go through review rather than just git push is extremely nice), but IMO
this doesn't outweigh the downsides of adding an additional review team.
I also feel like this is an issue we could solve while still allowing us
to retain release control.


So, a couple questions:

* Is there disagreement with the sentiment that adding the extra
releases review team to our release process is not desirable for DIB? I
am really wondering if there's some practical benefit here we might be
missing...

* Are there some benefits inherent to the extra releases review team
that we are missing and outweigh the benefits of the added process? I
want to make sure to distinguish between things (like gerrit perms with
our existing setup) which we could work with the releases team to fix,
and things that we can't. 

Thanks,
Greg