Open Stack

We have a weekly meeting next Monday, will it be too late?

Renat Akhmerov
@Nokia

On 1 Jun 2017, 20:10 +0700, Thierry Carrez <thierry at openstack.org>, wrote:
> Note that it's technically too late to change the release model
> (milestone-1 is the deadline), but since that kills two birds with one
> stone, I'd be willing to grant mistral an exception (as long as it's
> done before milestone-2, which is next week).
>
> Renat Akhmerov wrote:
> > Thanks Thierry.
> >
> > To me it sounds like even a better release model for us. We can discuss
> > it with a team at the next team meeting and make a decision.
> >
> > Renat Akhmerov
> > @Nokia
> >
> > On 1 Jun 2017, 17:06 +0700, Thierry Carrez <thierry at openstack.org>, wrote:
> > > Renat Akhmerov wrote:
> > > > On 31 May 2017, 15:08 +0700, Thierry Carrez <thierry at openstack.org>,
> > > > wrote:
> > > > > > [mistral]
> > > > > > mistral - blocking sqlalchemy - milestones
> > > > >
> > > > > I wonder why mistral is in requirements. Looks like tripleo-common is
> > > > > depending on it ? Could someone shine some light on this ? It might just
> > > > > mean mistral-lib is missing a few functions, and switching the release
> > > > > model of mistral itself might be overkill ?
> > > >
> > > > This dependency is currently needed to create custom Mistral actions. It
> > > > was originally not the best architecture and one of the reasons to
> > > > create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by
> > > > moving all that’s needed for creating actions into a lib (plus something
> > > > else). The thing is that the transition is not over and APIs that we put
> > > > into ‘mistral-lib’ are still experimental. The plan is to complete this
> > > > initiative, including docs and needed refactoring, till the end of Pike.
> > > >
> > > > What possible negative consequences may we have if we switch release
> > > > model to "cycle-with-intermediary”?
> > >
> > > There are no "negative" consequences. There are just consequences in
> > > choosing a new release model, so I don't want mistral to switch to that
> > > model *only* because it didn't complete moving some code out of mistral
> > > proper into a more consumable mistral-lib. It feels like we wouldn't be
> > > having that discussion if the code was more adequately split :)
> > >
> > > First, the cycle-with-intermediary model means that every tag is a
> > > "release", which is expected to be consumed by users. You have to be
> > > pretty sure that it works -- there won't be any release candidates to
> > > protect you. This means your automated testing coverage needs to be
> > > pretty good.
> > >
> > > Second, the cycle-with-intermediary model is less "driven" by the
> > > release team -- you won't have as many reminders (like milestones), or
> > > best-practice deadlines (like feature freeze) to help you. Your team is
> > > basically doing release management internally, deciding when to release,
> > > when to slow down, etc.
> > >
> > > As such, this model appeals either to very young projects (which need a
> > > lot of flexibility and need to put things out fast), and very mature
> > > projects (where automated testing coverage is pretty complete, release
> > > liaisons take up much of the release management, and things don't change
> > > that often). Projects in the middle usually prefer the
> > > cycle-with-milestones model.
> > >
> > > > Practically, all our releases, even
> > > > those made after milestones, are considered stable and I don’t see
> > > > issues if we’ll be producing full releases every time.
> > >
> > > Yes, it sounds like you could switch to that model without too much pain.
> > >
> > > > Btw, how does
> > > > stable branch maintenance work in this case? I guess it should be the
> > > > same, one stable branch per cycle. I’d appreciate if you could
> > > > clarify this.
> > >
> > > There is no change in terms of stable releases, you still maintain only
> > > one branch per cycle. The last intermediary release in a given cycle is
> > > where the stable branch for the cycle is cut.
> > >
> > > --
> > > Thierry Carrez (ttx)
> > >
> > > __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Thierry Carrez (ttx)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170601/2d111fb3/attachment.html>