Open Stack

Excerpts from Ben Swartzlander's message of 2015-09-04 16:54:13 -0400:
> 
> On 09/04/2015 03:21 PM, Doug Hellmann wrote:
> > Excerpts from Ben Swartzlander's message of 2015-09-04 14:51:10 -0400:
> >> On 09/04/2015 12:39 PM, Doug Hellmann wrote:
> >>> PTLs,
> >>>
> >>> We have quite a few unreleased client changes pending, and it would
> >>> be good to go ahead and publish them so they can be tested as part
> >>> of the release candidate process. I have the full list of changes for
> >>> each project below, so please find yours and review them and then
> >>> propose a release request to the openstack/releases repository.
> >> Manila had multiple gate-breaking bugs this week and I've extended our
> >> feature freeze to next Tuesday to compensate. As a result our L-3
> >> milestone release is not really representative of Liberty and we'd
> >> rather not do a client release until we reach RC1.
> > Keep in mind that the unreleased changes are not being used to test
> > anything at all in the gate, so there's an integration "penalty" for
> > delaying releases. You can have as many releases as you want, and we can
> > create the stable branch from the last useful release any time after it
> > is created. So, I still recommend releasing early and often unless you
> > anticipate making API or CLI breaking changes between now and RC1.
> 
> There is currently an API breaking change that needs to be fixed. It 
> will be fixed before the RC so that Kilo<->Liberty upgrades go smoothly 
> but the L-3 milestone is broken regarding forward and backward 
> compatibility.
> 
> https://bugs.launchpad.net/manila/+bug/1488624
> 
> 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.

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.

Doug