Thanks for the input Duncan. The removal of the debug logs is really a separate issue. I was just hoping to reduce the number of patches that would touch a large number of files. As we are thinking through this though, it really is a separate change so it is best to do separate patches.
On a related note, we shouldn't be taking changes that have debug messages translated if we are moving forward with removing translation of debug messages. Jay On Thu, 2014-05-01 at 16:41 +0100, Duncan Thomas wrote: > 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 <[email protected]> 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 <[email protected]> > >> 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 > >> > [email protected] > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
