This is a follow up to a dev ML email [1] where I noticed that some
implementations of the upgrade-checkers goal were failing because some
projects still use the oslo_i18n.enable_lazy() hook for lazy log message
translation (and maybe API responses?).
The very old blueprints related to this
Matt Riedemann writes:
> On 11/5/2018 1:36 PM, Doug Hellmann wrote:
>> I think the lazy stuff was all about the API responses. The log
>> translations worked a completely different way.
>
> Yeah maybe. And if so, I came across this in one of the blueprints:
>
>
Matt Riedemann writes:
> This is a follow up to a dev ML email [1] where I noticed that some
> implementations of the upgrade-checkers goal were failing because some
> projects still use the oslo_i18n.enable_lazy() hook for lazy log message
> translation (and maybe API responses?).
>
> The
On 11/5/2018 1:36 PM, Doug Hellmann wrote:
I think the lazy stuff was all about the API responses. The log
translations worked a completely different way.
Yeah maybe. And if so, I came across this in one of the blueprints:
https://etherpad.openstack.org/p/disable-lazy-translation
Which says
Hi all,
Time is running out for you to have your say in the T release name
poll. We have just under 3 days left. If you haven't voted please do!
On Tue, Oct 30, 2018 at 04:40:25PM +1100, Tony Breeds wrote:
> Hi folks,
>
> It is time again to cast your vote for the naming of the T Release.
I'm interested in some feedback from the community, particularly those running
OpenStack deployments, as to whether FIPS compliance [0][1] is something folks
are looking for.
I've been seeing small changes starting to be proposed here and there for
things like MD5 usage related to its
