[openstack-dev] [ptl][release] flushing unreleased client library changes

Thierry Carrez thierry at openstack.org
Tue Sep 8 14:15:18 UTC 2015


Doug Hellmann wrote:
> Excerpts from Ben Swartzlander's message of 2015-09-04 16:54:13 -0400:
>> [...]
>> I would actually want to release a milestone between L-3 and RC1 after 
>> we get to the real Manila FF date but since that's not in line with the 
>> official release process I'm okay waiting for RC1. Since there is no 
>> official process for client releases (that I know about) I'd rather just 
>> wait to do the client until RC1. We'll plan for an early RC1 by 
>> aggressively driving the bugs to zero instead of putting time into 
>> testing the L-3 milestone.
> 
> If master is broken right now, I agree it's not a good idea to
> release.  That said, you still don't want to wait any later than
> you have to. Gate jobs only install libraries from packages, so no
> projects that are co-gating with manila, including manila itself,
> are using the source version of the client library. That means when
> there's a release, the new package introduces all of the new changes
> into the integration tests at the same time.

Yes, that creates unnecessary risk toward the end of the release cycle.
This is why we want to release near-final version of libraries this week
(from which we create the library release/stable branches) -- to keep
risk under control and start testing with the latest code ASAP.

> We want to release clients as often as possible to keep the number
> of changes small. This is why we release Oslo libraries weekly --
> we still break things once in a while, but when we do we have a
> short list of changes to look at to figure out why.
> 
> I'll be proposing that we do a weekly client change review for all
> managed clients starting next cycle, and release when there are changes
> that warrant (probably not just for requirements changes, unless
> it's necessary). I haven't worked out the details of how to do the
> review without me contacting release liaisons directly, so suggestions
> on that are welcome.

+1

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list