21:00:45 <ttx> #startmeeting
21:00:46 <openstack> Meeting started Tue Nov 30 21:00:45 2010 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:00:50 <romohr> hello
21:00:53 <ttx> Welcome to our weekly OpenStack team meeting...
21:01:00 <ttx> Today's agenda is at: http://wiki.openstack.org/Meetings
21:01:10 * ttx checks for late additions to the agenda...
21:01:28 <ttx> #topic Actions from previous meeting
21:01:43 <ttx> * ttx to start a ML thread about LP bug statuses: done
21:01:50 <ttx> * dendrobates to merge (or delegate merging of) the MLs, keep the archives
21:02:06 <ttx> dendrobates: in progress ?
21:02:09 <dendrobates> not doen yer
21:02:18 <dendrobates> not done yet
21:02:24 <dendrobates> blame thanksgiving
21:02:34 <dendrobates> In process.
21:02:38 <ttx> ok, pushing back to next week then
21:02:42 <creiht> dendrobates: too much vegitarian turkey?
21:02:45 <creiht> :)
21:02:47 <ttx> #action dendrobates to merge (or delegate merging of) the MLs, keep the archives
21:02:57 <dendrobates> creiht: actually yes
21:03:02 <zul> ewww
21:03:08 <ttx> #topic Current release stage: Implementation
21:03:24 <ttx> So you should still be busy writing code, reviewing proposed branches, and pinging dendrobates so that he approves your design :)
21:03:40 <ttx> #info For bonus points, you can update the "Implementation" status of your blueprints following the definitions at http://wiki.openstack.org/BlueprintsLifecycle
21:04:10 <ttx> Started / Slow progress / Good progress / Blocked...
21:04:32 <ttx> #topic Release status
21:04:40 <ttx> We have a Bexar list for Glance, available at:
21:04:51 <ttx> #link https://blueprints.launchpad.net/glance/bexar
21:05:10 <ttx> Status looks good, with teller-api (essential) on track for delivery in bexar...
21:05:18 <ttx> jaypipes isn't around ?
21:05:59 <ttx> dendrobates is still working on the Nova and Swift lists, I hope we can have them this week, once he is done with the CLA stuff.
21:06:11 <dendrobates> ttx: there will still be changes to the priorities
21:06:34 <ttx> The idea being, we track progress on the blueprints that are targeted to the release, especially the "essential" ones.
21:06:56 <ttx> dendrobates: ok, let me know if I can help you in cleaning up the lists
21:07:02 <dendrobates> k
21:07:11 <ttx> Any other comments ?
21:07:32 <dendrobates> make sure dependancies are in your bps
21:07:34 <ttx> Like your work is blocked by someone else's spec not progressing ?
21:08:04 <dendrobates> correct dependencies help us set priority
21:08:27 <dendrobates> and I encourage everyone to link a branch to your bp as well
21:08:40 <dendrobates> not required, but appreciated
21:08:52 <ttx> creiht/dendrobates: should we use "1.2" as synonymous to "Bexar" for swift ?
21:09:03 <creiht> Yes
21:09:54 <ttx> OK. I plan to generate combined release BP lists using the LP blueprint APi, when it's available
21:10:04 <Daviey> lol
21:10:14 <ttx> so that we can have "bexar openstack specs" lists
21:10:23 <Daviey> "when available"
21:10:33 <ttx> (currently that's not possible at project group level)
21:10:43 <ttx> Daviey: it's planned for LP 10.12.
21:10:56 <ttx> Dec 8.
21:11:03 <Daviey> Ooo
21:11:20 <ttx> Daviey: told you christmas was early this year.
21:11:26 <ttx> #topic LP Bugs fields, redux
21:11:32 <ttx> So I started a discussion on the mailing-list, and just wrote a draft at:
21:11:40 <ttx> #link http://wiki.openstack.org/BugsLifecycle
21:11:51 <ttx> #info Please review it and comment on the ML thread.
21:12:03 <ttx> Executive summary: Two opiniated choices were made in this draft
21:12:16 <ttx> (1) "Fix Committed" means in trunk, "Fix Released" means in release
21:12:29 <ttx> (2) "Confirmed" means reproduced and importance set, "Triaged" means debugged with a documented solution
21:12:40 <ttx> (1) was rather consensual, but (2) was still very much discussed.
21:12:57 <ttx> I think the current proposal maps better to our workflow, but feel free to convince me otherwise.
21:13:19 <ttx> Questions ?
21:14:07 <ttx> #topic i18n - adding coding standards (tpatil)
21:14:15 <annegentle> so non-programmers can confirm but not really triage bugs? (Just clarifying)
21:14:15 <Tushar> hi
21:14:17 <Tushar> We are working on i18n changes for bexar release
21:14:20 <alekibango> i have foun dsome i18n bugs
21:14:26 <Tushar> To support i18n, we would need to change all hard coded log messages
21:14:41 <alekibango> i will try to send patches tonight or tomorrow
21:14:43 <Tushar> for e.g. from logging.debug("instance %s: is running", instance['name'])
21:14:49 <Tushar> to logging.debug(_("instance %s: is running"), instance['name'])
21:14:59 <ttx> annegentle: depending on their technical knowledge, they could debug and explain the solution
21:15:07 <ttx> annegentle: (without coding)
21:15:08 <annegentle> ttx: ok, thanks
21:15:12 <alekibango> i mean, i have found some things not working properly when you have czech locales configured
21:15:26 <dendrobates> Tushar: are we using Launchpad to do the manage the translations?
21:15:38 <Tushar> yes,
21:15:53 <Tushar> but I haven't worked on this before..
21:16:06 <Tushar> we are still understanding launchpad trnslation process.
21:16:06 <xtoddx> Tushar: there may be a way to automatically call _() on log messages with the nova/log.py that is in lp:~xtoddx/nova/newlog
21:17:13 <annegentle> dendrobates: does someone need to set up Launchpad to enable translation management? We looked at the Summit but I think there's a config step.
21:17:24 <soren> There might be. Let me have a look.
21:17:25 <xtoddx> Tushar: I hadn't thought about it until now, but I'm sure we can automatically translate log strings, perhaps when hey go into the formatter
21:17:46 <dendrobates> annegentle: I'll look into it.
21:17:47 <jaypipes> annegentle: you can ask mtaylor for help on that...he knows how it works.
21:17:55 <xtoddx> i'll look over it late tonight and see if I come up with anything.  that would be the easiest change
21:18:38 <Tushar> Ok, thanks
21:18:55 <Tushar> another point is to induce the coding standard for i18n changes..
21:19:10 <Tushar> where should we specify the coding standard?
21:19:34 <xtoddx> Tushar: maybe you could write something up in the HACKING file in the root directory?
21:19:39 <jaypipes> xtoddx: no, you would use gettext around the message string in the source file.
21:19:48 <Tushar> yes
21:19:59 <dendrobates> Tushar: we need something on the wiki as well
21:20:08 <Tushar> "log message" should be replaced with _("log message")
21:20:17 <Tushar> and you will needto import gettext module
21:20:18 <jaypipes> Tushar: you mean, the "best" way to do things like from gettext import ugettext as _ ?
21:20:36 <Tushar> yes
21:20:41 <xtoddx> jaypipes: i don't know gettext, but why is that the case?
21:20:42 <jaypipes> Tushar: I can help with that.
21:20:55 <Tushar> Ok, thanks
21:21:22 <gundlach> if we can avoid littering code w/ _()s that would be ideal -- either centralizing in xtoddx's log.py or monkeypatching the logging module
21:21:30 <jaypipes> xtoddx: you "mark" strings in the source as i18n'd with gettext, and running the gettext binaries on the source directory produces a .po file that is uploaded to Launchpad for translations.
21:21:33 <dendrobates> I think we need to move all strings to .pot files and then we can import them into LP
21:21:57 <jaypipes> dendrobates: we do it in Drizzle. mtaylor and myself can take point on this.
21:21:57 <dendrobates> Which will track all the strings for translation
21:22:35 <jaypipes> gundlach: believe it or not, littering the code with _() is the standard way of doing this..
21:22:35 <ttx> #action jaypipes and mtaylor to help Tushar set up his i18n efforts
21:22:35 <dendrobates> jaypipes: can you work with Tushar and let me know i fyou need anything else
21:22:42 <jaypipes> dendrobates: yep
21:23:00 <gundlach> jaypipes: yeah, i know, but that's great in projects that have lots of different exposed strings.  logging is the vast majority of our exposed strings, right?
21:23:11 <gundlach> jaypipes: so we don't have to accept the litter in most cases.
21:23:26 * ttx can't wait to get some translation karma for translating openstack messages into French.
21:23:49 <jaypipes> gundlach: yes, we do.  the litter is at the place of textual origin.  the new logging module would not be the place of textual origin, it would be a wrapper around the logging.debug(), etc calls.
21:24:26 <soren> jaypipes: Does it have to be, though?
21:24:28 <gundlach> i don't see the value of having to put _() at the place of textual origin.
21:24:33 <jaypipes> soren: yes.
21:24:34 <soren> Ah, yeah, otherwise we can't export them.
21:24:47 <soren> Easily, at least.
21:25:18 <jaypipes> gundlach: the only other way would be to have a single file with constant to English message string map, and only having _() in that file... but that's more cumbersome IMHO.
21:25:58 <gundlach> erm, ok, i bow to your experience in this
21:26:11 <ttx> ok, sounds like we have a plan then
21:26:12 <gundlach> i don't quite get it, but that's ok, we can talk offline :)
21:26:17 <jaypipes> gundlach: sure :)
21:27:06 <ttx> Tushar: is it what is tracked by https://blueprints.launchpad.net/nova/+spec/i18n-support ?
21:27:12 <Tushar> yes
21:27:18 <ttx> Tushar: ok, great.
21:27:26 <Tushar> twe have also set ausit-logging as dependency..
21:27:31 <eday> gundlach: to collect the strings to translate, they need to be tagged in source. they are never called (ie, monkey patching doesn't help identify if you never call it)
21:27:52 <zykes-> can help doing norwegian
21:28:02 <zykes-> and some swedish (:
21:28:05 <gundlach> gotcha, so something does a lexical check for _ ( ) and then translates the source files?
21:28:12 * jaypipes can help translate into Jive.
21:28:25 <ttx> xtoddx: how far away is audit-logging from being proposed for merging ?
21:28:48 <ttx> xtoddx: it's part of lp:~anso/nova/deploy
21:28:57 <xtoddx> ttx: it is, eday left some comments today, i need to see how far we diverge from how swift logs
21:29:14 <xtoddx> lp:~xtoddx/nova/newlog is auditlogging, i forgot to link to the blueprint
21:29:28 <xtoddx> its a port of our logging changes from deploy into trunk
21:29:37 <eday> gundlach: yup, then it creates a bunch of translated files that can be used for substitutions (monkey patching would work at this step, but that doesn't help at this point)
21:29:45 <ttx> xtoddx: ok, thanks !
21:30:10 <ttx> anythins else on that subject before we move to open discussion ?
21:30:22 <gundlach> eday: gotcha, thought it was at runtime.  i still think we could ask the translator to detect _() as well as logging.<anything>(), but ok :)
21:30:38 <eday> jaypipes: I have a program that does jive translations for you
21:30:52 <jaypipes> eday: :) cool.
21:31:32 <ttx> #topic Open discussion
21:31:40 <eday> gundlach: for collection, yes, you could look for things other than _(), but then it might get messy. who knows :)
21:32:13 <dendrobates> I am taking the raw-disk-image brach and fixing it up.
21:32:32 <dendrobates> it has been dormant for 6 weeks and is a dependency for other things
21:32:41 <jaypipes> good
21:32:52 <dendrobates> I'll be doing the merge proposal today or tomorrow
21:33:04 <dendrobates> what about the hyperv MR?
21:33:09 <dendrobates> anyone working on that?
21:35:04 <soren> Yes.
21:35:15 <soren> I poked Chiradeep. He said he'd fix it up.
21:35:26 * alekibango hopes live migration will come in soon
21:35:29 <dendrobates> soren: when did you poke him.
21:35:35 <soren> dendrobates: Yesterday.
21:35:38 <soren> I think.
21:35:41 <soren> Or early today.
21:35:45 <dendrobates> great
21:35:47 <soren> I'm not sure. I've lost my sense of time.
21:36:08 <soren> My wife promised she'd let me know when it's christmas.
21:36:19 <zul> lol
21:37:14 <alekibango> soren: you missed it. it was last month
21:37:19 <soren> Next year, then.
21:37:30 <alekibango> :)
21:40:30 <soren> I'm done
21:41:27 <ttx> ok, let's close it
21:41:34 <ttx> #endmeeting