[12:10] <lifeless> one minute
[12:30] <ddaa> too late, I'm going to bed. Staying connected for the scrollback.
[12:31] <lifeless> ok
[12:31] <lifeless> anyway, I'll have answers tomorrow
[12:31] <lifeless> but as your scripts do not write to the sm directly, it should not matter to you or niemeyer
[12:31] <lifeless> ditto for reading, the ids are not exposed outside the SM machine
[12:32] <ddaa> lifeless: it would be simpler for us to read directly from the id-based FS.
[12:32] <ddaa> and more robust as well
[12:32] <spiv> niemeyer: No, that internal structure isn't in place yet.
[12:32] <lifeless> then we should change the specs
[12:32] <lifeless> we do not want the id based FS to leak
[12:32] <ddaa> it's not leaking... bzrsync is an internal system.
[12:32] <lifeless> in fact, we should not use the real id based FS to read, it would make to tight coupling
[12:33] <lifeless> we should use a flat structure exposing the ids for internal use
[12:34] <ddaa> lifeless: this is niemeyer
[12:34] <ddaa> niemeyer: this is lifeless
[12:39] <ddaa> spiv: would it be feasible for you to hack something to give us that flat id namespace on an internal http?
[12:40] <ddaa> I mean, before next week.
[12:46] <lifeless> spiv: so, did you lose the sm sftp stuff with your laptop ?
[12:52] <spiv> ddaa: So, that's easy... assuming the internal storage is flat ids, just run a private httpd, e.g. plain apache, on a private port serving them.
[12:53] <spiv> lifeless: Almost none, the vast bulk of it was mirrorred.  The larger setback was the change to use just branch ids rather than person-id/product-id/branch-name ;)
[12:54] <lifeless> spiv: re flat id space - right, but if the internal ids get path-shuffled, we'd want a mapping to keep them flat
[12:55] <lifeless> so that the logical access and physical storage are not conflated
[12:55] <spiv> lifeless: So, the SFH spec currently says that an ID of abcdef12 would be stored on disk in a directory ab/cd/ef/12.
[12:56] <ddaa> spiv: niemeyer is working on making bzrsync a good citizen of launchpad/cronscripts, and make it scan the public supermirror. For rollout monday next week at the latest. I'd like that code to to use branch id to access the bzr branches on SM regardless of what the backend FS looks like.
[12:56] <spiv> So the apache would need a simple mod_rewrite.
[12:56] <lifeless> spiv: right.
[12:56] <spiv> If we ever change that scheme, we'd obviously need to update the mod_rewrite config in that httpd.
[12:56] <lifeless> spiv: right.
[12:57] <lifeless> spiv: so I'd like that published as 'http://internal/+ids/abcdef12
[12:57] <spiv> i.e. I'd expect it to be serving from http://foo/bar/abcdef12 not http://foo/bar/ab/cd/ef/12.
[12:57] <ddaa> that said, I'm heading away, thanks guys
[12:57] <spiv> Sorry, I'm obviously not awake enough, I assumed you read my mind and thought that was obvious ;)
[12:57] <spiv> ddaa: Good night.
[12:58] <lifeless> night ddaa
[12:58] <spiv> I'm not sure that the branches on the supermirror currently have branch records in Launchpad...
[12:58] <ddaa> spiv: lifeless: btw, while you are around with niemeyer, can you fill him with the specific testing requirements for cronscripts, if any?
[12:59] <lifeless> spiv:  they do not
[12:59] <niemeyer> spiv: abcdef12?
[12:59] <ddaa> spiv: if they don't they bzrsync do not care.
[12:59] <niemeyer> spiv: Isn't it just 12?
[12:59] <lifeless> niemeyer: we are defining a new publishing address for branches on the supermirror
[12:59] <ddaa> Hu, I mean bzrsync do not care abotu branch that are not in launchpad.
[12:59] <niemeyer> lifeless: Yeah, I got that part.. ;)
[12:59] <lifeless> niemeyer: if the database id was 'abcdef12'
[12:59] <niemeyer> lifeless: Ah, ok.. database ids are numbers always.
[12:59] <lifeless> then the url would be 'http://internal/+ids/abcdef12'
[01:00] <lifeless> niemeyer: this is true, and thus confusing as an example ;)
[01:00] <spiv> niemeyer: abcdef12 is a number in base 16 ;)
[01:00] <niemeyer> spiv: Ah, of course. My fault.. :)
[01:02] <spiv> (the librarian's on-disk storage uses that scheme, also with hex)
[01:03] <lifeless> spiv: I think to http publish decimal is easier to debug
[01:04] <niemeyer> spiv: Yes, but they're hashes, while database ids are not (as we're talking in the other window :)
[01:04] <spiv> niemeyer: No, they're not, as I'm saying in the other window :)
 It won't be fantastic, but it'll be good enough.
 Each directory will have a maximum of 256 entries at any level.
 So while the existing entries won't be evenly distributed, it will avoid the major suckage of having thousands of entries in a single directory.
 I guess a cheap way to improve that would be to reverse the segments:
 12/ef/cd/ab
