Open Stack

That sounds like a sensible way forward, yes.

If the dependency is not need, then great, makes review and merge even easier.

Thanks

On 28 April 2014 17:03, Jay S. Bryant <jsbryant at electronicjungle.net> wrote:
> Duncan,
>
> Thanks for the response.  Have some additional thoughts, in-line, below:
>
>
> On Mon, 2014-04-28 at 12:15 +0100, Duncan Thomas wrote:
>> Two separate patches, or even two chains of separate patches, will
>> make reviewing and more importantly (hopefully temporary) backouts
>> easier. It will also reduce the number of merge conflicts, which are
>> still likely to be substantial.
>
> True, I suppose we need to keep in mind the fact that we might want to
> make this be easy to back-out in the future.  Hopefully it isn't an
> issue this time around though.
>
>> There's no benefit at all to all of this being done in one patch, and
>> substantial costs. Doing the conversion by sections seems like the way
>> forward.
>
> So, let me propose a different process here.  Handling the i18n and
> removal of debug separately instead.  First, propose one patch that will
> add the explicit import of '_' to all files.  There will be a lot of
> files touched, but they all will be 1 liners.  Then make the patch for
> the re-enablement of lazy tanslation a second patch that is dependent
> upon the first patch.
>
> Then handle removal of _() from DEBUG logs as a separate issue once the
> one above has merged.  For that change do it in multiple patches divided
> by section.  Make the sections be the top level directories under
> cinder/ ?  Does that sound like a reasonable plan?
>
>>
>> Doing both around the same time (maybe as dependant patches) seems reasonable
>>
>
> As I think about it, I don't know that the debug translation removal
> needs to be dependent, but we could work it out that way if you feel
> that is important.
>
> Let me know what you think.
>
> Thanks!
>
>> On 27 April 2014 00:20, Jay S. Bryant <jsbryant at electronicjungle.net> wrote:
>> > All,
>> >
>> > I am looking for feedback on how to complete implementation of i18n
>> > support for Cinder.  I need to open a new BluePrint for Juno as soon as
>> > the cinder-specs process is available.  In the mean time I would like to
>> > start working on this and need feedback on the scope I should undertake
>> > with this.
>> >
>> > First, the majority of the code for i18n support went in with Icehouse.
>> > There is just a small change that is needed to actually enable Lazy
>> > Translation again.  I want to get this enabled as soon as possible to
>> > get plenty of runtime on the code for Icehouse.
>> >
>> > The second change is to add an explicit export for '_' to all of our
>> > files to be consistent with other projects. [1]  This is also the safer
>> > way to implement i18n.  My plan is to integrate the change as part of
>> > the i18n work.  Unfortunately this will touch many of the files in
>> > Cinder.
>> >
>> > Given that fact, this brings me to the item I need feedback upon.  It
>> > appears that Nova is moving forward with the plan to remove translation
>> > of debug messages as there was a recent patch submitted to enable a
>> > check for translated DEBUG messages.  Given that fact, would it be an
>> > appropriate time, while adding the explicit import of '_' to also remove
>> > translation of debug messages.  It is going to make the commit for
>> > enabling Lazy Translation much bigger, but it would also take out
>> > several work items that need to be addressed at once.  I am willing to
>> > undertake the effort if I have support for the changes.
>> >
>> > Please let me know your thoughts.
>> >
>> > Thanks!2]
>> > Jay
>> > (jungleboyj on freenode)
>> >
>> > [1] https://bugs.launchpad.net/cinder/+bug/1306275
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Duncan Thomas