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 <jsbry...@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 <jsbry...@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@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