[01:05] <niemeyer> spiv: Interesting
[01:05] <lifeless> hmm
[01:06] <spiv> lifeless: I don't see how it would be easier to debug -- it's just a number either way.  Converting to and from hex isn't hard: python -c "print 0xabcdef12, hex(12345678)"  ;)
[01:06] <lifeless> spiv: one has to do that
[01:06] <lifeless> spiv: postgres gives you decimal output
[01:06] <spiv> lifeless: How about this.
[01:07] <spiv> lifeless: You figure out how to write the rewrite rule to do the conversion, and I won't care ;)
[01:07] <lifeless> heh
[01:07] <lifeless> well, lets do hex then
[01:07] <lifeless> as I don't care *that* much
[01:08] <jamesh> postgres has a to_hex() function, if that helps
[01:09] <spiv> jamesh: Beat me to it :)
[01:10] <Alinux> hello
[01:11] <Alinux> can tell me someone, if .po files translated in lauchpad are syncronized with original .po files?
[01:12] <lifeless> perhaps /+hexids/abcdef12
[01:12] <lifeless> so its clear to someone debugging
[01:13] <jamesh> Alinux: if the upstream maintainers export them from rosetta and include them, yes
[01:14] <jamesh> Alinux: for Ubuntu, the rosetta data is also exported as language packs
[01:14] <spiv> lifeless: That's a good idea.
[01:15] <Alinux> yes I know... but it measn that for example "nautilus" translated in Georgian in Ubuntu will never appear in "nautilus" of Debian or SuSE etc...
[01:15] <Alinux> =
[01:16] <mdke> Alinux, it depends on the georgian gnome translating team
[01:16] <jamesh> Alinux: you could request an export and then ask someone on the gnome-i18n list to commit it
[01:16] <mdke> if they export them, then they will be included
[01:17] <jamesh> Alinux: if you are part of the gnome translation project, you could commit updated PO files easily too
[01:17] <Alinux> gnome gnome, or ubuntu gnome?
[01:17] <mdke> gnome gnome
[01:18] <Alinux> I'm in Ubuntu Georgian translators team
[01:18] <mdke> Alinux, here is how it works
[01:18] <Alinux> not in gnome.
[01:18] <jamesh> GTP
[01:18] <mdke> Gnome translators have their own procedure about which translations/translators they accept
[01:18] <mdke> so Ubuntu can't force them to use its translations
[01:19] <mdke> if they want to, they can
[01:19] <mdke> they generally will, if they think they are good enough, and are aware that they exist
[01:20] <Alinux> mdke, sei tu ? :)
[01:20] <mdke> yes
[01:20] <Alinux> ciao bro :)
[01:20] <mdke> hi
[02:14] <jamesh> looks like ddaa's branch added a patch-25-99-0.sql
[02:14] <jamesh> which doesn't look like an approved patch number
[02:35] <Kinnison> jamesh: shouldn't be a problem, we're on a -40- baseline now?
[02:36] <Kinnison> ciau
[02:39] <jamesh> Kinnison: it still gets applied by "make schema", without any errors
[02:39] <jamesh> just makes me think it hasn't been approved
[02:39] <jamesh> (not that it wouldn't get approved)
[03:54] <jblack> spiv: around?
[03:55] <spiv> jblack: Yeah.
[03:56] <jblack> Remember that config class we made back at UBZ?
[03:56] <jblack> we replaced Config.get() with a __getattr__(self, var)
[03:57] <spiv> Hmm, I don't remember that at all.
[03:57] <spiv> Perhaps you're thinking of someone else, or perhaps you just need to jog my memory more :)
[03:57] <jblack> Never mind. I figured it out.
[03:58] <jblack> THanks for the help. :)
[03:58] <spiv> Excellent :)
[04:16] <jamesh> jblack: I think I was the one helping you out then.
[04:16] <jblack> Oh, yes. That's right.
[09:31] <SteveA_> morning everyone
[09:32] <ajmitch> hi
[09:34] <stub> yo
[09:57] <SteveA_> jamesh: how's the error reporting stuff looking?
[09:58] <Kinnison> jamesh: bizarre, I didn't think we applied patches except within the baseline.
[09:59] <jamesh> SteveA_: okay.  I've got the hooks in place, just need to finish off the code that writes out the exception files
[09:59] <jamesh> Kinnison: maybe that's a bug too ...
[09:59] <Kinnison> jamesh: perhaps. I'd mail stub if I were you
[10:04] <jamesh> Kinnison: no need: see item 3 on http://pqm.ubuntu.com/
[10:06] <Kinnison> aha
[10:06] <Kinnison> coolio
[10:17] <sivang> Morning all
[10:18] <Kinnison> hi sivan
[10:18] <sivang> Kinnison: Hey Daniel, what's cooking?
[10:19] <Kinnison> sivang: not much, just sorting through my TODO
[10:19] <Kinnison> Had to get up early today to take the car in for its MOT
[10:19] <sivang> Kinnison: ah, good
[10:19] <Kinnison> so I'm still under-caffeinated
[10:19] <sivang> Kinnison: MOT ?
[10:19] <Kinnison> sivang: it's a test which all cars over a certain age take each year to ensure they're road-worthy
[10:20] <ajmitch> something that has to be done every 6 or 12 months here, for every car
[10:21] <Kinnison> maybe a tyre or two will need replacing
[10:21] <sivang> Kinnison: oh, right. we have this here as well
[10:22] <sivang> Kinnison: what brand of car is that?
[10:22] <Kinnison> sivang: I have a Daewoo
[10:22] <Kinnison> s'not brilliant, but it works
[10:23] <carlos> morning
[10:24] <ddaa> Maybe they should do the same for politicians.
[10:24] <Kinnison> ddaa: what, check every year that their brake pressure is high enough and that their tyres have enough tread?
[10:24] <ddaa> In substance.
[10:24] <jamesh> ddaa: for politicians, it's called an election
[10:25] <ddaa> jamesh: nah, an election is like crossing an intersection.
[10:26] <ddaa> That a car crosses an intersection means neither that the driver is awake (i.e. crossing when the traffic light is green) nor that the car is able to turn or brake (it just needs to go straight ahead).
[10:27] <ddaa> Occasionally, a policitician crashes when crossing an election. That's called a Watergate.
[10:27] <ddaa> or it crosses all right but then roll over a few pedestrians.
[10:27] <ddaa> That's called Dubia.
[10:28] <ddaa> Or Tony Blair if you want.
[10:29] <ddaa> Oh BTW, apparently the fellow was caught having a phone conversation where he suggested bombing Al-Gesira :)
[10:30] <ddaa> more practically
[10:30] <sivang> ddaa: LOL
[10:31] <ddaa> jamesh: I have few questions for you about the where and whys of launchpda cronscripts.
[10:31] <ddaa> jamesh: got a few minutes?
[10:31] <jamesh> ddaa: sure.
[10:32] <ddaa> So context: we need to have a new cronscript for bzr branch scanning. niemeyer is the guy that's going to work on actually doing it.
[10:33] <ddaa> What are the requirements for new cronscripts, in terms of integration with launchpad, testing, deployments, etc. ?
[10:35] <ddaa> Actually, It's just one big sweeping question ATM. I have more pointed ones, but I'd like if you could generally, "tell me what you know".
[10:35] <jamesh> ddaa: best practice is to put the meat of the script in lib/canonical/launchpad/scripts as a module, and write it in a form where it can be tested
[10:35] <jamesh> ddaa: then make the actual script in cronscripts/ a small program that uses the above module
[10:36] <SteveA_> i think niemeyer talked with spiv yesterday about this also
[10:37] <ddaa> did not see much relevent talk in the backlog... maybe it was a private discussion?
[10:37] <SteveA_> dunno.  i just read it on gustavo's activity report.
[10:38] <ddaa> The public log has much talk about SMFSH, which is orthogonal to the cronscripting.
[10:39] <ddaa> SteveA_: I also wonder what's the purpose of the ./cronscript/tests directory
[10:40] <ddaa> it's empty here
[10:43] <ddaa> jamesh: is there a cronscript template somewhere? In the current collection of scripts, it hard to tell what's best practice and what's this way just because it's the way it is.
[10:45] <jamesh> ddaa: scripts/bugzilla-import.py in https://chinstrap.ubuntu.com/~jamesh/pending-reviews/jamesh/launchpad/bugzilla-import/full-diff isn't too bad
[10:48] <ddaa> Mh... I guess that means the bzrsync should move out of lib/importd and become a good citizen of the launchpad testing framework...
[10:51] <ddaa> jamesh: is there a set of required command line options?
[10:52] <jamesh> ddaa: not really.
[10:53] <jamesh> ddaa: if you are producing log messages, it is good to use canonical.launchpad.scripts.logger_options() and c.l.s.logger() to set up logging
[10:53] <jamesh> ddaa: that'll give consistent handling of --verbose and --quiet args
[10:53] <ddaa> Wel... if you remove mysql and and optparse, there's not much left of your script...
[10:54] <ddaa> mh... ok
[10:55] <ddaa> Is there anything tricky I should now about launchpad.conf integration?
[10:55] <ddaa> * I should know
[10:56] <jamesh> not really
[10:56] <jamesh> edit lib/canonical/config/schema.xml to define new keys, set appropriate values in the various configs under configs/
[10:57] <ddaa> well, separate db user, so will probably need a rework of security.cfg, I figured out.
[10:57] <ddaa> Has schema.xml, thanks!
[10:57] <ddaa> Did not notice that before.
[10:58] <ddaa> Mh.... I think that completes the integration questions. Now, the deployment questions :)
[10:59] <ddaa> Who is in charge of rolling out a cronscript and setting up the cronjob?
[11:00] <ddaa> I mean, is that centralised (stub/elmo/etc. does them all), or is that everybody does its own? And on which system?
[11:04] <spiv> ddaa: Talk with stub, I think.
[11:04] <ddaa> stub: ping!
[11:05] <spiv> ddaa: Even if it's something that doesn't run on the same machines as the production webapps, it's still likely he'll need to know about it for rollouts and planned outages.
[11:06] <ddaa> spiv: well, ATM I'm try to figure out what's the general policy and whether there's any policy.
[11:07] <ddaa> one question related to that, is what is the recommended procedure for cronscript feedback? Email? And then to who, configured in which way?
[11:08] <ddaa> I can imagine many combinations there, but I'd like to know what's currently being done before asking niemeyer to do something that will waste his time in review.
[11:08] <spiv> The other cron scripts mail to the launchpad error reports list.
[11:08] <jamesh> ddaa: assuming you are using the standard logging framework, setting the log level to the appropriate level should result in only errors getting printed
[11:08] <jamesh> ddaa: so if you run the script at that logging level, cron will mail out the output
[11:09] <spiv> I think this is done by making the cron jobs themselves look for output on stderr, and mail if appropriate.
[11:11] <ddaa> jamesh: mail the output to the launchpad-error-reports mailing list?
[11:12] <jamesh> ddaa: I think that's how it works
[11:14] <ddaa> SteveA: can you approve my subscription to launchpad-error-reports, please?
[11:17] <SteveA_> ddaa: no
[11:17] <SteveA_> ddaa: i'm not manager of that list
[11:17] <SteveA_> oh, aparently i am
[11:17] <SteveA_> how odd
[11:19] <SteveA_> ddaa: you're approved
[11:26] <stub> ddaa: Pong
[11:26] <stub> (had the sound down sorry)
[11:29] <stub> ddaa: I'm generally the person who turns on the various cron stuff, and am the point of contact for that.
[11:30] <stub> ddaa: cronscripts generally just spit their output to stdout/stderr and cron takes it from there (sending the output to launchpad-error-reports)
[11:32] <stub> ddaa: Which makes the scripts testable. Ideally your script will not produce any output if run with '-q' to avoid needless spamming, unless it is important for people to be aware that it actually *did* run (such as backups or critical stuff)
[11:32] <ddaa> Hu... define critical?
[11:35] <stub> ddaa: Stuff you will be explicitly checking for in your in tray every day.
[11:36] <ddaa> In my specific case, the task is scanning bzr branches to populate the database. I expect that sooner or later we'll want to be able to see what has been done during the last few runs (for diagnostic, in case something smells fishy). What would be the way of handling this sort of logging?
[11:36] <stub> ddaa: I can't think of any of our existing systems that are like that, except for possibly the shipit exports (and marileze gets that status through another mechanism anyway)
[11:37] <stub> ddaa: Sure. Just output overview stuff using log.info(), verbose debugging noise using log.notice()
[11:37] <stub> ddaa: Then we roll it out and, when we are happy with how it is performing, we can add the '-q' option to reduce the daily noise. Or add the '-v' option if things are screwing up and we need the debug noise.
[11:38] <stub> ddaa: So just use the launchpad.scripts.logger stuff jamesh mentioned above
[11:39] <stub> Which gives you nice timestamps and stuff in your output, which is very useful for stuff running as a cronjob
[11:42] <stub> ddaa: Will your script run happily on the standard production servers, or need to run on a specific server or a dedicated server?
[11:42] <ddaa> Do you usually run jobs as a specific user on a specific system? I'm used to having a lot of control over the bazaar-related subsystem so I can do rollout or tweak this kind of diagnostic knobs myself.
[11:44] <stub> ddaa: No, but we should be ;)
[11:44] <ddaa> I do not expect that specific script is going to have exotic requirements. It's mostly running bzrlib over sanitised branches to extract metadata (so I do not expect high CPU or memory usage) and fill the database.
[11:44] <stub> ddaa: If you want to run it yourself, that is fine. I just need to give DB access to the relevant accounts and possibly do test runs for you on the staging server.
[11:46] <ddaa> Though, it can potentially run a large number of transactions when new branches are published.
[11:46] <WaterSevenUb> carlos, quick question... dapper translations will change a lot soon? i.e., something like breezy imports? or is more or less stable by now?
[11:46] <carlos> WaterSevenUb, will change a lot soon
[11:47] <WaterSevenUb> carlos, ok:-) thanks. How about saying those things on Rosetta-users?:) I'm afraid translators get mad loosing their work...
[11:47] <carlos> no work will be lost
[11:48] <WaterSevenUb> ok, great ;)
[11:48] <ddaa> stub: oh BTW, somebody pointed out that I merged my patch as patch-(something)-99.sql :)
[11:48] <stub> ddaa: I noticed ;) There is a patch in PQM to fix that (failed to land it yesterday)
[11:48] <ddaa> Should I fix that myself or leave you make it dbadmin kosher?
[11:49] <ddaa> nice, thanks
[11:49] <stub> ddaa: It is running on staging if you want to confirm the new schema works with launchpad happily
[11:53] <ddaa> I fully expect there will be no problems.
[11:53] <ddaa> Had a quick look though.
[11:53] <ddaa> The code is very thouroughly tested.
[11:54] <ddaa> stub: is there a rollout policy for cronscripts?
[11:54] <ddaa> I mean, is that bound to the launchpad rollout schedule, or can we nag you randomly to update or rollout new cronscripts?
[11:56] <stub> ddaa: I like to be nagged. Just because the script has landed doesn't mean it should be turned on yet, as there may still be outstanding dependancies (eg. debbugs syncing waiting on Gina)
[11:57] <stub> ddaa: Turning them on isn't bound to the launchpad rollout schedule, and if you are maintaining the codebase that runs it it doesn't even have to be the production branch you are running (which could cause issues with our mutating database schema, but if you want the rope you can have it)
[11:57] <ddaa> Thinking of which. I think I'd like to to be able, at least, to kick the script by hand now and then. For example when an interesting community member just registered a branch I'd like to be able to cause an immediate scan.
[11:58] <jamesh> ddaa: interesting choice of sample data, btw ;)
[11:58] <ddaa> I'm pretty much in control of the db schema bits relating to this. And I'm used to having massive version skew with production on importd...
[11:59] <ddaa> For example, I'm about to rollout the new importd, and it's expectd to work seamlessly with the old and new schemas.
[12:00] <ddaa> stub: So, I think it would be nice to have a new user we can both login into for controlling bzrsync.
[12:00] <ddaa> sounds reasonable?
[12:01] <stub> ddaa: Sure. Macquarie would be a good choice then since we both already have accounts there and it already has other connections to the production db.
[12:01] <ddaa> jamesh: well, gnome-terminal was one of the few sampledata products that were not already "polluted" by hct sampledata :)
[12:02] <stub> ddaa: Just stick an issue into rt for elmo/znarl
[12:03] <ddaa> oh, BTW I need to go scream because it (and the importd systems) do not have bzr yet :(
[12:04] <stub> ddaa: We are building it from source to avoid having to keep rolling out the dailies (with is a pita, and blocked me updating staging yesterday and production today :-( )
[12:04] <ddaa> that does not sound that much a PITA...
[12:05] <stub> ddaa: rollout.py in the main config tree is what I'm using
[12:05] <stub> ddaa: It is a pita when the current version we are supposed to use doesn't work with our archives ;)
[12:06] <ddaa> Cannot use that.
[12:06] <stub> Robert seemed happy with installing 0.7 though when it is released
[12:06] <ddaa> The importd stuff requires some uncommitted changes (builbot's private.py) and some non-source files to be preserved (though it could be argued that's a bug).
[12:07] <ddaa> Mh... I guess I could w/o bzr...
[12:08] <ddaa> I can move the critical data "by hand".
[12:08] <stub> Sounds like a bug - I would say private.py and the non-source files needing preservation should not be in the tree. Makes rollouts and the corresponding documentation much easier
[12:08] <matsubara> good morning!
[12:08] <ddaa> stub: IMO using buildbot at all is a bug.
[12:09] <stub> We already do this for the main production launchpad instances (there is a ZCML script that lives outside of the tree that contains the IMAP password)
[12:09] <ddaa> And I'm not sure at all we can move the private.py away.
[12:09] <ddaa> mh... yes we can...
[12:13] <ddaa> hey niemeyer
[12:13] <niemeyer> ddaa: Hello
[12:19] <cprov> good morning
[12:40] <WaterSevenUb> a translator asked me if his work was being lost somehow since his "karma" was going down... how is Karma measured ?
[12:40] <Kinnison> Karma decays over time
[12:40] <Kinnison> So you have to keep doing work in order to keep it up
[12:40] <WaterSevenUb> yeah.. that's what I thought...
[12:40] <WaterSevenUb> .)
[12:40] <WaterSevenUb> kinnison, ok thx
[12:40] <Kinnison> No problem
[12:45] <WaterSevenUb> kinnison, see bottom https://wiki.ubuntu.com/NewTranslatorQuestions - answer to the karma question. More or less fine?:)
[12:47] <Kinnison> seems fine
[12:47] <Kinnison> salgado: does it look right to you?
[12:51] <salgado> yep, it's okay
[12:54] <sivang> hmm, can anyone tell me why I am getting "orry, you don't have permission to access this page." on https://launchpad.net/distros/ubuntu/+spec/dapper-desktop-plan/+status? It wsa suggested as an example in an email to u-d sent by JaneW
[12:58] <sivang> oh, and another question - why is my Karma dropping in launchpad? :)
[01:07] <carlos> lifeless, Is there any trick to do a bzr mirroring fast?
[01:07] <Kinnison> carlos: use bzrtools and its rsync push rather than sftp:// push
[01:08] <carlos> Kinnison, tried a local mirror and then direct rsync but the local mirror is still slow
[01:08] <carlos> Kinnison, what should I use? rsync:// ?
[01:08] <carlos> bzr push rsync://.... ?
[01:09] <Kinnison> bzr push chinstrap.ubuntu.com:/home/warthogs.....
[01:15] <carlos> Kinnison, seems to work as I wanted. Thank you!
[01:16] <Kinnison> carlos: You're welcome
[01:16] <Kinnison> bzr: ERROR: bzrlib.errors.NoSuchRevision: Branch BzrBranch(u'/home/dsilvers/dev-canonical/rocketfuel-mirror-of-launchpad/launchpad') has no revision<EMAIL_ADDRESS>[01:16] <Kinnison> urgh :-(
[01:17] <carlos> sounds bad...
[01:17] <Kinnison> I *think* this is a known issue with bzr
[01:26] <salgado> stub, around?
[01:28] <jamesh> Kinnison: I think lifeless fixed it last time
[01:29] <Kinnison> jamesh: hmm
[01:36] <sivang> jamesh: Is it easy to have the same remedey you suggested for #3600 be applied to the whiteboard text handleing of the specification tracker? :-)
[01:43] <Keybuk> funny, googling for "introduction to quilt" gave me a document with exactly the title I was looking for, but not the content
[01:46] <sivang> Kinnison: bon appetite!
[01:48] <stub> salgado: yes
[01:48] <salgado> stub, is it possible to optimize this: https://chinstrap.ubuntu.com/~dsilvers/paste/file6sINHz.html
[01:49] <salgado> ?
[01:56] <stub> salgado: Nothing obvious. I'll have a closer look later
[01:57] <salgado> stub, ok, thanks. :)
[02:16] <niemeyer> ddaa: Great job on the document
[02:28] <SteveA> carlos: ping
[02:51] <Kinnison> brb, gotta reconnect the router
[03:02] <stub> salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/filewrXAog.html
[03:02] <stub> salgado: The way you have is only taking 3 or 4 seconds to execute though, so perhaps there is another query on that page that is causing the time to be chewed up?
[04:13] <kiko> hello guys
[04:13] <kiko> how is everybody?
[04:15] <kiko> Kinnison?
[04:16] <SteveA> hi carlos
[04:16] <SteveA> we have a few code things to talk through.  and i have another 2/3 of the review to do
[04:16] <carlos> SteveA, pong
[04:16] <carlos> hi
[04:17] <Kinnison> kiko: hey
[04:17] <Kinnison> kiko: what can I do for you today?
[04:18] <kiko> Kinnison, let's talk soyuz some, shall we?
[04:20] <Kinnison> kiko: sure, can I have a few mins to finish up this function?
[04:20] <kiko> yeah sure
[04:20] <kiko> take off the tuxedo etc
[04:21] <Kinnison> what?
[04:26] <carlos> SteveA, ?
[04:26] <SteveA> carlos: can we talk in 30 mins or so?
[04:27] <carlos> SteveA, sure
[04:27] <kiko> Kinnison, the function you're finishing.
[04:30] <Kinnison> Okay, what do you want to talk about?
[04:30] <kiko> Kinnison, guess and win 5$? I think elmo would be helpful here as well -- elmo, are you available?
[04:43] <kiko> Kinnison, well, let's try again in 1h. can you please try and get hold of elmo? I'd like to see if we are moving to drescher.
[04:43] <niemeyer> kiko!
[04:43] <niemeyer> Welcome back
[04:43] <Kinnison> stub suggested we shouldn't
[04:43] <kiko> hey niemeyer
[04:43] <Kinnison> did you not see that mail?
[04:44] <kiko> Kinnison, not yesterday. I know he suggested that -- he said so at UBZ as well. I was wondering if he had reconsidered
[04:44] <kiko> he's suggesting living without staging then?
[04:45] <Kinnison> Seems to be what he's advocating
[04:45] <kiko> well, if that's the case.
[04:46] <kiko> Kinnison, at any rate, we should talk status and see how I can help you
[04:47] <Kinnison> Okay, give me 2 mins and we'll talk status
[04:47] <kiko> Kinnison, 1h is better, I need lunch
[04:48] <Kinnison> kiko: okay, one sec... 17:00 UTC? 1h13m from now
[04:48] <kiko> that's perfect
[04:48] <kiko> thanks
[04:53] <salgado> hmmmm. is pqm borked again?
[04:55] <bradb> salgado: I think it's due to the load on chinstrap. But it's not always easy to tell if pqm is down or just unbelievably slow.
[05:13] <Kinnison> ciao
[05:18] <bradb> jamesh: around?
[05:26] <carlos> hmm
[05:26] <carlos> someone added a wrong db patch to launchpad...
[05:26] <carlos> carlos@aragorn:~/Work/Canonical/trivial/database/schema$ ls patch-*
[05:26] <carlos> patch-25-99-0.sql  patch-40-00-0.sql  patch-40-02-0.sql
[05:26] <SteveA> carlos: shall we talk about the translation queue stuff now?
[05:27] <carlos> ddaa, I think it's about your work on launchpad, not sure who added them...
[05:27] <carlos> SteveA, sure
[05:28] <SteveA> 'lib/canonical/launchpad/browser/translationimportqueue.py'
[05:28] <SteveA> carlos: can we look at that first?
[05:29] <carlos> sur
[05:29] <carlos> sure
[05:29] <SteveA> so, i made some comments about this set of 4 methods
[05:29] <SteveA>  has_things_to_import, has_pending_reviews, readyToImport, pendingReview
[05:29] <SteveA> first two are properties, actually
[05:30] <carlos> right
[05:30] <carlos> I don't see why a raw SQL query should be used there...
[05:30] <SteveA> raw sql?
[05:31] <carlos> "Maybe this should go to an SQL query?" isn't it what you are suggesting?
[05:31] <SteveA> no
[05:32] <SteveA> first of all, the code to has_things_to_import looks almost the same as readyToImport
[05:32] <SteveA>   @property
[05:32] <SteveA>    def has_things_to_import(self):
[05:32] <SteveA>        """Return whether there are things ready to import or not."""
[05:32] <SteveA>        for entry in self.context.getEntries():
[05:32] <SteveA>            if entry.import_into is not None:
[05:32] <SteveA>                return True
[05:32] <SteveA>        return False
[05:32] <SteveA>    def readyToImport(self):
[05:32] <SteveA>        """Iterate the entries that can be imported directly."""
[05:32] <SteveA>        for entry in self.context.getEntries():
[05:32] <SteveA>            if entry.import_into is not None:
[05:32] <SteveA>                yield entry
[05:32] <SteveA>
[05:33] <carlos> yes is the same
[05:33] <SteveA> so, why not write has_things_to_import in terms of readyToImport ?
[05:33] <carlos> I thought it was easier to understand that way
[05:34] <SteveA> maybe.  it will also make people wonder if they've missed something, seeing the repeated code
[05:34] <carlos> SteveA, well, it's not exactly the same, but it's quite similar
[05:34] <carlos> the returned value is different
[05:34] <SteveA> you could do this:
[05:34] <SteveA>   @property
[05:34] <SteveA>    def has_things_to_import(self):
[05:34] <SteveA>        """Return whether there are things ready to import or not."""
[05:34] <SteveA>        for entry in self.readyToImport():
[05:34] <SteveA>            return True
[05:34] <SteveA>        return False
[05:35] <carlos> ok
[05:35] <SteveA> there are other ways of doing it too
[05:35] <SteveA> but i think this is not too bad
[05:36] <carlos> ok, next point?
[05:37] <carlos> hmm wait
[05:37] <carlos> what did you mean with the SQL query?
[05:37] <SteveA> where did i say that?
[05:38] <YuLin> Hi there
[05:38] <YuLin> ;)
[05:38] <SteveA> hello YuLin
[05:38] <YuLin> may I ask a question?
[05:38] <carlos> That is a lot.  The code is already iterating over many of the database
[05:38] <carlos> records.  Maybe this should go to an SQL query?
[05:38] <YuLin> (well, that was already one, actually)
[05:39] <SteveA> ah, right
[05:39] <carlos> SteveA, that's what you said for has_things_to_import
[05:39] <Kinnison> YuLin: go ahead
[05:39] <YuLin> Kinnison: thank you :)
[05:39] <SteveA> carlos: you were saying that you want to use iteration there, in order to cope with having a lot in the database
[05:39] <carlos> right
[05:40] <SteveA> carlos: the query to get self.context.getEntries() is made 4 times the way the view is currently written, it looks like
[05:40] <SteveA> i'm not sure if these are all on the same page
[05:41] <YuLin> so, here's my question: why Swiss French is not represented as one of the languages Ubuntu can be translated in?
[05:41] <ddaa> carlos: the patch-25-99.sql is mine.
[05:41] <SteveA> if they are, then it would be better to use self.context.getEntries() once, iterate over it once, getting the required information from it
[05:41] <ddaa> I was a bad boy.
[05:41] <ddaa> stub said he has a fix pending upload
[05:41] <SteveA> or, not iterating over it to find a case when import_into is None or not None, and instead adding a database API for this
[05:42] <SteveA> so that you don't potentially iterate over all of them
[05:42] <carlos> SteveA, well, we don't iterate over all the records...
[05:42] <SteveA> you might
[05:42] <SteveA> it depends on the data in the records
[05:42] <carlos> we do the query but we get only the first entry
[05:42] <SteveA> you get as many queries as needed
[05:42] <carlos> hmmm, that's true
[05:42] <SteveA> to find one with import_into is NULL
[05:42] <SteveA> or not NULL
[05:43] <SteveA> so, if this can get big
[05:43] <SteveA> it needs to be a query of its own
[05:43] <carlos> ok
[05:44] <YuLin> so? ;)
[05:45] <SteveA> carlos: let's take a break, so you can talk with YuLin
[05:45] <carlos> SteveA, oh, right!
[05:45] <carlos> YuLin, sorry, I didn't see your question...
[05:45] <YuLin> that's so nice
[05:45] <carlos> YuLin, what's the difference between Swiss French and just French?
[05:46] <YuLin> well, there are many
[05:46] <mdke> accent, the occasional word here and there
[05:46] <YuLin> of course "many" isn't really relevant ;)
[05:46] <carlos> YuLin, by default, we hide those kind of languages
[05:47] <YuLin> linguistically, there are many differences, especially due to german influence
[05:47] <mdke> i suspect that the answer is that swiss french people understand french french very well
[05:47] <YuLin> they do
[05:47] <YuLin> but is this legitimate to have Old English represented while no one can speak it?
[05:48] <carlos> but you still can translate into them building the URL by hand to create the first transaltion, later it will appear in all listings for that product or sourcepackage
[05:48] <mdke> no, in my opinion
[05:48] <mdke> equally, French (France) should go, and Italian (Italy) etc
[05:48] <carlos> YuLin, do you think the Swiss French should be always available for all modules to translate?
[05:49] <carlos> or are we talking only about small differences?
[05:49] <YuLin> I think so, yes
[05:50] <SteveA> another thing to ask is, would swiss french speakers join in a wider french translation effort
[05:50] <YuLin> well, you see, I'm French and I live in Switzerland
[05:50] <SteveA> or would they consider their language different, so they would want to focus on their own language, and not on french in general
[05:50] <YuLin> and since I've moved here (a few years), I'm getting aware of more and more differences
[05:50] <YuLin> well
[05:50] <YuLin> there's an idea of identity
[05:51] <YuLin> Swiss French people are very friendly
[05:51] <mdke> one of the leaders of the Ubuntu french translating team is swiss :)
[05:51] <YuLin> however, they don't like to be assimilated to French people
[05:52] <SteveA> of course, people must work on those things that they want to.  but, i'd be concerned about encouraging a split in the volunteer efforts between two goals without so much difference between them
[05:52] <carlos> the key question is if you or someone else will create a Swiss French team
[05:52] <carlos> YuLin, for instance, es_ES and es_MX have differences
[05:53] <YuLin> I guess so
[05:53] <carlos> YuLin, but we try to reach a common translation so we just translate for 'es'
[05:53] <YuLin> I see
[05:53] <carlos> so we join efforts and have just one team
[05:54] <mdke> that is nice
[05:54] <YuLin> well, I suppose you're right
[05:54] <mdke> that way, people get more translations in the end
[05:54] <YuLin> there's no real need for fr_CH, after all
[05:55] <YuLin> I just thought of suggesting this because I know the French Team is rather big and efficient
[05:55] <mdke> it should be the same for english, without all this en_AU en_GB stuff
[05:55] <YuLin> I think, in general, it's nice to preserve differences :)
[05:55] <carlos> YuLin, from the Spanish point of view, we try first to get a 100% and with good quality translation into Spanish and then, we will try to improve the specific parts for every country
[05:55] <YuLin> but of course, if it goes against functionality, that's a problem
[05:56] <SteveA> it can be a big deal for educational software, software used in schools
[05:56] <mdke> carlos, i think that is the right approach
[05:57] <SteveA> because when teachers are trying to teach good en_GB, it is more difficult when the software kids are using is in en_US
[05:58] <mdke> that is a good point. But where it is a question of prioritising scarse resources, I think the spanish approach is the best
[06:00] <carlos> YuLin, the thing is... you can translate into Swiss French if you want, but you need to create the URL manually
[06:00] <YuLin> alright
[06:00] <carlos> YuLin, if you decide that a new team should be created, request us to enable your language by default and we will do it
[06:04] <mdke> carlos, are the fr_FR things going to hang around?
[06:05] <carlos> mdke, the old ones will remain until a French translator merge them into 'fr' and request us to remove them we are not going to implement a way to merge them in the near future (if that's your question)
[06:05] <carlos> mdz, hi, around?
[06:05] <mdz> carlos: yep
[06:05] <carlos> mdz, why launchpad-database-dependencies depends on postgresql 8.1?
[06:05] <mdz> carlos: because postgresql 8.0 says "DON'T USE ME"
[06:06] <carlos> mdz, 8.1 does not work with launchpad
[06:06] <mdke> carlos, yes i think that answers my question. I wasn't really just asking about fr_FR but all languages which have the duplicate. It is quite confusing for users
[06:06] <mdz> carlos: I see.  is that expected to be true in the long term?
[06:07] <carlos> mdke, we prevent to create new ones, but the old ones remain there
[06:07] <carlos> mdz, I don't think so, I suppose it's a matter of stub or any postgres expert to fix it...
[06:07] <carlos> I started to fix it, but got an error that I'm not sure how to solve
[06:07] <mdke> carlos, i see. So if I went about merging the it_IT ones into it, you'd remove it_IT afterwards?
[06:07] <mdz> carlos: should I revert it, or just wait?
[06:08] <carlos> mdke, yes
[06:08] <jordi> carlos, SteveA: saw my draft?
[06:08] <carlos> mdz, I don't know.
[06:08] <carlos> SteveA, ?
[06:08] <carlos> jordi, not yet, sorry
[06:08] <jordi> k
[06:08] <mdke> carlos, ok. Would I have to merge just dapper, or all versions of Ubuntu?
[06:09] <carlos> mdke, does dapper have an it_IT?
[06:09] <carlos> mdke, if that's the case... you need to fix it upstream
[06:09] <SteveA> jordi: not yet
[06:09] <carlos> mdke, or it will appear again
[06:09] <mdke> carlos, yes it does
[06:10] <mdke> carlos, ditto de_DE and fr_FR etc
[06:10] <mdke> but the source packages in there are a bit odd
[06:10] <mdke> https://launchpad.net/distros/ubuntu/dapper/+lang/it_IT
[06:11] <SteveA> carlos: the part of my review where i said something probably didn't have test coverage, and had totally duplicated code, was me not reading a "not" in one version of the methods, by the way.
[06:13] <carlos> mdke, those upstream products should be fixed, anyway, with the new system I developed, we can implement a workaround...
[06:13] <mdke> ooh
[06:14] <carlos> SteveA, ok
[06:16] <salgado> ddaa, that fix stub had to rename patch-25-99.sql was being processed when pqm got stuck, so it didn't get merged
[06:16] <ddaa> ack, but when asked stub if I should fix the problem myself, he told me he had this patch.
[06:17] <ddaa> so I'm not sure what you are suggesting.
[06:17] <carlos> SteveA, "We still have three largely identical methods.  This is not the best thing.
[06:17] <carlos> Let's talk on irc about how to use less code here."
[06:17] <carlos> SteveA, could we talk about that?
[06:18] <salgado> I wasn't suggesting anything, actually. it was just so you know why it wasn't renamed yet
[06:18] <SteveA> yes. let me get another cup of tea.  5 mins
[06:27] <SteveA> carlos: ?
[06:28] <carlos> SteveA, I'm back
[06:28] <SteveA> ok
[06:29] <SteveA> so, we have these methods like def block(self):
[06:29] <ddaa> yay... importd is coming back online, at last...
[06:29] <carlos> SteveA, right
[06:29] <SteveA> > +                entry = self.context.get(id)
[06:29] <SteveA> where does id come from?
[06:29] <ddaa> that was starting to feel like one of those dreams where the more you run, the more backwards you go
[06:30] <carlos> SteveA, from the form, the names of the checkboxes have it
[06:30] <jordi> carlos: we have a few pending plural form requests
[06:31] <jordi> and some "languages in my country" requests
[06:31] <carlos> jordi, will try to handle them tomorrow..
[06:31] <SteveA> look at the method def block
[06:31] <SteveA> where does 'id' come from?
[06:31] <jordi> should I mail launchpad@, or you?
[06:31] <jordi> ok
[06:31] <carlos> I have some pending mails from rosetta-users
[06:31] <jordi> me too
[06:31] <jordi> gotta go, I'm at uni trying to fix the server
[06:32] <jordi> processor seems very dead though :(
[06:32] <kiko> jordi!
[06:33] <carlos> SteveA, ok, when I applied your iniitial review, I didn't execute the tests and forgot to update the for clause to use 'id' instead of 'item'
[06:33] <carlos> jordi, I will do it, I need to update also the sampledata
[06:34] <SteveA> carlos: okay
[06:34] <SteveA> so, the overall pattern of block() is like this:
[06:34] <SteveA>   - set counter to 0
[06:34] <SteveA>   - get the launchpad celebrities
[06:34] <SteveA>   - loop over the ids in form_entries
[06:35] <SteveA>   - check that the user is allowed (not sure why this is done each time through the loop, and not sure why this isn't handled by the normal security systems)
[06:36] <SteveA>   - if user is allowed, get the entry, and block it.  increment counter
[06:36] <carlos> SteveA, because we check if it's allowed with that concrete entry
[06:36] <SteveA> not according to the code, it seems to me
[06:36] <SteveA>   - then notify according to how big the count it
[06:36] <SteveA>
[06:36] <SteveA> this is the same pattern for three different operations
[06:37] <SteveA> all that changes is the action, like entry.block(False) or whatever
[06:37] <carlos> right, I was looking at remove()
[06:37] <SteveA> and the notification message
[06:37] <carlos> remove depends on the entry
[06:37] <SteveA> okay, so remove is a little different.  but, that should also be handled by the general security
[06:37] <carlos> block and unblock does not depend on the entry
[06:38] <SteveA> so, try: self.context.remove(entry) except: ForbiddenAttributeError  do stuff
[06:38] <SteveA> or just allow the forbidden error to occur
[06:38] <SteveA> but let's look at this as two separate issues
[06:39] <SteveA> the first is that you can abstract out the pattern of these three methods
[06:39] <SteveA> into a do_stuff_across_entries(self, action_callable, notify_callable)
[06:40] <SteveA> where action_callable is a method that does the work like actually blocking / removing, given an entry
[06:40] <SteveA> and notify_callable is a method that does the appropriate notification
[06:40] <SteveA> or maybe just a notification string is enough
[06:40] <SteveA> don't worry about getting the 1 thing 2 things wording right
[06:40] <carlos> the string should be enough, yes
[06:40] <SteveA> this will come automatically later, when we do launchpad l10n
[06:41] <carlos> ok
[06:41] <SteveA> the security stuff is a separate issue.  you can go with what you have, but file a bug about it, that it should use the standard security system rather than checking the details of the user
[06:42] <carlos> SteveA, how can I use the security system if we don't have a specific web page for that object...
[06:42] <carlos> I think I don't know the .zcml code for that, could you give me a hint, please?
[06:42] <carlos> I prefer to fix it now if it's possible
[06:43] <SteveA> i don't want you work on that now.  go with what you've got.  i think it might be a tricky change from where you're at now.
[06:43] <carlos> ok
[06:43] <SteveA> we'll tidy that part up once this is landed properly
[06:44] <SteveA> so, i'll get on with the rest of the review.  thanks for going through these parts with me, carlos.
[06:45] <carlos> SteveA, thanks to you for the input
[06:50] <carlos> SteveA, do you need anything else?
[06:51] <carlos> I need to go out
[06:58] <YuLin> sorry for my being away for a very long time
[06:58] <YuLin> so, the idea is (if I get the point):
[06:58] <YuLin> 1 -  I check whether there are relevant differences between fr_FR and fr_CH
[06:59] <YuLin> 2 - I create the URL manually regarding the distro I want to translate in fr_CH (in the case I've found relevant differences with fr_FR)
[07:00] <YuLin> 3 - I ask for the creation / create a Swiss French team
[07:00] <YuLin> right ?
[07:01] <SteveA> YuLin: check whether there are significant differences.  then, we have two ways to go.
[07:01] <mdke> do you guys want bug reports for broken links in LP?
[07:01] <kiko> mdke, YES :)
[07:01] <SteveA> what i'd recommend is that you look for packages to translate where it makes a difference in this case
[07:01] <SteveA> and translate those by using the URL
[07:01] <mdke> kiko, k
[07:02] <SteveA> if you find some other people who are also interested, and there are enough differences to make it worthwhile, then talk with us again about making a team and making the language more visiable.
[07:07] <YuLin> alright guys
[07:07] <YuLin> thanks for everything =)
[07:07] <YuLin> have a nice evening
[07:07] <YuLin> ;)
[07:31] <bradb_> When do we get the dedicated pqm server?
[07:32] <bradb_> Landing is misery,  peine possible, without.
[07:42] <ether3> hi I'm one of the admins of the openssi-team, but I can't add a calendar event on the project page.  Is there a bug for this already?
[07:42] <ddaa> bradb_: you're defacing French...
[07:43] <ddaa> " peine possible"
[07:44] <ddaa> we do not have this twiddly diacritical the spaniard are so fond of.
[07:44] <bradb_> we do here
[07:44] <bradb_> c'est  dire, icitte
[07:45] <ddaa> mh
[07:45] <bradb_> :)
[07:45] <ddaa> looks like an encoding problem
[07:45] <bradb_> indeed
[07:45] <bradb_> i see boxes when you type. do you see boxes when i type?
[07:45] <ddaa> Na, I see "Atilde"
[07:46] <ddaa> except the symbol
[07:46] <bradb_> ew
[07:46] <ddaa> looks like my gaim thinks it's using latin1... weird my locale is en_GB.UTF-8
[07:54] <kiko-afk> hey niemeyer
[07:54] <niemeyer> Hiho
[08:02] <SteveA> bradb: i see A+tilde when you type that.  like .  I'm pretty sure i'm using utf-8.
[08:03] <mdke> triangular boxes?
[08:04] <mdke> s/triangular/diamond
[08:05] <kiko-afk> so am I
[08:05] <mdke> i see diamond boxes, in irssi
[08:05] <SteveA> kiko-afk: do you see e with a dot on top:
[08:06] <bradb_> hmph
[08:06] <kiko-afk> SteveA, yes, though the char is very faint!
[08:08] <bradb_>  -- better?
[08:08] <mdke> i get the diamond box there
[08:08] <mdke> but i think that is a well known issue with irssi
[08:11] <SteveAirssi> tries to write
[08:11] <SteveA> aha
[08:11] <SteveA> that was supposed to be
[08:11] <bradb_> madness
[08:12] <bradb_> normally I use Colloquy on OS X so that I don't have to think about such things
[08:13] <SteveAirssi> testing
[08:13] <SteveAirssi> aha
[08:14] <SteveA>  /set term_charset UTF-8 in irssi
[08:14] <SteveA> bradb: there you go
[08:15] <kiko-afk>
[08:15] <bradb_> SteveA: i already tried that
[08:15] <mdke> :)
[08:15] <sivang> SteveA: never worked for me as well, irssi problem?
[08:16] <bradb_> an my gnome terminal is set to UTF-8
[08:16] <bradb_> s/an/and/
[08:17] <Seveas> Is there a way to remove people from the inactive members list in a group?
[08:19] <salgado> Seveas, not yet, but there'll be one
[08:19] <Seveas> salgado, gracias
[08:20] <Seveas> any ETA on that already?
[08:20] <Seveas> or is it just in the list of features-to-come? :)
[08:20] <bradb_> SteveA: when do we get a new version of Zope 3, btw? I'm anxious to write a lot of tests for a lot of untested things.
[08:21] <salgado> Seveas, it was speced during UBZ, but I haven't started implementing it yet
[08:22] <Seveas> salgado, thanks again, good to know that it'll be implemented :)
[08:22] <salgado> Seveas, you're welcome. :)
[08:22] <SteveA> bradb_: as soon as i can.
[08:23] <bradb_> ok :)
[08:28] <niemeyer> ddaa: Where are you currently working on? branches branch?
[08:28] <ddaa> I just started working on importd2bzr.
[08:28] <ddaa> Not yet done my first commit.
[08:29] <ddaa> The branches branch is merged.
[08:29] <ddaa> I do not plan to commit anything new there.
[08:30] <ddaa> Up to now, was busy gathering info for you and putting the importd deployment into the bzr brave new world.
[08:31] <niemeyer> ddaa: Is it pushed already?
[08:32] <ddaa> Since I've not done my first commit, you can consider it's published at rocketfuel/launchpad/devel :)
[08:33] <ddaa> I think we should not merge one another. These branches can land independently. That will make smaller reviews.
[08:34] <niemeyer> ddaa: Was there a commit on rocketfuel though? ;)
[08:35] <ddaa> niemeyer: many, but I don't claim all the credit :)
[08:35] <niemeyer> ddaa: Yes, you're right.. even though depending on what you're doing we can break each other. But that's what bzr is for, right? :)
[08:36] <niemeyer> ddaa: What I meant is that if we wanted to work on similar branches, I wouldn't be able to branch from rocketfuel since I could get something else. But no big deal..
[08:36] <ddaa> yeah, since I'm making a new launchpad/script, there's a significant risk we step on one another's toes, but the smoother review is worth taking the risk.
[08:37] <niemeyer> ddaa: launchpad/script?
[08:37] <niemeyer> Are you changing bzrsync?
[08:37] <ddaa> I mean launchpad/scripts
[08:38] <ddaa> No, that's the driver for the custom baz2bzr lifeless promised for this week.
[08:38] <ddaa> Entirely new code.
[08:38] <niemeyer> Ack
[08:38] <ddaa> Will be my first venture alone into bzrlib :)
[08:40] <niemeyer> ddaa: Don't forget your towel..
[08:40] <niemeyer> ddaa: And more importantly, don't panic.. :)
[08:41] <ddaa> Not this week. I plan on panicking mid-january :)
[08:45] <niemeyer> ddaa: You may panic when you discover that .remove() is in WorkingTree, and .add() is in Branch, for instance. :)
[08:46] <ddaa> *gasp*
[08:46] <niemeyer> ddaa: That's the kind of thing that a pie makes to a man..
[08:46] <ddaa> I just need to do sftp pull and push, and some checking around that.
[08:47] <ddaa> and calling baz2bzr
[08:48] <ddaa> hint: press "?"
 [Yn] "
