On Fri, 2013-09-06 at 10:59 +0200, Thierry Carrez wrote: > Mark McLoughlin wrote: > > I'd like to request a feature freeze exception for the final (and > > admittedly the largest) patch in the series of 40 patches to port Nova > > to oslo.messaging: > > > > https://review.openstack.org/39929 > > I'm generally adverse to granting feature freeze exceptions to code > refactoring: the user benefit of having them in the release is > inexistent, while they introduce some risk by changing deep code > relatively late in the cycle. That's why I prefer those to be targeted > to earlier development milestones, this avoids having to make hard calls > once all the work is done and almost completed.
Yes, absolutely understood. To be clear - while I think there's a strong case for an exception here, I am very close to this, so I would be cool with a denial of this request. > That said, if the risk is under control and the patch is ready to merge, > I'm fine with this as long as there is some other benefits in having it > *in* the release rather than landed first thing in icehouse. > > Would having it *in* the release facilitate stable/havana branch > maintenance, for example ? > > > While this change doesn't provide any immediate user-visible benefit, it > > would be massively helpful in maintaining momentum behind the effort all > > through the Havana cycle to move the RPC code from oslo-incubator into a > > library. > > Could you expand on why this would be a lot more helpful to have it in > the release rather than early in icehouse ? > > And to have all cards on the table, how much sense would the alternative > make (i.e. not land this final patch while a lot of this feature code > has already been merged) ? If the patch was merged now, while it's not a user-visible feature per-se, I think oslo.messaging is something we would celebrate in the Havana release e.g. While OpenStack continues to add new projects and developers while, in parallel, aggressively takes steps to enable the project to scale. The oslo.messaging library added in the Havana release is an example of where code which was previously copied and pasted between projects and has now been re-factored out into a shared library with a clean API. This library will provide a structured way for OpenStack projects to collaborate on adopting new messaging patterns and features without the disruption of incompatible API changes nor the pain of keeping copied and pasted code in sync. Obviously, as Oslo PTL, I think this is an important theme that we should continue to emphasise and build momentum around. The messaging library is by far the most significant example so far of how this process of creating libraries can be effective. Nova using the library in the Havana release would (IMHO) be the signal that this process is working and hopefully inspire others to take a similar approach with other chunks of common code. Conversely, if we delayed merging this code until Icehouse, I think it would leave somewhat of a question mark hanging over oslo.messaging and Oslo going into the summit: Is this oslo.messaging thing for real? Or will it be abandoned and we need to continue with the oslo-incubator RPC code? Why is it taking so long to create these libraries? This sucks! That's all very meta, I know. But I do really believe making progress with Oslo libraries is important for OpenStack long-term. While it's not a user-visible benefit per-se, I do think this work benefits the project broadly and is also something worth marketing. We measure our progress in terms of what we achieved in each release cycle. I think we've made great progress on oslo.messaging in Havana, but unless a project uses it in the release it won't be something we really celebrate until Icehouse. If we agree the risk is manageable, I hope the above shows there is ample benefit in comparison to the risk. Thanks, Mark. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
