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 <thie...@openstack.org>, wrote: >> Renat Akhmerov wrote: >>> On 31 May 2017, 15:08 +0700, Thierry Carrez <thie...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