[08:49] <ddaa> I find that a reasonably intuitive interface
[08:49] <niemeyer> bradb: Is it a question? "You're sick?"
[08:49] <ddaa> bradb_: bad faith, the shelve question accepts a "yes" answer.
[08:49] <bradb_> ddaa: the point is this: to me "y" means yes. If the question is "did you like it or did you hate it?" what does the answeer "yes" mean?
[08:49] <bradb_> s/answeer/answer/
[08:50] <ddaa> bradb_: it's "do this, or do something else"
[08:50] <niemeyer> "no"
[08:50] <ddaa> "no" does not work
[08:50] <ddaa> but "yes, do this" works
[08:51] <ddaa> the alternative is "please do something else"
[08:51] <ddaa> maybe I have been exposed to Vorlon rethoric for too long...
[08:52] <bradb_> ddaa: you too close to the source dude :)
[08:52] <bradb_> s/you/you're/
[08:52] <bradb_> or the legacy of it, in any case
[08:52] <ddaa> Mh... in Vorlon rethoric, when one is close to the source, the thing to say is "Jump".
[09:20] <niemeyer> See ya
[09:31] <tristee> alguien habla espaol?
[09:35] <kiko> si hombre
[09:35] <kiko> que pasa
[09:37] <tristee> al cuanto tiempo
[09:37] <tristee> llega los cd de ubuntu
[09:40] <tristee> kiko ?
[09:41] <kiko> tristee, entre 4 e 12 semanas
[09:41] <kiko> y 12
[09:42] <tristee> mas no?
[09:47] <lifeless> morning
[09:49] <lifeless> ddaa: we have fields in the db for that diagnostic
[09:56] <dsas> Hi people, I've got a quick rosetta question: What's the typical criteria for joining a translation team ?
[09:57] <dsas> (for a ubuntu team) or is that a question for another channel?
[10:00] <sivang> dsas: well, I guess that depends on the lanugage you want to join translating in, and maybe on past translation work that you do. At least that's how I filter my translation team approvals. (I tend to try and see how many good translations were done by each requester)
[10:01] <sivang> dsas: since approved translator can actually overide others work, it's important to gain trsut in them before approving them
[10:02] <dsas> ahh, only en_GB, I made 25ish "suggestions", but then thought maybe I should join the team first...So I applied and haven't heard anything back - so thought I'd misread some criteria or something....
[10:02] <sivang> dsas: well, bnetter ask the administrator for that team
[10:03] <sivang> dsas: I mean, directly. Basically if he's happy with you, he would probably go ahead and approve you.
[10:03] <dsas> Yeah I dropped him an email a few days ago...there's been about 6 other people apply via launchpad who haven't been accepted too.
[10:04] <dsas> or rejected.
[10:05] <dsas> although the guy (mez) is a ubuntu developer and admins a bunch of other groups.. he's probably got a lot of other stuff on, i may just be being impatient :)
[10:06] <sivang> dsas: interesting. he hasn't come online for a few days, IIRC
[10:06] <sivang> dsas: (I know him)
[10:08] <dsas> sivang: ahh ok, that probably explains things...I'll drop him a mail in a week to see what's happening.
[10:08] <sivang> dsas: yes, that was going to be my next suggestion :) cool then, let me know if you didn't get anything sorted by next week ok?
[10:08] <dsas> Wouldn't it be useful for a group to have more than one administrator wherever possible? That way if one person is busy another can pick up the slack?
[10:09] <dsas> sivang: will do :)
[10:09] <sivang> dsas: that is a great idea, you can bring this up on today's CC meeting (roghly 50 minutes from now, #ubuntu-meeting)
[10:10] <sivang> dsas: 10:00UTC to be more precise
[10:11] <dsas> sivang: Thanks, that gives me plenty of time to get some toast :) I'll come along.
[10:12] <sivang> dsas: cool
[10:38] <ddaa> lifeless: what diagnostic?
[10:39] <lifeless> ddaa: 'what branches were mirrored today'
[10:39] <ddaa> gn?
[10:39] <ddaa> what are you answering to?
[10:39] <lifeless> you and stub about cron job output
[10:40] <ddaa> that was not about mirorring
[10:40] <lifeless> it was about bzrsync right ?
[10:40] <ddaa> yes
[10:40] <lifeless> which is (in my head) the second step of mirroring
[10:41] <lifeless> its what I meant anyway ;0
[10:41] <ddaa> you can see it that way, but it's done by a different subsystem, asynchronously
[10:41] <lifeless> indeed
[10:41] <ddaa> BTW, I think bzrsync is indeed abusing the the mirroring status field.
[10:41] <ddaa> But that's for the supermirror, not bzrsync.
[10:41] <lifeless> probably. Maybe we should have two fields ?
[10:43] <ddaa> I think it would indeed make sense to have a set of fields for driving and monitoring bzrsync.
[10:44] <ddaa> BTW, I'd like this bazaar scanning thing to be called bazaard.
[10:44] <ddaa> parallel to importd
[10:44] <lifeless> well
[10:44] <lifeless> if we have a smart server
[10:44] <lifeless> bazaard should be that
[10:44] <lifeless> so, I think bazaard for bzrsync would be squatting
[10:45] <ddaa> couple of thoughts about that:
[10:45] <ddaa> bazaard does not squat, in the context of launchpad
[10:45] <ddaa> and I'd think about the smart server as bazaarserv or something like that.
[10:45] <lifeless> sure it does, as a smart server running on the supermirror is maintained by the same folk
[10:46] <lifeless> httpd; smtpd; ftpd; there is a long history of 'the thing that implements the server protocol being PROTOCOL+d'
[10:46] <ddaa> buildd
[10:46] <ddaa> importd
[10:46] <lifeless> right
[10:46] <lifeless> importd does imports
[10:46] <lifeless> buildd does builds
[10:47] <lifeless> bazaard should do bazaar. And we have multiple bazaar things in play
[10:47] <ddaa> bazaard does bazaar, that is the branch view in launchpad
[10:47] <lifeless> bzrsyncd
[10:47] <ddaa> That's starting to be too long an argument for its own sake. But I'd like to say that this "sync" concept makes me uncomfortable.
[10:48] <ddaa> It's not syncing anything, it's scanning, scraping, importing...
[10:49] <ddaa> btw I already sent a rt for creating a bazaard user.
[10:49] <lifeless> cool
[10:49] <lifeless> ish
[10:50] <lifeless> so, find a name++. using bazaard for this--.
[10:51] <ddaa> so, backto previous topic
[10:51] <ddaa> I think it would indeed be useful to have a set of field to drive whateverd
[10:51] <ddaa> and monitor
[10:52] <lifeless> agreed
[10:52] <ddaa> last successful sync time, last success status, whether an immediate sync is requested, maybe last attempt timestamp.
[10:52] <ddaa> But it's not for right now.
[10:52] <lifeless> right.
[10:52] <lifeless> bzrscand perhaps ?
[10:53] <lifeless> anyway, please consider the name heavily, I'm very uncomfortable with bazaard for this task.
[10:54] <ddaa> okay, I'll pick some other name
[10:55] <ddaa> i need to leave now, tomorrow I'd like to have a chat with you about the security implications of the stuff I have drafted this weekend to become the actual daemon.
[10:55] <lifeless> ok
[10:55] <ddaa> you know, my replacing-buildbot pet peeve :)
[10:55] <lifeless> I suggest you email me
[10:55] <lifeless> because I have slug and acs this week
[10:56] <ddaa> good idea, I'll CC niemeyer and Kinnison, as we'll be looking for opportunities to consolidate with buildd.
[10:56] <lifeless> given the various moving parts, I'm not at all sure replacing is the right thing, so I'd really like to see a gap analysis
[10:58] <ddaa> The gap is simple: buildbot cannot do non-trivial scheduling.
[10:58] <lifeless> email
[10:58] <ddaa> ok
[10:58] <ddaa> cya
[11:09] <lifeless> night
[11:14] <jordi> kiko-afk: man, you made it back
[12:00] <kiko-afk> jordi, so I did, so I did
[12:01] <jordi> kiko-afk: how did the adventure end?
[12:01] <kiko-afk> in new york a few days later
[12:02] <kiko-afk> I ended up rushing to the airport too, can you believe it?
[12:02] <jordi> heh
[12:02] <jordi> was it at direct flight?
[12:03] <kiko-afk> yes, nyc to so paulo