[12:10] <lucas> hi
[12:11] <lucasd> hello
[12:11] <lucas> where should I report bugs about launchpad ?
[12:12] <Kinnison> in malone, against the launchpad product
[12:12] <Kinnison> ideally :-)
[12:13] <lucas> maybe you can check my bug first
[12:13] <lucas> https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bugs <= no bugs shown
[12:13] <lucas> https://launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bug/6684 <= but there's one, marked fix commited
[12:13] <Ubugtu> Malone bug 6684: "backgrounds (Ubuntu) - gnome-backgrounds: merge new debian version" Fix req. for: gnome-backgrounds (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: Fix Committed http://launchpad.net/bugs/6684
[12:15] <lucas> (and there's no Advanced button)
[12:16] <njs> flashplugin-nonfree != gnome-backgrounds?
[12:16] <lucas> arg
[12:16] <lucas> wrong link
[12:16] <lucas> https://launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bug/6684 <= bug
[12:16] <Ubugtu> Malone bug 6684: "backgrounds (Ubuntu) - gnome-backgrounds: merge new debian version" Fix req. for: gnome-backgrounds (Ubuntu), Severity: Normal, Assigned to: MOTU Reviewers Team, Status: Fix Committed http://launchpad.net/bugs/6684
[12:16] <lucas> https://launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bugs <= no bugs
[12:30] <mpt> oh dear
[12:31] <mpt> so the source package bugs page should have links to "All bugs ever reported" etc, like the product bugs page does
[12:31] <mpt> but https://launchpad.net/distros/ubuntu/+source/gnome-backgrounds/+bugs-all doesn't even work :-(
[12:32] <lucas> I reported it
[12:32] <lucas> it is now this bug
[12:32] <lucas> https://launchpad.net/products/malone/+bug/6695
[12:32] <Ubugtu> Malone bug 6695: "Some bugs are missing from the list" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6695
[12:37] <mpt> lucas, ok, I also reported bug 6697 about the missing links
[12:41] <lucas> ok
[12:41] <lucas> good night
[12:41] <mpt> night
[12:42] <njs> random curiosity: what's the theory on the + signs all over the urls?
[12:43] <ajmitch> a zopism, I think
[12:46] <mpt> njs, the general answer is that it's used to distinguish subsets of things from stuff that applies to things
[12:47] <mpt> e.g. if the next version of Ubuntu after Dapper was codenamed Bugs, /distros/ubuntu/bugs (stuff about that release) would be distinct from /distros/ubuntu/+bugs (bug reports on Ubuntu in general)
[12:48] <mpt> not that that's a particularly likely example, but there are lots of +something URLs and there would probably be a clash eventually if we didn't use the +s
[12:50] <lucasd> mpt, to have all those slashes (/) in the URL, is there a lot of folders?
[12:50] <lucasd> or are those functions or classes?
[01:01] <mpt> there's no folders
[01:01] <mpt> it's all zope magic
[01:01] <lucasd> hmm.. that's what I was thinking
[01:02] <lucasd> mpt, what zope version is being used?
[01:04] <Seveas> zope3
[01:06] <lucasd> unfortunately, at Ubuntu repositories, the zope version is 2.6
[01:06] <ajmitch> we have zope 2.8 & zope 3.1
[01:06] <ajmitch> zope 2.6 has been dropped
[01:07] <ajmitch> hopefully 3.2 & 2.9 before upstream version freeze for dapper
[01:07] <lucasd> ajmitch, 3.1 ?
[01:07] <ajmitch> yes
[01:08] <ajmitch> see the zope3 package
[01:08] <lucasd> ajmitch, there are only python libraries ;/
[01:09] <ajmitch> no, it's in breezy & dapper
[01:10] <lucasd> hm.. i'll try to install it again
[01:25] <lucasd> ajmitch, can you help me with zope.. it doesn't start :/
[01:25] <lucasd> can you?
[01:25] <ajmitch> I can
[01:26] <ajmitch> but best not to take up this channel for it
[01:26] <lucasd> ajmitch, can we go to pvt?
[01:27] <ajmitch> if you wish
[03:58] <stub> lifeless: Have you had a chance to look at that bzr exception I got trying to cherry pick into the production branch? I'll need to try generating and applying a diff manually if I can't do the merge.
[03:59] <lifeless> stub: no sorry. it will be another encoding bug - it -may- be fixed in head.
[03:59] <lifeless> stub: so I need to test the pqm toolchain against head and do another snapshot to fix it or eliminate that as a problem
[04:00] <lifeless> I suggest a manual patch
[04:00] <stub> ok
[05:57] <spiv> lifeless: http://users.rcn.com/python/download/Descriptor.htm
[06:09] <wadeb> hello, can anyone give me a general direction to go for getting my OSS application localized?  I would like to make it available in additional languages.
[06:22] <spiv> wadeb: https://wiki.ubuntu.com/RosettaFAQ#head-b356f13978780b88ed4844602554339ac2c33774
[06:22] <spiv> wadeb: Also https://launchpad.net/rosetta/+about
[06:28] <wadeb> thanks!  the faq seems a bit geared towards translators as opposed to developers though.
[06:28] <wadeb> I had already imported my project into launchpad- https://launchpad.net/products/cuecard.  I'm having a hard time finding where to announce it, find translators, or even upload the .po file :)
[06:30] <wadeb> also, is it common for projects that are not part of a standard distribution to be translated by those teams?  or should I concentrate on getting my program included in edubuntu first and translation later?
[06:30] <spiv> Hmm: https://launchpad.net/products/cuecard/+translations
[06:31] <spiv> You're more than welcome to use launchpad to translate an upstream project that isn't yet part of a distribution.
[06:31] <spiv> I think we have a few projects being translated that aren't distro-centric
[06:33] <spiv> So, it appears you should mail rosetta@ubuntu.com (or talk to daf or carlos on irc when they wake up) about getting started.
[06:33] <wadeb> okay great, thanks- I will send an email there and also get as far as I can with the web page
[06:36] <spiv> wadeb: Oh, and see the "I don't see the upstream project in Rosetta, how can I import it?" part of the RosettaFAQ
[06:37] <spiv> wadeb: You should add your project to https://wiki.ubuntu.com/RosettaPendingImports
[06:46] <wadeb> spiv: okay, I'm preparing my tarball with pot & po's to add to that page
[06:52] <marc^> how long does shipit usually take to send ubuntu CDs ?
[06:56] <spiv> 6-8 weeks, iirc.
[06:57] <spiv> Actually, 4-6 weeks, according to the FAQ in the google cache.
[06:57] <spiv> For some reason, the FAQ link on shipit.ubuntu.com appears to be broken.
[07:03] <wadeb> spiv: okay, it's gtg.  thanks for your help!  btw, any idea where to start on getting my project into edubuntu?
[07:03] <Burgundavia> wadeb, #edubuntu
[07:04] <wadeb> burgundavia: cool, thanks
[08:15] <Keybuk> hey guys, bradb especially
[08:15] <Keybuk> I had a bug in Malone on udev that was actually on initramfs-tools
[08:15] <Keybuk> and I wanted to transfer it to that, have Adam subscribed to it, and me removed
[08:15] <Keybuk> is there a one-step operation for that?  It took me about six steps and I still couldn't figure out how to unsubscribe to the bug
[08:16] <Keybuk> (and I'm not sure I even managed to get it assigned to Adam)
[08:17] <lifeless> mmm, probably not. But one would be nice
[08:17] <lifeless> the basic thing will be to request a fix in ubuntu, on the initramfs-tools, close the udev task and assign the initramfs one to adam
[08:19] <Keybuk> how do I assing that?
[08:19] <jamesh> you can reassign a bug task between different packages in a particular distro, or between upstream products
[08:19] <Keybuk> I did a "Request Fix in initramfs-tools" thing
[08:19] <jamesh> without rejecting one task and creating a new one
[08:19] <Keybuk> then rejected the fix in udev
[08:19] <Keybuk> jamesh: you can?  how?
[08:19] <jamesh> Keybuk: click on the task in the table at the top, then change the package name
[08:19] <Keybuk> jamesh: lol
[08:20] <Keybuk> wow, how undiscoverable is that?! :p
[08:20] <jamesh> clicking on the pacakge name to change it? :)
[08:20] <Keybuk> yeah
[08:21] <jamesh> so you could easily change the assignee + package name in one go
[08:21] <Keybuk> ok, that's easier then :p
[08:21] <jamesh> that doesn't unsubscribe you though
[08:21] <Keybuk> I do wish that the change things form was all in one place
[08:21] <jamesh> the new assignee should get email though
[08:21] <Keybuk> rather than spread into little kibbles
[08:22] <jamesh> Keybuk: soon you'll be able to add a comment from the task edit page
[08:27] <Keybuk> there's no "reassign to the owner of the package" operation?
[08:30] <mpt> Keybuk, I'm doing a spec today to make the changing things all on one page
[08:44] <Keybuk> ...
[08:44] <Keybuk> in spec-tracker, what's the difference between Status=Implemented and Expectation-of-Delivery=Done ?
[10:08] <jordi> buenos dias launchpad
[10:09] <niemeyer> Hiho!
[10:09] <stub> ho
[10:14] <sivang> buenos noches jordi :)
[10:14] <sivang> yo niemeyer , 'sup?
[10:17] <SteveA> hi
[10:18] <SteveA> i'm in a meeting all day.  Ping me for urgent urgent stuff, and I'll look at irc occassionally.
[10:20] <ajmitch> hey niemeyer 
[10:21] <SteveA> hi carlos
[10:21] <carlos> morning
[10:21] <SteveA> i read that there's been problems with your changes to some rosetta scripts
[10:21] <SteveA> you can get lifeless or jamesh to help you get it tested better
[10:23] <carlos> SteveA, yeah, seems like there are some bugs with paths not tested..
[10:24] <carlos> SteveA, that would be really good. I'm fixing the problems we find but it't not optimal
[10:24] <jordi> carlos: should I post a msg to the list warning about the queue problems?
[10:24] <carlos> stub, I think we should have staging testing the scripts too... Do you think it would be too difficult?
[10:25] <carlos> jordi, yes please, it's the third bug that stops it to be running. But let me fix this one and hope there is no other bugs around, ok?
[10:25] <stub> That won't help poimport though unless people upload files to staging though, will it?
[10:25] <carlos> SteveA, btw, 'make lint' seems like didn't see the latest missing import...
[10:26] <carlos> stub, I would do that testing
[10:26] <stub> I can easily switch on cronjobs on staging though if they don't rely on email (and me or someone else can fix the staging email setup if that is a problem)
[10:26] <carlos> stub, well, our scripts send emails
[10:26] <carlos> I think that sometime ago you suggested to redirect all that email to a single mailing list
[10:26] <carlos> for debugging purposes
[10:27] <carlos> jordi, btw, could you email the mailing list announcing that dapper translations will not be open until February?
[10:27] <stub> Yes - just needs some work to do that. Nothing dramatic - just nobody has done it yet.
[10:27] <jordi> carlos: ok.
[10:28] <carlos> jordi, I was talking yesterday with kiko and Kinnison and we need to have Ubuntu using launchpad to generate the packages on production to get them imported
[10:28] <stub> poimport won't be an issue though, as it will only spam people who upload stuff to staging (I can clear the queues on update)
[10:28] <carlos> jordi, and that's planned for February
[10:28] <jordi> k
[10:28] <stub> But you still need a poimport.py test if there isn't one already
[10:28] <carlos> stub, we have such tests
[10:28] <carlos> stub, but they are not testing all possible paths
[10:28] <carlos> that's the problem
[10:29] <carlos> every bug we get I fix it + add a test
[10:29] <stub> Yup. But if the infrastructure is there, that lowers the barrier greatly for improving that coverage.
[10:29] <jordi> carlos: import queue is supposed to be ready tomorrow, right?
[10:29] <carlos> jordi, don't say anything about that
[10:29] <jordi> k :)
[10:29] <carlos> jordi, I will do an easy fix now and ask for a fast review
[10:30] <stub> Do kiko's lint targets in the Makefile still work btw?
[10:30] <carlos> perhaps today could be done, if stub can do the cherrypick
[10:30] <carlos> stub, it does not break but it missed latest problem
[10:30] <carlos> we have with poimport
[10:32] <carlos> lifeless, jamesh hi, around?
[10:32] <carlos> carlos@aragorn:~/Work/Canonical/trivial$ make lint
[10:32] <carlos> carlos@aragorn:~/Work/Canonical/trivial$
[10:32] <carlos> stub, no, it's not working at all
[10:33] <stub> I suspected it hadn't survived the bzr migration
[10:34] <stub> I guess ideally it could be rewritten as a bzr plugin?
[10:34] <stub> Maybe that is overkill...
[10:42] <stub> ddaa: Looks like the 'No topic matched' filter for launchpad-error-reports is not going to work. It seems that a message can match more than one topic, so if you subscribe to that topic all that happens is you get all emails.
[10:50] <jamesh> carlos: yeah
[10:52] <ddaa> stub: what I suggest what a regexp that matches _nothing_
[10:52] <ddaa> stub: dunno how you can do that, maybe "^$"
[10:52] <ddaa> (well, that's close enough to nothing)
[10:52] <stub> Oh... yes. I can do that
[10:53] <uws> ddaa, stub: if not len(yourstring)
[10:53] <uws> That's faster than a ^$ regex check
[10:53] <ddaa> uws: you're -ECONTEXT :)
[10:53] <ddaa> we're talking mailman configuration
[10:54] <stub> ddaa: Done
[10:54] <ddaa> stub: BTW, what do I need to do to get the bzrsyncd emails on launchpad-error-reports?
[10:55] <ddaa> I guess I should set something in the crontab, and you should subscribe bzrsyncd@gandwana to be able to post.
[10:55] <stub> Make the output go to launchpad-error-reports@lists.canonical.com 
[10:55] <stub> MAILTO=launchpad-error-reports@lists.canonical.com
[10:56] <stub> (in the crontab)
[10:56] <stub> Messages from gandwana will already have access (or I will get told by Mailman and make it so)
[10:56] <ddaa> okay...
[10:57] <stub> I've added a topic
[10:59] <ddaa> thank you for the "ro" user thing for importd2bzr.
[10:59] <ddaa> now I need to make that damn script to _actually_ work DAMNIT!
[11:00] <carlos> jamesh, SteveA suggested me to ask you for help to improve the testing of Rosetta's poimport
[11:00] <uws> ddaa: Ah :)
[11:01] <jamesh> carlos: okay.  Are there particular areas that are of concern?
[11:06] <carlos> jamesh, well, we have some tests
[11:07] <carlos> jamesh, but some of the paths are not tested at all as we get bugs when we move into production
[11:07] <carlos> I'm adding tests while fixing them
[11:07] <carlos> but I think we need to take a closer look to the script testing
[11:08] <jamesh> carlos: is it the main driver script, or the doRawImport() code, something else, or a combination?
[11:08] <carlos> jamesh, the main driver
[11:08] <carlos> jamesh, we have tests for doRawImport
[11:08] <carlos> and tests for other parts
[11:09] <carlos> we also have tests for the main driver script but as seen from the cron run, we are missing tests
[11:11] <jamesh> carlos: it might help to split the run() method in po_import.py down a little
[11:11] <sabdfl> stub: ping
[11:11] <jamesh> carlos: one method that is a simple "get next object to import" (which should be quite easy to test)
[11:11] <stub> sabdfl: pong
[11:12] <sabdfl> stub: elmo asked me about an emperor upgrade, do you have a sec to discuss that?
[11:12] <stub> sabdfl: Sure
[11:12] <jamesh> carlos: and then try and simplify the rest of the logic: you shouldn't need as many try/execpt clauses
[11:13] <jamesh> carlos: a simple "doRawImport(); ztm.commit() inside a try block, with two except clauses should be enough
[11:13] <carlos> jamesh, well, there are only two of them
[11:13] <jamesh> the first except being to catch KeyboardInterrupt and SystemExit, and just pass the exception on
[11:14] <jamesh> the second being your catch all with the ztm.abort() call
[11:14] <carlos> jamesh, hmm, I was told to not add more than one call inside a try that could raise exceptions
[11:14] <jamesh> carlos: for the type of thing you are doing in run(), it would be appropriate.
[11:15] <jamesh> it would simplify your logic a bit too
[11:15] <carlos> ok
[11:16] <jamesh> carlos: the try/finally block in recentlySeen also seems a bit weird: the code inside the try clause shouldn't ever raise any exception
[11:17] <jamesh> it would be easier to put the contents of the finally: block before the return statement
[11:17] <lifeless> carlos: pong
[11:18] <jamesh> carlos: for methods like recentlySeen(), you should be able to make it easier to test by adding an extra default argument giving the pickle file name
[11:19] <jamesh> carlos: that way you can test it in a controlled environment, without needing to worry about other people writing to your file in /var/tmp
[11:21] <carlos> lifeless, don't worry, it's the same thing I'm talking with jamesh 
[11:21] <carlos> jamesh, right, like we do with the lock file
[11:23] <lifeless> carlos: ah, how to test your script ?
[11:24] <carlos> lifeless, I test some methods directly
[11:24] <carlos> and also call the script directly
[11:30] <lifeless> ok
[11:31] <lifeless> I'll look at this during the meeting - whats the script ?
[11:31] <lifeless> (I'm finishing dinner at th emoment)
[11:31] <stub> I think recentlySeen is known to be broken btw. - there  is a bug report open and a hack on production to work around it
[11:34] <carlos> lifeless, lib/canonical/launchpad/scripts/po_import.py and cronscripts/rosetta-poimport.py
[11:35] <carlos> stub, yeah, I will try to fix it at the same time I improve the tests
[11:35] <daf> bug #?
[11:36] <daf> I can't find it
[11:39] <carlos> daf, https://launchpad.net/products/rosetta/+bug/2934
[11:39] <Ubugtu> Error: I cannot access this bug.
[11:39] <daf> hmm
[11:40] <stub> Hmm... I wouldn't say severity is major - the workaround does the trick
[11:40] <daf> I thought that once an import had been tried, it would be taken off the queue
[11:40] <daf> rather than being tried > 24h later
[11:41] <daf> * retried
[11:58] <dilys> Merge to devel/launchpad: [r=spiv]  fix bug #6372: broken URLs for membership approval (r2985: Dafydd Harries)
[12:07] <daf> Kinnison: the pending branch summary page says the status of your buildd-fixes branch is "unknown"
[12:20] <matsubara> good morning!
[12:21] <ddaa> yay! importd2bzr running!
[12:21] <daf> congratulations!
[12:22] <ddaa> now... I guess I wil need to work on some tools to guesstimate the total runtime...
[12:22] <uws> ddaa: What vcs's does it import from?
[12:22] <ddaa> uws: internal transition of rcs->baz import into bzr branches.
[12:23] <daf> ddaa: your importd2bzr branch still needs merging though, yes?
[12:23] <ddaa> daf: yes, found out yesterday it was still outstanding. I've been having hell with bzr slowness, and pqm rejects my merge with errors that seem to have nothing to do with my code.
[12:23] <daf> suck :(
[12:24] <daf> if you're getting weird test failures, maybe posting to the list might help
[12:24] <ddaa> I'm frankly mystified, I'm running a local merge to check that my branch is not pulling unrelated changes.
[12:24] <ddaa> I will post to the list when I'm positive that it's not stupidity from my side.
[12:24] <daf> ah, so once that's finished in a few days, we might know what's up
[12:25] <ddaa> yup... and that stupid slow iBook does not help... but it would not help much to buy myself another high end lappy, since the thinkpad will probably come back before I've finished setting it up.
[12:25] <daf> oh -- is it sent away for repair?
[12:26] <ddaa> Besides, my GF would go crazy at my buying a THIRD lappy :)
[12:26] <daf> heh
[12:26] <ddaa> yes, USB was fried back in UDU.
[12:26] <uws> Heh, two should be enough
[12:26] <ddaa> well, I'm not sure if that iBook should not be counted as 1/2...
[12:32] <Kinnison> daf: Yeah, I am currently sorting branches out
[12:32] <daf> cool
[12:32] <daf> only semi- ?
[12:33] <ddaa> Kinnison: they got the living blood out of you, so you have to use a wood stove for heating now?
[12:33] <Kinnison> daf: Well, I now know what to do with these share option exercises I had in US$
[12:33] <Kinnison> daf: Now I just have to fill out the rest of the form and do the maths
[12:33] <Kinnison> ddaa: Not quite, I think they've left me with enough for coal-fired heating
[12:39] <ddaa> so, I've got 637k revisions to convert...
[12:39] <lifeless> its running ?
[12:39] <ddaa> yes... mh... I think might have forgotten to ask elmo for celementtree...
[12:41] <ddaa> ha yes, it's there...
[12:43] <ddaa> So, the guesstimate ATM is 44 days
[12:44] <ddaa> Will revise gesstimate monday...
[12:45] <lifeless> ddaa: well - I had hoped we'd be running it mid dec. 
[12:45] <lifeless> ddaa: anyhoo. at least now it is running :)
[12:46] <lifeless> good work
[12:46] <ddaa> we still need a green light from the boss for the output format...
[12:46] <lifeless> has sabdfl...no
[12:46] <lifeless> ok
[12:46] <daf> meeting in 15 minutes -- get your break in now
[12:46] <lifeless> sabdfl: ping ^^
[12:51] <sivang> daf: dev wekly status meeting, eh?
[12:51] <daf> indeed
[12:54] <cprov> good morning 
[12:56] <kiko-zzz> morning
[12:57] <daf> morning guys
[12:57] <daf> hi Seb
[12:57] <kiko> morning daf 
[12:57] <kiko> so
[12:57] <lifeless> good mornink vietnam
[12:58] <kiko> is SteveA around?
[12:58] <carlos> stub, I have a fix + a test for the latest problem with poimport
[12:58] <carlos> stub, the fix is one line, the test is longer
[12:58] <stub> ok
[12:58] <carlos> stub, kiko, SteveA do you have time for a fast review?
[12:58] <seb128> hey here
[12:58] <carlos> https://chinstrap.ubuntu.com/~dsilvers/paste/file8AkQge.html
[12:58] <daf> carlos: did you run the lint script this time? :)
[12:58] <seb128> Hi daf kiko carlos
[12:58] <kiko> lol
[12:59] <carlos> kiko, dude, make lint is useless....
[12:59] <daf> why?
[12:59] <SteveA> hi
[12:59] <lifeless> carlos kicks back ?
[12:59] <daf> hi Steve
[12:59] <mpt> MEETING TIME
[01:00] <SteveA> indeed
[01:00] <SteveA> who's here today?
[01:00] <daf> me
[01:00] <spiv> me
[01:00] <lifeless> noddy
[01:00] <carlos> me
[01:00] <mpt> me
[01:00] <jamesh> me
[01:00] <matsubara> me
[01:00] <carlos> kiko, perhaps is that I don't have pylint installed.... O:-)
[01:00] <kiko> me
[01:00] <ddaa> us, and them
[01:00] <lifeless> uamI ?
[01:01] <stub> yo
[01:01] <stub> carlos: approved. r=stub
[01:01] <carlos> stub, thanks
[01:01] <Kinnison> workrave just finished
[01:02] <daf> Bjrn on holiday?
[01:02] <SteveA> yes
[01:03] <niemeyer> me
[01:03] <SteveA> so, the meeting agenda is out of date
[01:03] <SteveA> let's do this in a more ad-hoc way this time around
[01:03] <jbailey> SteveA: Clearly it can't happen then.  Come back to us. =)
[01:03] <SteveA> any extra items for the agenda
[01:03] <SteveA> ?
[01:03] <lifeless> carlos: for testing scripts, I tend to make main() invokable, so I do it in process
[01:03] <lifeless> oops, sorry, forgot its meeting time ;)
[01:03] <SteveA> as it stands:
[01:04] <SteveA>  * Roll call
[01:04] <SteveA>  * Agenda
[01:04] <SteveA>  * Next meeting
[01:04] <SteveA>  * Activity reports
[01:04] <SteveA>  * Items from last meeting
[01:04] <SteveA>  * Production / staging (stub)
[01:04] <SteveA>  * Keep, Bag, Change
[01:04] <SteveA>  * Three sentences
[01:04] <carlos> lifeless, will answer after the meeting, but that does not work
[01:04] <SteveA> 
[01:04] <spiv> carlos: I'll join that discussion
[01:04] <SteveA> there's the bugzilla->malone conversion tomorrow, 1200 UTC
[01:04] <SteveA> mpt: you have something about "fixing projects"
[01:04] <jblack> here
[01:04] <SteveA> hi jbailey 
[01:04] <SteveA> hi jblack 
[01:04] <mpool> hi
[01:04] <jblack> :)
[01:05] <mpt> SteveA, yes, now?
[01:05] <mpt> or later?
[01:05] <SteveA> also, i'd like to remind jblack, mpool and lifeless that we decided a few weeks ago that you can have a launchpad/bzr meeting at a different time
[01:05] <SteveA> to avoid weekly early mornings for jblack / late nights for lifeless, mpool
[01:06] <mpool> this time does mess up my friday, so that'd be good
[01:06] <ddaa> I guess that would end up at a time I am unable to attend...
[01:06] <SteveA> mpt: i'd rather not discuss that this week because i'm more focused on my meetings in london
[01:06] <carlos> spiv, ok
[01:06] <mpool> SteveA: should anyone else be there?
[01:06] <mpt> ok
[01:06] <SteveA> mpt: can it be put off for two more weeks?
[01:06] <lifeless> mpool: its a slightly different focus
[01:06] <SteveA> then i'll be back in vilnius
[01:06] <lifeless> mpool: so - some folk will go to both
[01:06] <mpt> that's fine
[01:06] <lifeless> mpool: its in the minutes a few weeks back
[01:06] <SteveA> i'd like us to get a good understanding of the situation before approaching mark about it
[01:07] <mpt> but the other item probably needs to be discussed today
[01:07] <mpt> (the state and progress of Malone)
[01:07] <SteveA> ok
[01:08] <SteveA>  * Roll call
[01:08] <SteveA>  * Agenda
[01:08] <SteveA>  * Next meeting
[01:08] <SteveA>  * Activity reports
[01:08] <SteveA>  * Items from last meeting
[01:08] <SteveA>  * Production / staging (stub)
[01:08] <SteveA>  * State and progress of malone (mpt)
[01:08] <SteveA>  * Keep, Bag, Change
[01:08] <SteveA>  * Three sentences
[01:08] <SteveA> 
[01:08] <SteveA> that is the agenda
[01:08] <SteveA> next meeting: same time next week?
[01:08] <SteveA> i will probably not attend, as i'll be on leave
[01:08] <sivang> here
[01:08] <SteveA> hello sivan
[01:08] <ddaa> Who will chair next week's meeting then?
[01:09] <SteveA> kiko or stuart
[01:09] <kiko> if not SteveA, I can
[01:09] <SteveA> i think kiko will be arouind
[01:09] <kiko> of course.
[01:09] <SteveA> if kiko and i were both in meetings / on leave, then i'd ask stuart
[01:09] <lifeless> if kiko isn't, I'd be happy to
?
[01:09] <SteveA> lifeless: when you have the other meeting sorted out, i expect you not to attend launchpad ones always
[01:10] <SteveA>  * activity reports
[01:10] <SteveA> who's hot, and who is not?
[01:10] <mpt> up to date
[01:10] <daf> hot
[01:10] <lifeless> SteveA: sure. that will be nice... though I find missing .uk time meetings hurts - see the mgmt ones 
[01:10] <ddaa> hot as hot coals
[01:10] <mpool> think i'm ok
[01:10] <lifeless> burning
[01:10] <jamesh> not up to date
[01:10] <jblack> I am solar
[01:10] <spiv> I'm up to date.
[01:10] <jblack> kinnison is up to date
[01:10] <Kinnison> jblack: yes, I already said that
[01:10] <jblack> kinnison: Stevea has trouble with /me's. 
[01:11] <matsubara> up to date
[01:11] <kiko> I've been average -- sent all but three of reports due
[01:11] <niemeyer> I'm kind of out of date.. the sprint will probably be on a single entry
[01:11] <Kinnison> jblack: You what?!?!
[01:11] <kiko> Kinnison, "you"?
[01:11] <stub> up to date
[01:11] <SteveA> for the roll call, it is easy to miss what someone said if they emote on irc, while everyone else is saying
[01:12] <SteveA> jblack was alluding to that
[01:12] <Kinnison> oh right
[01:12] <carlos> I'm behind
[01:12] <Kinnison> sorry
[01:12] <Kinnison> force of habit
[01:12] <SteveA> i emoted this time too
[01:12] <SteveA> oh well
[01:12] <SteveA> thanks for the note jblack
[01:12] <Kinnison> jblack: yeah, ta
[01:12] <jblack> stevea is up to date too. =)
[01:12] <SteveA> jamesh: can you send a summary of what you've been working on to the activity list please?
[01:13] <SteveA> jblack: actually, i'm not
[01:13] <daf> jblack: no he's not :)
[01:13] <jamesh> SteveA: okay
[01:13] <SteveA> let's move along
[01:14] <mpt> let's
[01:14] <SteveA>  * Items from the last meeting
[01:14] <daf> (done)
[01:14] <SteveA> daf: will you summarize this meeting too?
[01:15] <daf> certainly
[01:15] <SteveA> please look at the previous summaries on the wiki
[01:15] <SteveA> there are various things in the summaries that you may find useful
[01:15] <SteveA> for example, using MeetingAction and ItemForNextMeeting tags
[01:15] <daf> I did look through them and tried to follow the style
[01:15] <SteveA> to help with searching through it
[01:15] <daf> MeetingAction is something I omitted; I'll rectify that this time
[01:15] <SteveA> use whatever you think will help
[01:16] <SteveA> thanks daf
[01:16] <SteveA>  * Production / staging (stub)
[01:16] <stub> Production upgrade to hoary and PostgreSQL 8.0 appears to have gone well. It seems to have improved timeouts much better than I expected (or perhaps I've just been lucky).
[01:16] <stub> Initial steps have also been taken to avoid batch jobs (karma, cache updates) running at the same time.
[01:16] <stub> Nothing thrilling to report about staging.
[01:16] <pitti> hi
[01:17] <stub> I guess we will find out for sure about the timeouts next time we analyze the exception reports
[01:17] <daf> pitti: welcome
[01:17] <kiko> stub, SteveA, jamesh: what's the status on the report analysis?
[01:18] <jamesh> kiko: I've ported your script, and made a few improvements.  I am going to write up a few cron jobs to generate regular reports on chinstrap
[01:18] <jamesh> kiko: and do up a simple CGI script to display OOPS reports without you having to hunt for the filename
[01:18] <kiko> jamesh, that'd be great, because we've been without regular reports for almost a month now
[01:19] <daf> jamesh's OOPS summary script is awesome
[01:19] <jamesh> kiko: with my latest branch, we can get OOPS reports for requests that took longer than we'd like without us timing them out for the user
[01:19] <niemeyer> kiko: What are these reports about?
[01:19] <niemeyer> OOPS reports?
[01:19] <kiko> niemeyer, the most common errors occurring in production
[01:19] <niemeyer> Ah, ok
[01:20] <jamesh> to help catch problems before users notice
[01:20] <niemeyer> Nice idea
[01:20] <sivang> jamesh: will it be easy to find out the OOPS reason on the cgi front ?
[01:20] <sivang> jamesh: even if they are not just, plain, timeouts.
[01:20] <jamesh> sivang: the OOPS report includes a full traceback, and information about the user, URL, etc
[01:21] <sivang> k, I see.
[01:21] <jamesh> (you won't get a traceback for soft timeout OOPS reports though)
[01:21] <daf> will we get a list of executed queries for soft timeouts?
[01:22] <SteveA> cool
[01:22] <jamesh> daf: that's the other thing we'll be having soon.  And yes, you will get the list of queries in this case
[01:22] <daf> jamesh: great!
[01:22] <SteveA> is there a control for the soft time-out in the config file?
[01:22] <jamesh> SteveA: yes.
[01:23] <SteveA> i think we should start by having a large hard time-out, and a much lower soft time-out
[01:23] <SteveA> so that our users will see very few timeouts
[01:23] <kiko> SteveA, the downside to that is that the server can get overbombed
[01:23] <SteveA> and then lower it by looking at oops reports
[01:23] <SteveA> and lower to a level where we still don't get many hard timeouts
[01:24] <mpt> so maybe stub can decide on the hard timeout based on how much the server can stand at the time
[01:24] <SteveA> kiko: yes, that is something we need to consider too
[01:24] <jamesh> kiko: ideally we'd set the hard timeout to a value that prevents the system from getting overloaded, and the soft timeout to a value we'd expect people to wait for pages
[01:24] <kiko> right.
[01:24] <SteveA> i'd like us to record what we're using for these timeouts
[01:24] <SteveA> week-by-week
[01:24] <stub> We will have a second server online this week so we can keep a large timeout.
[01:24] <SteveA> so that we have some basis to make future decisions
[01:24] <kiko> stub, ah, so the second box is not yet up?
[01:24] <daf> stub: second app server?
[01:25] <stub> kiko: Correct. I've set most of it up but got distracted today
[01:25] <stub> daf: Yes
[01:25] <daf> stub: so we'll be getting A, B, C, D oopses?
[01:25] <stub> Yes
[01:25] <sivang> it's probably be good to run some sort of an analysis to see the most time consuming queries and attempt optimization at them , or split up.
[01:25] <SteveA> we'll eventually get cronscript oopses too
[01:26] <jamesh> sivang: we'll have timing information for queries in the OOPS reports
[01:26] <SteveA> which need their own "server code"
[01:26] <kiko> okay
[01:26] <sivang> jamesh: cool :)
[01:26] <kiko> jamesh, is there an ETA for this stuff, or are there still unknowns?
[01:27] <jamesh> kiko: it appears to be sitting in your review queue :)
[01:27] <kiko> oh don't be cruel
[01:27] <kiko> I'll do it today then.
[01:27] <daf> haha
[01:27] <sivang> heh
[01:27] <SteveA> so the new timeouts levels can be set when that rolls out
[01:28] <SteveA> stub: when is the new server coming on line?
[01:28] <stub> I just need to move some crontrol scripts into place and fire it up, and let the admins know so the oopses can be rsynced and monitoring switched on.
[01:29] <stub> Should be tomorrow
[01:29] <dilys> Merge to devel/launchpad: [r=jamesh]  cleanups of Soyuz-related code in preparation for UI work (r2986: Dafydd Harries)
[01:29] <stub> I believe the load balancer is already configured
[01:29] <SteveA> we need to think how the OOPSes get combined on chinstrap
[01:29] <SteveA> i think we should have two places for these on chinstrap
[01:29] <SteveA> one for staging, and one for production
[01:30] <SteveA> i do not know if it is possible to rsync all into the same place
[01:30] <SteveA> or whether we need to get james' scripts on chinstrap to do the aggregation
[01:30] <stub> It is possible to rsync them all into a single location
[01:30] <stub> (we designed it that way)
[01:30] <jamesh> the analysis script just takes a list of directories as arguments, so it can aggregate from multiple directories
[01:30] <SteveA> we should rsync them into the same place
[01:31] <SteveA> so, on chinstrap, we should have launchpad-production-logs
[01:31] <SteveA> and launchpad-staging-logs
[01:31] <kiko> that sounds okay
[01:31] <SteveA> and get things rsynced into there
[01:31] <SteveA> rather than gangotri-logs and asuka-logs as currently
[01:31] <jamesh> I'll write the CGI script to handle multiple locations (will be necessary for finding both production and staging OOPS's)
[01:31] <SteveA> that needs RT requests
[01:31] <SteveA> and prioritization
[01:31] <SteveA> kiko: would you?
[01:31] <lifeless> will it need RT ?
[01:32] <SteveA> all admin requests need RT
[01:32] <lifeless> I'm not clear what admins are being asked to do
[01:32] <SteveA> move directories, and change rsyncing cron jobs
[01:32] <stub> I can do it. I need to sort with them re: the new servers logs too
[01:32] <SteveA> ok, thanks stub
[01:32] <kiko> cool
[01:33] <SteveA> next production roll-out?
[01:33] <SteveA> it would be nice to get the error reporting improvements out there
[01:33] <stub> Do we need one next week? Anything important landing?
[01:33] <SteveA> error reporting improvements
[01:33] <kiko> if the error reporting lands, then yeah
[01:33] <stub> Ok. So I can rollout next week from when jamesh's patch lands
[01:34] <stub> Tuesday as normal
[01:34] <kiko> sure.
[01:35] <SteveA> okay, cool
[01:35] <SteveA> moving along
[01:35] <bradb> stub: bug status notes as comments
[01:35] <SteveA>  * State and progress of malone (mpt)
[01:35] <SteveA> and, we're running into the latter portion of our allocated time
[01:35] <mpt> ok, jamesh announced that the distro team would be moving to Malone
[01:35] <SteveA> so, i may push the bulk of this off to a separate meeting
[01:36] <mpt> and some of them are concerned about that
[01:36] <mpt> which is why seb128 and mvo are here, I believe
[01:36] <daf> and pitti and dholbach 
[01:36] <kiko> I've heard concerns as well.
[01:36] <mpt> so first, it would be nice if SteveA or kiko could reply to their concerns on ubuntu-devel
[01:36] <daf> we should migrate to Malone more often -- our meetings have never been so popular
[01:36] <sivang> daf: lol
[01:36] <mpt> if you weren't subscribed, I can redirect you the relevant messages
[01:36] <kiko> I don't get ubuntu-devel email, and I probably shouldn't
[01:36] <SteveA> i'd invite them to talk about it on launchpad-users
[01:37] <ddaa> okay, everybody migrates to HCT next week
[01:37] <ddaa> (heh, kidding!)
[01:37] <kiko> someone did CC: launchpad-users but I've slacked on announcing it, so..
[01:37] <mpt> second, who's in charge of bradb's schedule? :-)
[01:37] <kiko> I'll do that today, I made a plan yesterday
[01:37] <kiko> mpt, bradb is in charge of his schedule, of course
[01:37] <sivang> I'm interested to know what can be done to help users who run into problems , after the migration. (that does not involve code hacking if possible)
[01:37] <kiko> we can help suggest what the priorities are
[01:37] <mpt> well, I see there are two big problems
[01:37] <seb128> kiko: if they are way to roll back to bugzilla in the switch to malone impacts the productivity of the distro team too much?
[01:38] <mpt> 1. it's hard to find bugs
[01:38] <daf> sivang: being on #launchpad to support them is one thing
[01:38] <seb128> s/if/is
[01:38] <mpt> 2. it's really slow to process bugs
[01:38] <kiko> seb128, probably not.
[01:38] <seb128> grumpf (s/if they/is there a)
[01:38] <mpt> so w.r.t. (1), I've just finished https://wiki.launchpad.canonical.com/MaloneSearch
[01:38] <mpt> and it would be nice if parts of that could be implemented week by week
[01:38] <mpt> so at least people can see that things are getting better :-)
[01:38] <daf> mpt: re 1: using google with site:launchpad.net works very well
[01:38] <daf> (in the meantime)
[01:38] <kiko> that sounds pretty good.
[01:39] <mpt> and w.r.t. (2), I'm writing https://wiki.launchpad.canonical.com/BugWorkflow
[01:39] <jbailey> seb128: I don't see how there could be.   Once new data goes into Malone, it's not really trivial to model those changes back in bugzila.
[01:39] <mpt> that's all.
[01:39] <mpt> SteveA, done
[01:39] <bradb> mpt: The sooner the Ubuntu devs switch to Malone, the sooner the problems you mention will be unavoidable to address. :)
[01:39] <SteveA> thanks mpt
[01:39] <seb128> jbailey: hey, me too, I just though I would ask anyway :)
[01:39] <sivang> we should have a list of "temporary remedies" in the stages before finish the touch up. daf : then (1) should be ther e:)
[01:39] <SteveA> there is much we can discuss on this
[01:39] <SteveA> but we don't have time to in today's meeting, because there is 6 minutes left
[01:39] <SteveA> i'd like us to have a meeting for this
[01:39] <daf> I hope the distro guys can count on us to take their complaints seriously
[01:39] <ddaa> bradb: I'm not sure that the distro guys are enthusiastic about suffering to address prioritization issues in our dev process...
[01:40] <lifeless> t-5
[01:40] <seb128> bradb: we don't ship to be kicked down to report bugs, I do for months already
[01:40] <SteveA> so, when for this meeting?
[01:40] <mpt> kiko, can you at least steer matsubara and gneuman in the direction of Malone bugs for the next few weeks?
[01:40] <seb128> s/ship/need
[01:40] <jbailey> daf: You've been quite amazing on the bug triaging so far. =)
[01:40] <SteveA> hang on a minute please
[01:40] <SteveA> i'd like to plan when the "malone for distro team" meeting happens
[01:40] <SteveA> later today is okay with me
[01:40] <SteveA>  and i'll try to take time out from my london meetings for it
[01:40] <SteveA> shall we say at 1300 UTC?
[01:40] <kiko> mpt, I'll look into it.
[01:41] <seb128> bradb: no offense but we barely keep up with bug flood using bugzilla, we are not going to keep up with malone
[01:41] <bradb> 1300 URC sounds good
[01:41] <mpt> is that in one hour?
[01:41] <SteveA> in 20 mins
[01:41] <mpt> oh, right
[01:41] <kiko> that's in 20 yeah
[01:41] <mpt> how time flies
[01:41] <bradb> s/URC/UTC
[01:41] <SteveA> all against 1300 UTC, say now:
[01:41] <SteveA> 5
[01:41] <SteveA> 4
[01:41] <SteveA> 3
[01:41] <SteveA> 2
[01:41] <SteveA> 1
[01:41] <SteveA> done.
[01:41] <SteveA> okay
[01:41] <SteveA> Keep bag change:
[01:42] <SteveA> with a strict countdown....
[01:42] <SteveA> 6
[01:42] <SteveA> 5
[01:42] <SteveA> 4
[01:42] <SteveA> 3
[01:42] <ddaa> CHANGE: unknown dates for march sprint
[01:42] <SteveA> 2
[01:42] <ddaa> CHANGE: bzr fetcher slowness
[01:42] <SteveA> 1
[01:42] <SteveA> 0
[01:42] <SteveA> ddaa: kiko and i are talking about the march sprint tonight, and i'll be talking with mark about it tomorrow
[01:42] <mpt> People keep asking me where I'm travelling this year, and I don't have any idea
[01:42] <SteveA> i expect to have firm dates within the next few days
[01:42] <SteveA> Three sentences:
[01:42] <SteveA> go for it!
[01:42] <ddaa> DONE: catch-up, deploy bzrsyncd, deploy importd2bzr
[01:42] <ddaa> TODO: OptionalBranchTitle, importd->bzr transition
[01:42] <ddaa> BLOCKED: approval of importd2bzr output format
[01:43] <Kinnison> DONE: catchup with three weeks of movement while I was on holiday, dealt with tax, started to map out tool work
[01:43] <matsubara> DONE: fixed bug on +join team not displaying confirmation message, finished the canned search for commented bugs, bug triage, fixed validator for some form fields.
[01:43] <matsubara> TODO: find a reviewer for some of the bugs above, fix more bugs.
[01:43] <matsubara> BLOCKED: nope
[01:43] <lifeless> SteveA: hmm, that might do for the bazaar sprint I was thinking of
[01:43] <daf> DONE: bug 6372, Soyuz code cleanups, Soyuz UI work, bug triage
[01:43] <Kinnison> TODO: tools, more tools, and some tools
[01:43] <daf> TODO: Soyuz UI work
[01:43] <daf> BLOCKED: no
[01:43] <spiv> DONE: supermirror SFTP nearly ready -- 4/5 acceptance tests passing.
[01:43] <spiv> TODO: get supermirror SFTP done, merged and deployed.
[01:43] <spiv> BLOCKED: no
[01:43] <Ubugtu> Malone bug 6372: "approving members broken" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Dafydd Harries, Status: Fix Committed http://launchpad.net/bugs/6372
[01:43] <Kinnison> BLOCKED: nothing right now
[01:43] <jamesh> DONE: error reporting improvements / code reviews / bugzilla migration prep.
[01:43] <cprov> DONE: fix builddmaster to gather buildresults via uploader and queue tool to enable single binary overrride and other minor fixes related to soyuz deployment test and buildd UI
[01:43] <jamesh> TODO: bugzilla migration and fallout / code reviews
[01:43] <jamesh> BLOCKED: no
[01:43] <cprov> TODO: run new Soyuz deployment test schema over breezy-autotest
[01:43] <cprov> BLOCKED: None
[01:43] <stub> DONE: PostgreSQL 8.0 upgrade
[01:43] <stub> TODO: Zope 3.2 update
[01:43] <stub> BLOCKED: Nothing
[01:43] <kiko> DONE: getting back on track with work on LP, soyuz testing, management in general, random bugfixes
[01:43] <mpt> DONE: polish work, landed capitalization branch (yay!), MaloneSearch spec
[01:43] <mpt> TODO: more Malone specs, more polish
[01:43] <mpt> BLOCKED: no
[01:43] <lifeless> SteveA: rather than separate, I'd like to tack a couple of dedicate VCS days on there for the VCS folk
[01:43] <bradb> DONE: Fixed bugs 1440, 6285, 5485, 3712, 4066, and queued up BugStatusChangesAsComments. Moved --story patch into Z3/LP branches on chinstrap.
[01:43] <jblack> DONE: Supermirror deployment refinement, rocketfueldoc touchups
[01:43] <bradb> TODO: Transfer all this code from review queue and approved state into merged.
[01:43] <bradb> BLOCKED: Response from SteveA about how best to integrate --story patch, since it includes a change to our Zope.
[01:43] <SteveA> DONE: reviews, management, travel to london, meetings
[01:43] <SteveA> TODO: meetings
[01:43] <SteveA> BLOCKED: no
[01:43] <jblack> TODO: rocketfuel script refinement, bzr docs!! 
[01:43] <jblack> BLOCKED: none
[01:43] <kiko> TODO: finish some of the trivials, reviews, move on to serious bug triage and assess what our current state of major problems is
[01:44] <kiko> BLOCKED: no
[01:44] <lifeless> SteveA: one sec, forgot to prep them
[01:44] <kiko> ddaa, is bug 1512 still a concern?
[01:45] <ddaa> Ubugtu: bug 1512
[01:45] <Ubugtu> (bug <abbreviation> <number>) -- Look up bug <number> in the bugtracker associated with <abbreviation>.
[01:45] <lifeless> TODO: finalise formats for importd conversion with sabdfl, ddaa, bzr branch format support
[01:45] <Ubugtu> Malone bug 1512: "Admins creating products should be allowed to set owner and is_reviewed" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Christian Reis, Status: In Progress http://launchpad.net/bugs/1512
[01:45] <lifeless> DONE: bzr transport implementation tests, reviews, etc
[01:45] <lifeless> BLOCKED: Zope3 update steve week 8
[01:45] <niemeyer> DONE: Leave days
[01:45] <carlos> DONE: bugs #6410, # 1681 and several poimports fixes
[01:45] <mpool> TODO: finish 0.7; texas travel, etc
[01:45] <niemeyer> TODO: Gantry meeting
[01:45] <mpool> DONE: 0.7rc1, many merges & reviews
[01:45] <mpool> BLOCKED: no
[01:45] <stub> lifeless: Zope3 is on my plate for now
[01:45] <niemeyer> BLOCKED: Nope
[01:45] <lifeless> stub: thanks!
[01:45] <carlos> TODO: Improve poimport tests, finish POMsgSetPage implementation
[01:46] <carlos> BLOCKED: No
[01:46] <ddaa> kiko: it's part of the 1k-importd-death-march thing, still nice to have, but low priority.
[01:46] <daf> t+1
[01:46] <lifeless> stub: I'm looking to use the SVN HEAD test runner - thats the goal.
[01:46] <SteveA> okay
[01:46] <daf> the current Zope test runner code blows goats
[01:46] <SteveA> i'll deal with blockers after the meeting
[01:46] <SteveA> MEETING ENDS
[01:46] <SteveA> ddaa: who needs to approve the importd2bzr format?
[01:47] <lifeless> whers teh KABOOM ?
[01:47] <lifeless> SteveA: sabdfl
[01:47] <SteveA> DOOM
[01:47] <ddaa> SteveA: sabdfl does
[01:47] <mpt> there wasn't time for it, lifeless 
[01:47] <lifeless> the earth shattering KABOOM
[01:47] <SteveA> i'll ask mark about it this afternoon
[01:47] <ddaa> lifeless: just realized we overlooked signing for importd2bzr
[01:47] <SteveA> what is the contentious issue?
[01:47] <SteveA> where do i read about it?
[01:47] <lifeless> ddaa: no we didn't, bzr can sign post hox.
[01:47] <mpt> This is how the meeting ends ... not with a kaboom but with a whimper
[01:47] <carlos> lifeless, spiv about the script testing
[01:47] <ddaa> lifeless: sure, but there's no plan for when, where and how.
[01:47] <lifeless> ddaa: 'post hoc'
[01:48] <lifeless> ddaa: well, thats true enough
[01:48] <sivang> niemeyer: what's Gantry ?
[01:48] <carlos> lifeless, spiv we cannot use the main function to call it from the tests because we need to run that script with a concrete dbuser so we are sure that the user is able to access to the needed tables
[01:48] <SteveA> stub: can i give you the bradb blocker about --story ?
[01:48] <ddaa> After the branches are made public, or at some point during the transition, then when, knowing it's a significant CPU hog to sign 700k revision or something.
[01:48] <lifeless> SteveA: thats actually on my todo for tomorrow
[01:48] <stub> I think I have the email. --story will need to be rewritten for the new test runner I believe.
[01:48] <lifeless> SteveA: it bubbled up to the top of my pile this week
[01:49] <lifeless> stub: yes, it all likelyhood
[01:49] <carlos> at least that was the case when we started testing that script
[01:49] <SteveA> lifeless: "that"?
[01:49] <lifeless> SteveA: --story
[01:49] <SteveA> lifeless: okay
[01:49] <niemeyer> sivang: It's a framework of steel bars raised on side supports to bridge over or around something
[01:49] <jbailey> win 10
[01:49] <dilys> Merge to devel/launchpad: Fixed missing import that breaks the poimport script + test [r=stub]  (r2987: Carlos Perell Marn)
[01:49] <SteveA> lifeless: i asked stub to look into the zope3 migration, seeing as i'm not getting around to it
[01:50] <carlos> stub, ^^^^ Could you cherrypick it?
[01:50] <sivang> niemeyer: oh
[01:50] <stub> carlos: yup
[01:50] <niemeyer> sivang: :-)
[01:50] <carlos> stub, thanks
[01:50] <SteveA> lifeless / ddaa: what do you want me to do about the importd2bzr stuff/
[01:50] <daf> niemeyer: it's some sort of admin interface for Ubuntu, isn't it?
[01:50] <ddaa> SteveA: boring technical issues sabdfl got himself involved into. Basically, "how to advertise launchpad in RCS imports in bzr". I made some changes to what sabdfl and lifeless previously agreed to, because that was user hostile. lifeless and kiko know the details and support my proposal.
[01:50] <lifeless> SteveA: get mark on irc with ddaa
[01:50] <ddaa> lifeless: that would do it, I think
[01:50] <niemeyer> sivang: But the truth is that I can't talk about it :(
[01:50] <bradb> lifeless: I have --story in two branches on chinstrap
[01:51] <sivang> niemeyer: ah , ok.
[01:51] <kiko> stub, I'm seeing a strange problem on the diskless boxes here:
[01:51] <kiko> 19:14:15 WARNING Bad object name 'public.plpgsql_validator(oid)'
[01:51] <kiko>     + ProgrammingError: ERROR:  relation reference "ps1" cannot be used in an expression
[01:51] <lifeless> bradb: a newer version ?
[01:51] <kiko> stub, I wonder if that's just us requiring pgsql 8.0 now?
[01:51] <stub> kiko: Ignore it, or remove the matching entries from security.cfg before I get around to doing it myself.
[01:51] <stub> kiko: Actually - just ignore it.
[01:52] <kiko> stub, okay, but the test suite bombs out massively
[01:52] <SteveA> ddaa / lifeless: i'll ask mark to get on irc with you guys
[01:52] <kiko> possibly unrelated then
[01:52] <lifeless> SteveA: just ddaa
[01:52] <stub> kiko: Removing the entries will screw Mawson since it is still 7.4
[01:52] <SteveA> ok
[01:52] <lifeless> stub: ddaa and I are in sync
[01:52] <bradb> lifeless: No, the same version, segregated into its own branches, one for the Z3 change required, and one for the LP change.
[01:52] <lifeless> put me in the loop makes it a TZ problem
[01:52] <SteveA> lifeless: ok
[01:52] <lifeless> bradb: sweet. can you mail me the details ?
[01:52] <bradb> lifeless: sure
[01:52] <cprov> stub: how long should it take to upgrade mawson to pgsql 8 ?
[01:53] <stub> kiko: Oops... I only saw the warning. Don't know the second ERROR line - I'd need more details
[01:53] <stub> cprov: An hour or three
[01:53] <cprov> stub: AFAICS is the only DC machine using 7.4 
[01:53] <Spl4y> My dream was that launchpad stopped to give timeout
[01:53] <SteveA> kiko: i was just chatting with jbailey about bug triage.  he seems very pleased with the bug triage work recently for launchpad bugs, particularly daf's efforts getting through the mass of bugs
[01:53] <ddaa> lifeless: so, anything really urgent you can think of, or can dig back into OptionBranchTitle now?
[01:53] <cprov> stub: do you have time to do it today ?  or ASAP ?
[01:54] <ddaa> it's going to need a couple of rounds of review, so the sooner the better.
[01:54] <SteveA> T-5 mins to malone / distro meeting
[01:54] <lifeless> ddaa: whats the revisions/second count now ?
[01:54] <daf> kiko, SteveA: I have plans for generating a summary of bugs for LP products
[01:54] <kiko> stub, a massive set of ISE 500s on rosetta pages
[01:54] <lifeless> ddaa: yes, digging into that makes sense to me
[01:54] <cprov> stub:  I have a time-windows available and i think it might be a good idea to upgrade it since e have this time 
[01:54] <kiko> daf, I wonder if malone shouldn't be doing that for us :)
[01:54] <mpool> ok night all
[01:54] <SteveA> although to be honest, it is more of a "discussion" than a "meeting"
[01:54] <daf> kiko: it should, but in the meantime... :)
[01:54] <carlos> see you later
[01:54] <lifeless> night all
[01:55] <ddaa> lifeless: speed is not signficantly different, it's still clearly > 1 month job.
[01:55] <daf> kiko: hacking something up on chinstrap has a way faster turnaround than speccing, implementing, reviewing, merging
[01:55] <kiko> stub, it appears to be a postgresql-8ism introduced in potmsgset.py?
[01:56] <ddaa> lifeless: no point into making more guesstimate until we have a larger sample of branches into the measurement.
[01:56] <kiko> is that possible?
[01:56] <stub> cprov: Not today
[01:56] <cprov> stub: ok
[01:57] <stub> kiko: What is an ISE 500 ?
[01:57] <kiko> internal server error!
[01:57] <stub> timeouts? 
[01:58] <kiko> stub, see privmsg 
[01:58] <pitti> stub: btw, I uploaded a postgresql 8 fix to breezy-updates today; I think you want that for LP
[01:58] <kiko> it's an odd error in a rosetta query.
[01:59] <bradb> SteveA: malone / distro meeting now?
[01:59] <SteveA> no
[01:59] <kiko> SteveA, note that mdz isn't here..
[01:59] <SteveA> now
[02:00] <jbailey> Today's meeting is dedicated to ntp? =)
[02:00] <SteveA> kiko: we can summarize to mdz later or something
[02:00] <SteveA> or have another discussion
[02:00] <SteveA> Okay...
[02:00] <kiko> that's not very fair with the manager of the distro
[02:00] <kiko> another meeting would be okay
[02:00] <SteveA> Welcome to the discussion of malone and launchpad, a continuation of what we started in the launchpad meeting, but didn't have time for
[02:01] <SteveA> kiko: mdz wasn't in the launchpad meeting, so i don't think it is any worse
[02:01] <SteveA> who is here for this discussion?
[02:01] <SteveA> please say "here"
[02:01] <daf> here
[02:01] <mvo> here
[02:01] <mpt> here
[02:01] <dholbach> here
[02:01] <seb128> here
[02:01] <jbailey> here, but distracted.
[02:01] <pitti> here, lurking
[02:01] <kiko> here
[02:01] <jbailey> ogra: say "here"
[02:01] <matsubara> here
[02:01] <ogra> here
[02:01] <bradb> here
[02:01] <jbailey> Kamion: say "here"
[02:02] <mpt> bradb?
[02:02] <carlos> here but having lunch at the same time....
[02:02] <kiko> two seconds in the channel and already getting bossed around
[02:02] <bradb> mpt?
[02:02] <mpt> ok, bradb's here
[02:02] <Kamion> here
[02:02] <stub> here
[02:02] <SteveA> okay, let's get some kind of agenda.
[02:03] <SteveA> what are the main points we want to discuss?
[02:03] <mpt> * communication with distro team about why we're switching now
[02:03] <SteveA> just throw out points for the next 30 seconds
[02:03] <SteveA> then we'll triage them down
[02:03] <SteveA> 30
[02:03] <SteveA> ...
[02:03] <mpt> * advertising the best ways for distro developers to communicate ideas for improvement
[02:03] <pitti> * prioritization for malone bug fixes
[02:03] <seb128> * impact that will have on dapper, do we have to switch now?
[02:03] <bradb> what pitti said :)
[02:03] <SteveA> 15...
[02:03] <daf> * how to deal with problems that occur
[02:04] <ogra> * could we also switch after UVF ?
[02:04] <pitti> * plan B?
[02:04] <SteveA> 38....
[02:04] <sivang> * if we don't swtich this friday, this will probably get posponed furhter, so we better do it.
[02:04] <lifeless> night
[02:04] <seb128> * why do we need to switch now with well known issue that will impact on the distro team and could be fixed before switching
[02:04] <SteveA> okay
[02:04] <SteveA> i have the following items:
[02:05] <SteveA>  * communication with distro team about why we're switching now
[02:05] <SteveA> * advertising the best ways for distro developers to communicate ideas for improvement
[02:05] <SteveA>  * prioritization for malone bug fixes
[02:05] <SteveA>  * impact that will have on dapper, do we have to switch now?
[02:05] <SteveA>  * how to deal with problems that occur
[02:05] <SteveA> what is UVF?
[02:05] <lifeless> carlos: can we talk monday?
[02:05] <mpt> Upstream Version Freeze
[02:05] <pitti> upstream version freeze
[02:05] <ogra> upstream version freeze
[02:05] <SteveA>  * could we also switch after UVF ?
[02:05] <sivang> UpstreamVersionFreeze
[02:05] <SteveA> thanks
[02:05] <SteveA>  * plan B?
[02:05] <lifeless> carlos: I didn't mean to ignore you, but am very tired, and going out tomorrow night
[02:05] <SteveA>  * why do we need to switch now with well known issue that will impact on the distro team and could be fixed before switching
[02:05] <SteveA> 
[02:06] <spiv> carlos: Take a look at test_cronscript in lib/canonical/librarian/ftests/test_gc.py
[02:06] <SteveA> sivang: i didn't include yours because it was a statement
[02:06] <mpt> some of these points are duplicates
[02:06] <carlos> lifeless, sure
[02:06] <lifeless> thanks
[02:06] <sivang> SteveA: sure, noted
[02:06] <spiv> carlos: (and the rest of the file too :)
[02:06] <carlos> spiv, ok
[02:06] <kiko> shall we start out by addressing the first concern: why change now?
[02:06] <carlos> will do after lunch
[02:06] <SteveA> kiko: please do
[02:07] <kiko> okay
[02:07] <kiko> any migration at any time will be painful
[02:07] <kiko> that's where I want to start from
[02:07] <daf> there are always going to be reasons why switching now is not ideal
[02:08] <ogra> but doing it at the most critiacl and busy time of distro development is hard
[02:08] <ogra> *critical
[02:08] <kiko> ogra, but I disagree with you there.
[02:08] <kiko> this is not necessarily the most critical and busy time for distro development
[02:08] <seb128> kiko: that will impact on dapper
[02:08] <pitti> AFAICS now is not more or less critical than at any other point in the distro release
[02:08] <kiko> there's a number of critical periods during the six-month cycle
[02:08] <ogra> kiko, freezes are the most critical time 
[02:09] <pitti> if Malone would have all features we need, then switching shouldn't be so much of a pain
[02:09] <seb128> kiko: dapper is a special version, it's the first supported for 5 years we will have
[02:09] <kiko> seb128, it will impact on any release during which we would do the migration.
[02:09] <seb128> kiko: we should not screw it
[02:09] <mvo> I was wondering if we shouldn't have a discussion before the switch and lay out a plan what issues are ciritical for the distro team before a switch can be made (e.g. better search)
[02:09] <kiko> I am 100% confident malone won't screw dapper.
[02:09] <pitti> at least to me, the pain arises not from getting used to malone, but coping with the tremendous workflow slowdown 
[02:09] <ogra> kiko, we are all more busy the week before a freeze ... having to care for bugtracker issues at this time is quite some extra work
[02:09] <seb128> kiko: yeah, better to do it on a normal one rather than the "5 years supported one"
[02:10] <daf> pitti: would having extra people working on bug triage help?
[02:10] <bradb> I have a patch that will add a comment box on the +editstatus page. It's been in code review for a week, and got a review today.
[02:10] <seb128> kiko: I'm confident it'll, I barelly catch with my list of bug using bugzilla and working a lot of extra hours, and I do use malone already ... I'm pretty sure we will not keep with bug flow
[02:10] <pitti> daf: extra people working on improving malone usability would, IMHO
[02:10] <kiko> I think it will be more useful if we be practical, and not assembling a set of doubts.
[02:10] <daf> pitti: noted
[02:10] <kiko> look.
[02:10] <pitti> daf: i. e. we should make sure that bug triage is efficient
[02:10] <seb128> daf: sure, less bugs to deal with would allow to spend extra time on one bug :)
[02:11] <kiko> I realize you are really worried with the migration
[02:11] <ogra> kiko, i'm only worried about the time 
[02:11] <kiko> so let's be practical and address what are problems with the migration
[02:11] <daf> seb128: well, I was wondering whether having more people might counter-act the worflow slowdown
[02:12] <kiko> without hand-waving or excessive emotionality
[02:12] <Kamion> better searching and being able to see all bugs at once would greatly improve triage workflow, I think
[02:12] <daf> the main concern I've heard so far is that using Malone is slower than Bugzilla
[02:12] <pitti> daf: that doesn't seem like a good way of dealing with the problem; you can't pick a random guy for bug triage, for most bugs you need expert knowledge
[02:12] <seb128> stuff like sub-string query not working will hurt
[02:12] <kiko> daf, that's too intangible to be useful :-(
[02:12] <Kamion> daf: extra people triaging my bugs often actually slows me down
[02:12] <bradb> seb128: I recently landed a patch to do sub-string matching on package name.
[02:12] <daf> Kamion: fair enough :)
[02:13] <Kamion> they've been assigned to me because I know about them; not to be snobbish, but I often spend more time correcting triagers' misconceptions than actually working when I have some of them going through my bugs
[02:13] <daf> well, I was thinking more about pre-assignment triaging
[02:13] <pitti> full ack
[02:13] <mpt> bradb, does having done that make it easier for you to implement it for summary+description?
[02:13] <Kamion> daf: ugh
[02:13] <seb128> people closing duplicates, asking for useful informations, etc is useful though
[02:13] <Kamion> I'd rather just get the bugs
[02:13] <bradb> mpt: No, unfortunately.
[02:13] <kiko> Kamion, you said "better searching" -- are there any critical ones?
[02:13] <pitti> daf: of course it is always helpful to have somebody go through the unassigned bugs, close dups, assign to the right people, etc.
[02:14] <daf> pitti: right, that's the sort of thing I had in mind
[02:14] <bradb> mpt: Having mentioned the importance of that to stub at UBZ, it seemed like it was a fairly complex problem to solve without killing LP.
[02:14] <pitti> daf: that indeed helps, but it's pretty independent of the malone vs. bz question IMHO
[02:14] <daf> ok
[02:14] <Kamion> kiko: substring in package name, as bradb said, is the main thing; it used to be that other searches didn't work right but having retested it at least seems better now
[02:14] <daf> for searching: using Google can be a workaround for Malone's deficiencies
[02:14] <daf> (sometimes)
[02:15] <bradb> Sad, but true.
[02:15] <kiko> bradb, searching through bug summaries and descriptions? that's doable with a second fti field and some coding hacks.
[02:15] <pitti> but certainly with a big lag?
[02:15] <kiko> google has a big lag?
[02:15] <bradb> kiko: Sub-string matching on bug summaries and descriptions?
[02:15] <Kamion> but I *really* want to be able to see all bugs at once so that I can just use my browser's search facilities
[02:15] <seb128> we need query on comment like bugzilla
[02:15] <Kamion> then issues with malone searching would not be so important
[02:15] <seb128> bug title are not useful enough to find duplicate 95% of the time
[02:15] <kiko> bradb, well, substring is trickier than fti; we may require a read-only copy to do that.
[02:16] <pitti> we need status change and comment addition on one page, not with four clicks as it is now
[02:16] <kiko> Kamion, that's something we can address without too much difficulty.
[02:16] <kiko> pitti, that's going to be addressed this week.
[02:16] <daf> we have a bug in the bug batching code that means you can't make it show all bugs at once
[02:16] <kiko> daf, yeah, but it's fixable, I've looked at it a bit
[02:17] <Kamion> kiko: thanks
[02:17] <daf> kiko: maybe we should make that a priority
[02:17] <pitti> kiko: yay
[02:17] <kiko> daf, priority is my middle name
[02:17] <mpt> or just increase the batch size to 500, like I've been saying for moooonths
[02:17] <kiko> mpt, calma
[02:17] <kiko> but that's an option.
[02:17] <mpt> desculpe
[02:17] <Kamion> I think if the distro team could feel assured that issues that are seriously affecting their workflow could be addressed quickly, that would help
[02:17] <kiko> look
[02:17] <kiko> we work /for you/
[02:17] <pitti> I think this falls under 'bug fix priorization'
[02:17] <kiko> if you have troubles and come here, we will help
[02:18] <bradb> pitti: I implemented a fix for comment + change last week. It got code reviewed today, so hopefully I'll be able to land it todayish.
[02:18] <stub> mpt: Increasing batch sizes will increase timeouts. We can increase it but 500 is unreasonable.
[02:18] <Kamion> understood, but many of these issues were raised some time ago
[02:18] <Kamion> the ones people are bringing up today
[02:18] <ddaa> Kamion: it has been observed that pie-based bet appear to motivate some developers.
[02:18] <Kamion> I realise that not all bugs get fixed, of course
[02:18] <kiko> Kamion, yes, and we've been working on them, but there are lots of bugs.
[02:18] <seb128> kiko: I've filled some bugs like 6 months ago, you have a limited manpower too to fix issue, I'm sure you do your best but still ...
[02:18] <kiko> we had a serious issue with performance that we've worked hard to get under control
[02:19] <mpt> stub, could you comment to that effect in bug 499?
[02:19] <seb128> "lots of bugs" may be a sign we should not switch yet, you have things to work on/you could fix before forcing distro team to deal with them
[02:19] <kiko> seb128, I have filed bugs 6 months ago on ubuntu, too, that haven't been fixed. now, point out to me the critical ones and I can make sure they get addressed
[02:19] <kiko> seb128, there will always be "lots of bugs"; this is after all, software.
[02:19] <daf> seb128: Ubuntu has lots of bugs -- does that mean I shouldn't be using it? :)
[02:19] <seb128> daf: let's say regression compared to what we are using now
[02:19] <bradb> seb128: IME, it's not a manpower issue, it's an issue of connecting the priorities of Ubuntu devs with the people who make the decisions about what will be implemented next in Launchpad.
[02:20] <seb128> regression are not good :)
[02:20] <kiko> bradb is right.
[02:20] <bradb> Your pain is documented here: https://wiki.launchpad.canonical.com/DistroTeamOneOnOne
[02:20] <mpt> daf, if you're talking about using Dapper while being paid to work on Launchpad, the analogy holds
[02:20] <kiko> now
[02:20] <Kamion> bradb: right
[02:20] <seb128> daf: like the "too many click", "no good query", etc are known for ages
[02:20] <kiko> I'm /trying/ to get a list of practical things we can address
[02:20] <kiko> so far I have one
[02:20] <kiko> which is being able to list all bugs at once
[02:20] <daf> 1. allow seeing all bugs on a package at once
[02:20] <kiko> right.
[02:20] <ddaa> seb128: problems with ibook french keyboard has been known for ages :P
[02:20] <daf> 2. package name substring search
[02:21] <kiko> now, are there any others, minus hand-waving and fear?
[02:21] <seb128> kiko: searching on bug title and description
[02:21] <seb128> I do that a lot
[02:21] <kiko> seb128, you can search on them today. you can't substring search on them.
[02:21] <seb128> no way to find duplicates with the current query system
[02:21] <kiko> seb128, what do you mean, no way to find duplicates?
[02:21] <bradb> daf: Both #1 and #2 are implemented.
[02:21] <daf> seb128: how do you find duplicates in bugzilla?
[02:21] <daf> bradb: how do I do #1 today?
[02:21] <seb128> what is "substring"? I want to search all the bugs with "cdio" in the tile and "warning" in the comment by example?
[02:22] <seb128> daf: I type 3-4 keywords for the comments that match the description of the bug I remember
[02:22] <Kamion> keyword support would help me too (which I understand is being worked on); I attach the 'installer' keyword to all my installer bugs in bugzilla, for instance
[02:22] <mpt> seb128, "substring" means searching for "crash" finds bugs that use the word crash, or crashes, or crashed, or crashing
[02:22] <bradb> daf: https://launchpad.net/distros/ubuntu/+source/3dchess/+bugs (forgive me for not having a better example offhand)
[02:22] <seb128> daf: like "panel" "menu" "empty" "click"
[02:22] <kiko> sivang, use the X-Launchpad-Bug header.
[02:22] <Kamion> as I say I know there's keyword support under development but perhaps something less general that's useful in the meantime would be good
[02:22] <stub> mpt: done
[02:23] <mpt> ta
[02:23] <bradb> daf: A better example: https://launchpad.net/distros/ubuntu/+source/firefox/+bugs. This was implemented months ago.
[02:23] <kiko> stub, see privmsg
[02:23] <seb128> mpt: k, I need to try that, a few days ago it was still not working so I've no feedback on if the fix is good enough or not
[02:23] <daf> bradb: is this page batched?
[02:23] <kiko> Kamion, okay, I'll think about this.
[02:23] <mpt> seb128, it's not implemented
[02:23] <seb128> it should before switching imho
[02:24] <Kamion> kiko: thanks
[02:24] <bradb> daf: No. It never was.
[02:24] <daf> bradb: ah, I see
[02:25] <kiko> any new items that we could implement to help?
[02:25] <seb128> is there a way to list bugs without an upstream task?
[02:25] <kiko> any other practical items?
[02:25] <Kamion> perhaps search refinement would help with the complexity of various of the things that seb128 is mentioning?
[02:25] <bradb> Kamion: The keyword support we have planned is probably next on my plate, and as keyword support goes, it's a fairly simple solution to making something useful without spending months of time on it.
[02:25] <seb128> (I need that to make the difference between bugs waiting on GNOME guys and bugs I've to tackle myself)
[02:26] <mpt> kiko, I get the feeling the answer is no, none of the biggest problems are easy ones.
[02:26] <Kamion> i.e. take the current search, add another criterion to it
[02:26] <sivang> kiko: excellent, will use that from now on.
[02:26] <kiko> mpt, I don't agree, though they may be politically difficult.
[02:26] <bradb> seb128: No way to list bugs without an upstream task, but that shouldn't delay rollout. We can fix that relatively quickly.
[02:26] <kiko> right.
[02:26] <daf> is there a bug open on that?
[02:26] <seb128> k, because I will not be able to spot my 80 bugs instead of the 900 GNOME forwarded ones without that
[02:26] <kiko> daf, yes.
[02:27] <mpt> daf, yes there is
[02:27] <daf> good
[02:27] <mpt> and I also specced how it would work in MaloneSearch
[02:27] <mpt> -product:
[02:27] <mpt> or for bugs that have been fixed upstream, anywhere:fixed
[02:27] <kiko> indeed.
[02:27] <Kamion> bradb: all bugs at once, distros/ubuntu/.../+bugs> that works for packages but not for a person's assigned bugs
[02:27] <kiko> Kamion, agreed.
[02:28] <bradb> Kamion: Right, +assignedbugs is batched.
[02:28] <daf> Kamion: do you have any feedback for this page: https://launchpad.net/people/kamion/+assignedbugs
[02:28] <daf> should it perhaps be grouped by package?
[02:29] <daf> should it be possible to see all bugs on one page?
[02:29] <Kamion> daf: I'd normally use newest-first in preference to grouping by package
[02:29] <kiko> daf, the latter is what he's been asking for
[02:30] <daf> oh, you can sort by location already
[02:30] <Kamion> it's hard to tell because I don't have many bugs assigned to me in Malone yet, but comparing with /people/bradb/+assignedbugs, definitely yes - I can't deal with clicking previous/next all the time
[02:30] <seb128> is there a launchpad copy with a bugzilla import done somewhere?
[02:30] <bradb> Kamion: I agree. We can fix that quickly too.
[02:30] <seb128> staging.launchpad.net?
[02:30] <Kamion> bradb: stub seemed to think that huge batch sizes would cause timeouts - is that relevant here?
[02:31] <daf> hmm, staging is down
[02:31] <mpt> daf, it's either (1) show all bugs do that so you can use Ctrl+F for substring searching, but that's impractical because it would kill the database, or (2) implement substring searching in Malone itself.
[02:31] <Kamion> still, even a batch size of 100 or 200 would be much nicer to use
[02:31] <kiko> staging did have a bugzilla import on it for a long while, we called for testing then
[02:31] <kiko> Kamion, I think we can address this well
[02:31] <bradb> Kamion: Yeah. I think we could increase the batch size, but we'd have to see how much we can get away with.
[02:31] <daf> Kamion: yes, that is relevant
[02:31] <bradb> I don't expect we'll immediately be able to simply remove batching, for example. :)
[02:31] <seb128> kiko: I get a "The proxy server received an invalid response from an upstream server." on staging.launchpad.net
[02:31] <daf> but we can try increasing the batch size and profile it
[02:31] <Kamion> right, rough usefulness comes before perfection, naturally :-)
[02:32] <kiko> batching only really helps avoid the general load -- one-off queries shouldn't be a problem. the main problem is that batching has been used to work around pages which issue O(N) queries.
[02:32] <bradb> yeah
[02:32] <daf> O(n) sucks
[02:32] <kiko> to fix those pages we really need to produce sql views.
[02:32] <stub> Turn default batch size into a launchpad.conf entry so we can tune it on the production hardware.
[02:32] <bradb> That's a good idea stub 
[02:32] <kiko> stub, I was thinking more in the lines of let the user choose.
[02:33] <kiko> the reason for that is that most users won't change the default
[02:33] <kiko> and we avoid spiking the load
[02:33] <daf> kiko: there's a bug that means that you can't choose even by hacking the batch parameters in URLs
[02:33] <kiko> and still address specific user's needs (I never wanted a larger batch size myself, tbh)
[02:33] <stub> The other problem is that huge pages take ages to actually render. Bugzilla solves this by being slow, but we don't really have that luxury with the current app server architecture.
[02:33] <kiko> daf, I know -- that needs fixing.
[02:33] <daf> stub: is this a ZPT limitation?
[02:34] <kiko> stub, yeah. I don't think an unlimited batch size is appropriate everywhere.
[02:34] <stub> zpt and https both
[02:34] <daf> user-configurable batch sizes is already a bug
[02:34] <daf> perhaps add a note to that saying the default should be lp.conf-configurable
[02:34] <kiko> seb128, Kamion, pitti, ogra: any other practical issues we can focus on?
[02:35] <Kamion> stub: my Bugzilla bugs page with ~400 bugs takes about 3/4 seconds (stopwatch) to load/render
[02:35] <ogra> kiko, no technical ones, nope 
[02:35] <bradb> daf: Do you have a bug #? I can't find it.
[02:35] <daf> bradb: bug 3948
[02:35] <Ubugtu> Malone bug 3948: "User profile for Launchpad Batching System" Fix req. for: launchpad (upstream), Severity: Wishlist, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/3948
[02:35] <daf> there's also some discussion of performance considerations there
[02:35] <bradb> great
[02:35] <stub> Kamion: It wasn't that fast from Australia when I last checked ;)
[02:36] <daf> stub: how is https related?
[02:36] <Kamion> kiko: (while I think there are issues that need fixed soon, I'm still in the camp that says we should switch now and get the pain over with as soon as possible rather than dragging it out for another release cycle)
[02:36] <ogra> i'd prefer to wait 10 days until UVF is done ...
[02:37] <seb128> UVF will not make a difference
[02:37] <kiko> I'd also wish we did this sooner.
[02:37] <stub> daf: Zope first assembles the page, which takes time because zpt is pretty slow (ignoring all the database queries). It then gets transmitted. I suppose the transmission time will generally be less than the rendering time, but they both count to the total the user sees.
[02:37] <bradb> ASAP is best.
[02:37] <mpt> because UVF is about versions, not bugs?
[02:37] <Kamion> I don't think UVF will make much of a difference either
[02:37] <kiko> (and even distro team don't clearly have a consensual alternative date to suggest)
[02:37] <Kamion> the only thing that UVF means is that we sit there closing a lot of merge bugs
[02:37] <seb128> kiko: is there a way to store queries (like "bugs to fix for dapper")
[02:37] <Kamion> yes, that will take a bit longer, but I don't think it will take critically longer
[02:38] <seb128> which would be a query on the target field
[02:38] <kiko> seb128, using bookmarks?
[02:38] <dholbach> seb128: bookmarks, i suppose
[02:38] <daf> stub: ah, and https transmission time is slower than http transmission time
[02:38] <bradb> seb128: I suggested canned searches as a sprint topic at UBZ, but it got rejected. If many Ubuntu devs complain that it should be a priority after starting to use Malone, that'll help force the issue. Or maybe they won't care.
[02:38] <kiko> and overhead is higher.
[02:39] <seb128> how do I bookmakr "dapper target"?
[02:39] <kiko> seb128, do the query, bookmark the resulting page
[02:39] <daf> stub: would doing page transmission in a separate thread help?
[02:39] <mpt> Distributions have milestones, right?
[02:39] <bradb> yes
[02:39] <seb128> kiko: how do I query on the target field?
[02:39] <mpt> so, set a Dapper milestone
[02:39] <stub> One point that is relevant to all this - we have direct and easy access to the database. We can hack together custom reports where necessary to fix workflow bottlenecks. You might need a magic URL bookmarked, but it will work until the generic UI does what we need.
[02:40] <seb128> s/target/milestone
[02:40] <kiko> seb128, what is the target field? the target milestone?
[02:40] <kiko> ah
[02:40] <seb128> sorry, used to bugzilla
[02:40] <stub> daf: Don't know
[02:40] <dilys> Merge to devel/launchpad: rs=stub Fix a rather invalid query in potmsgset.py so it still works with PostgreSQL 7.4 (r2988: kiko)
[02:41] <daf> stub: perhaps nobody has spent time optimising ZPT
[02:41] <daf> stub: but I expect SQL performance is more critical in the near term
[02:41] <seb128> kiko: like we will need to have lists of bug set with the dapper milestone
[02:41] <stub> daf: I can confirm that nobody has spent time optimising ZPT :)
[02:41] <kiko> https://launchpad.net/products/launchpad/+milestone/1.1/+index
[02:41] <daf> stub: :)
[02:42] <kiko> seb128, the distro team can manage their milestones independently and get reports of them
[02:43] <seb128> your link doesn't work from here (permission issue), but if we have a way to list all the dapper milestone that's fine :)
[02:43] <kiko> and that page isn't batched.
[02:43] <daf> https://launchpad.net/distros/ubuntu/+milestone/dapper
[02:44] <kiko> daf, how did you get to that page? :)
[02:44] <seb128> kiko: bkor (GNOME bugzilla master) asked to get https://launchpad.net/malone/bugs/6667 fixed before switching or it will hurt bugzilla.gnome it seems
[02:44] <daf> I created the milestone
[02:44] <Ubugtu> Malone bug 6667: "Make watching GNOME bugs more efficient by doing just one buglist.cgi request" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6667
[02:44] <daf> :)
[02:44] <bradb> It'd be linked from /distros/ubuntu
[02:44] <daf> indeed
[02:44] <kiko> seb128, I.. can fix that. It'll be interesting to fix.
[02:45] <daf> hmm, do bugs in Bugzilla have milestones? (or equivalent)
[02:45] <seb128> kiko: please do before switching, better to not piss GNOME guys by taking their bugzilla down :)
[02:45] <seb128> daf: target milestone
[02:45] <daf> if so, are they going to be imported in the transition?
[02:45] <kiko> daf, yes.
[02:45] <seb128> yep, they are
[02:45] <seb128> (according to jamesh mail)
[02:45] <kiko> IIRC jamesh confirmed this
[02:46] <daf> ah, good
[02:46] <daf> that's a relief
[02:46] <dholbach> kiko: hm, i can't seem to find them
[02:47] <mpt> So do we have a plan of action?
[02:48] <kiko> well
[02:48] <kiko> I have a list of 5 issues.
[02:48] <kiko> six actually
[02:48] <mpt> 0. mail ubuntu-devel@
[02:48] <mpt> 1...
[02:48] <daf> kiko: wiki page?
[02:49] <Kamion> oh, hmm, one thing where UVF *is* relevant
[02:49] <Kamion> Keybuk: does merge-o-matic know how to file Malone bugs yet?
[02:49] <kiko> Kamion, is that debzilla?
[02:49] <kiko> or is that something else :)
[02:50] <Kamion> kiko: something else
[02:50] <Kamion> it's the script that tells us about packages we need to merge from Debian
[02:50] <Kamion> it does so by filing bugs in Bugzilla
[02:50] <dholbach> mom has to learn to send signed emails
[02:51] <bradb> Kamion: Who owns that code?
[02:51] <dholbach> (if Keybuk hasn't hacked on that yet)
[02:51] <Kamion> (and if there's an existing bug but the Debian or Ubuntu bug gets updated, then it tells the existing bug rather than filing a new one)
[02:51] <kiko> Kamion, indeed, I don't know about that -- it should probably be changed to use the malone email intereface.
[02:51] <Kamion> bradb: Keybuk, hence why I asked him :)
[02:51] <Kamion> kiko: this is critical for us
[02:51] <bradb> oh, sorry
[02:51] <kiko> Kamion, is there anything we need to do on our side?
[02:51] <daf> is now Keybuk's gym-time?
[02:52] <Kamion> MOM only files bugs up to UVF; after that it's silenced, since we don't do merges by default after UVF
[02:52] <cprov> stub: could you fix rocketfuel-build sync ? it's slacking on 2976 yet.
[02:52] <Kamion> it might be possible to make it just output the results to a web page indexed by maintainer or something as a workaround, but it'd be pretty clumsy
[02:52] <daf> mom will need a user account in Launchpad with a registered key
[02:52] <kiko> cprov, you mean -prebuilt?
[02:52] <Kamion> kiko: I don't know, unfortunately; Keybuk had some issues the last time he tried to make it use Malone
[02:53] <kiko> which were never brought to my attention
[02:53] <Kamion> dholbach: the e-mail interface wouldn't be sufficient on its own, since MOM needs to know whether to file a new bug or append to an existing bug
[02:53] <stub> cprov: fix what?
[02:53] <cprov> kiko: in chinstrap it's called only -built IIRC
[02:53] <kiko> stub, how often does it refresh, do you know?
[02:53] <Kamion> IIRC, that was the thing he couldn't figure out how to do in Malone, but you'd really need to ask him
[02:53] <dholbach> Kamion: oh yes.
[02:53] <stub> kiko: what?
[02:53] <cprov> stub: it's not synced with RF HEAD, is it ?
[02:54] <kiko> stub, how often is launchpad-prebuilt updated
[02:54] <kiko> lol
[02:54] <stub> ahh... every 30 mins I think
[02:54] <kiko> Kamion, how does it know there is an existing bug, in bugzilla?
[02:54] <cprov> stub: 2976 is older than that, looks like sync script is broken 
[02:54] <daf> kiko: rocketfuel-built, you mean
[02:55] <kiko> something like that
[02:55] <kiko> Kamion, bradb: I suspect merge-o-matic could use bug aliases to do that nicely -- what do you think?
[02:55] <kiko> it creates a bug and sets an alias that it knows how to build
[02:55] <bradb> We were going to remove aliases, but if there's a use case, sure.
[02:55] <stub> cprov: It also takes a while to mirror the changes from the pqm box to chinstrap, so the delay could be longer. The script will kick in again in 5 minutes anyway
[02:56] <kiko> then it uses that alias to refer back to it 
[02:56] <kiko> if the alias doesn't exist, create it
[02:56] <stub> (and if it doesn't work, there isn't much I can do)
[02:56] <cprov> stub: ok, let's wait this last shot.
[02:56] <daf> kiko: how about creating a wiki page to track the issues we've turned up?
[02:56] <cprov> stub: thx for investigatiing 
[02:57] <kiko> daf, yeah, I agree, I'm just wondering if there's anything else -- it appears we're not as bad as we
[02:57] <kiko> 're said to be <wink>
[02:57] <daf> you mean it's worse? ;)
[02:57] <Kamion> kiko: it uses bug aliases in Bugzilla, yes
[02:58] <Kamion> merge-<packagename> I think
[02:58] <bradb> jamesh: Are bug aliases being migrated?
[02:58] <kiko> Kamion, should be damned trivial.
[02:58] <bradb> Indeed.
[02:58] <Kamion> good
[02:58] <kiko> Kamion, I'll let it be your problem chasing Keybuk 
[02:58] <daf> Malone calls them bug nicknames
[02:58] <kiko> I will be here all day and all night as usual
[02:58] <Kamion> ok, I'll chase him up when he returns
[02:58] <kiko> so he can just ask and we will provide
[02:59] <daf> bradb: good point
[02:59] <daf> kiko: making sure aliases are imported should be on the list, I think
[03:00] <kiko> on the list now
[03:00] <stub> bug nicknames don't work at the moment, do they?
[03:00] <kiko> stub, don't be bringing in facts
[03:00] <mpt> no
[03:00] <seb128> kiko: should https://staging.launchpad.net/ work?
[03:00] <mpt> hehe
[03:00] <kiko> seb128, yes, it should. stub?
[03:00] <mpt> seb128, eventually
[03:01] <stub> I'll give it a poke - cherry picking to production atm
[03:01] <kiko> Kamion, ogra, seb128, dholbach, jbailey, pitti: anything outstanding things you'd like to raise? should we be ending this and focusing on fixing these painful issues?
[03:01] <seb128> I get a "Bad Gateway" page
[03:02] <kiko> seb128, yeah, it's down for some reason -- we'll get to it shortly, I'll ping you when I know what's up
[03:02] <daf> seb128: that's what happens with Launchpad is down
[03:02] <seb128> kiko: thanks
[03:02] <ogra> kiko, i'm fine with malone and the perspective you gave us here .... 
[03:02] <mvo> kiko: thanks
[03:02] <bradb> group hug?
[03:02] <kiko> that's worth a smile
[03:02] <dholbach> kiko: you forgot 'mvo' - but i have none apart from those already mentioned.
[03:02] <kiko> thanks mvo 
[03:02] <seb128> kiko: no other issue no, having those fixed would be nice enough to start :)
[03:02] <daf> group hug!
[03:02] <kiko> okay.
[03:03] <kiko> now now
[03:03] <kiko> don't freak out for the next 22h
[03:03] <bradb> heh
[03:03] <seb128> I would appreciate not beeing bug flooded too
[03:03] <seb128> like not getting mails for my own changes by example :)
[03:03] <kiko> seb128, I suspect you'll need to study some field of work other than software development ;)
[03:04] <seb128> ah ah
[03:04] <kiko> "bugs and software" is analogous to "electricity and computers"
[03:04] <daf> bradb: hmm, has the mail-for-my-own-changes thing been discussed?
[03:04] <kiko> daf, it's on the list now
[03:04] <daf> kiko: bugs make software run?
[03:04] <kiko> it has been discussed before
[03:05] <seb128> I've pointed it several times already
[03:05] <daf> kiko: was there a decision made?
[03:05] <kiko> no.
[03:05] <daf> is there a bug open?
[03:05] <kiko> yes.
[03:05] <daf> I think bugzilla has a preference for don't-send-me-my-own-changes
[03:06] <daf> perhaps we should imitate that
[03:06] <seb128> and like not getting 4 mails because the guys set 2 watches, added a comment and changed some settings
[03:06] <bradb> bug 1350 has a particularly ambitious suggestion for dealing with that
[03:06] <Ubugtu> Error: Could not parse data returned by Malone: Connection to Malone bugtracker failed: HTTP Error 500: Internal Server Error
[03:06] <daf> hmm, batching notifications
[03:06] <kiko> seb128, oh, you figure bugzilla is better than that? :-)
[03:06] <kiko> s/than/at
[03:07] <seb128> kiko: bugzilla is great at that, it has one page to change all the settings and comment :)
[03:07] <seb128> no clicky issue, no mail flood
[03:07] <kiko> seb128, so will we next week (and I almost got fired trying to do it in a different way)
[03:07] <daf> debbugs sends you copies of your own changes
[03:07] <copernic> guys, does anyone know the irc channel name of rosetta?
[03:07] <daf> copernic: #launchpad
[03:07] <kiko> copernic, you're there.
[03:08] <seb128> kiko: yeah, do it, even if it's going to cost you your job :)
[03:08] <copernic> oups :) thanks
[03:08] <copernic> I thought there was some seperate channel
[03:08] <daf> no :)
[03:08] <copernic> anyway, I'll have a question related with Rosetta please
[03:08] <daf> sure
[03:08] <mpt> all righty
[03:08] <copernic> well, I am the translator for Azerbaijani language
[03:08] <bradb> I have a lot of things to land today. Anything else outstanding for the Malone meeting?
[03:09] <mpt> as long as there's smiles, even if some of them are forced
[03:09] <copernic> and I have my own account on rosetta
[03:09] <mpt> it's past 3am and BEDTIME
[03:09] <kiko> all right
[03:09] <stub> elmo / Znarl: I can't connect to asuka, so if that isn't one of you two doing maintenance then I think it needs a power cycle
[03:09] <kiko> thanks to everybody who was here to suggest, help, rant, cry, maim, etc launchpad developers over the malone migration
[03:09] <kiko> and as the memorable huggy bear once said
[03:09] <copernic> the problem is, https://launchpad.net/distros/ubuntu/dapper/+lang/az is showing very little packages whereas breezy has mana many packages to translate
[03:10] <bradb> Indeed, thanks for voicing your concerns dudes.
[03:10] <kiko> "this meeting is adjourned"
[03:10] <carlos> copernic, it's a know bug
[03:10] <carlos> copernic, we will fix it soon
[03:10] <copernic> I am planning to create one account for our translation team, to let them translate dapper staff
[03:10] <kiko> ----------------- end of malone migration meeting ------------------
[03:10] <Kamion> daf: like bugzilla, you can do many control-type changes at once in debbugs and get one ack mail back
[03:10] <Znarl> stub : Checking...
[03:10] <copernic> carlos: thanks for that info, what can we do for now?
[03:10] <kiko> I got hugged first!
[03:10] <carlos> copernic, dapper will not be available to translate until February
[03:10] <ogra> kiko, we'll rant, cry, maim a lot more the next weeks, thats only silence before the hurricane ;)
[03:10] <daf> Kamion: indeed, that's true
[03:11] <seb128> kiko: he he :)
[03:11] <kiko> Kamion, you can with malone too
[03:11] <daf> copernic: we have a bug open to improve that page
[03:11] <kiko> via the email interface
[03:11] <kiko> and via the status change page -- the main difference is that you can't comment on the status change page until next week
[03:11] <seb128> BW what is the best way to bug you guys?
[03:11] <seb128> using malone?
[03:11] <seb128> rant on this chan? :)
[03:11] <daf> either is good
[03:11] <copernic> carlos, ok, but if we start translation breezy, will these translations automatically be available in daper too in february?
[03:11] <bradb> seb128: Yes.
[03:11] <dholbach> :)
[03:11] <kiko> seb128, either is good, I always keep an eye out for your requests
[03:11] <seb128> cool, thanks
[03:12] <carlos> copernic, that's the idea, yes
[03:12] <daf> https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc
[03:12] <seb128> be ready to feel bug flooded too, we like to share :)
[03:12] <carlos> copernic, https://launchpad.net/distros/ubuntu/breezy/+search
[03:12] <carlos> copernic, look for packages there
[03:12] <seb128> isn't it, dholbach? :)
[03:12] <dholbach> :)
[03:12] <copernic> carlos, one more question, are these getting integrated with Gnome CVS?
[03:12] <Kamion> kiko: ok, thanks, acknowledged
[03:12] <daf> copernic: hmm, you're the GTP coordinator for AZ, yes?
[03:12] <copernic> yep
[03:12] <daf> thought so :)
[03:13] <copernic> :)
[03:13] <carlos> or go to https://launchpad.net/distros/ubuntu/dapper/+lang/es or https://launchpad.net/distros/ubuntu/dapper/+lang/ca or any other team that has lots of translations as a workaround to get a list of resources to translate....
[03:13] <daf> we don't have tools for CVS syncing yet
[03:13] <daf> I'm afraid you have to do it by hand
[03:13] <daf> we know we need an easier way to do it
[03:13] <carlos> copernic, we are working on it, but I don't think it will be done before April
[03:14] <copernic> daf, but these translations get into ubuntu right?
[03:14] <copernic> carlos: no problem, I just want the effort to not get lost
[03:14] <carlos> copernic, you can always download .po files and send them to GNOME's CVS
[03:14] <copernic> sure !
[03:14] <carlos> anyway, the integration we will do is to fetch from GNOME's cvs and import into launchpad/rosetta
[03:15] <carlos> the other way is a bit more difficult
[03:15] <copernic> carlos, what if the rossetta version is newer, has more up to date translations
[03:16] <copernic> carlos, and gnome cvs lags back, what will the system do then?
[03:16] <carlos> copernic, the gnome cvs one will not break the translations in Rosetta
[03:16] <carlos> copernic, we will get only the new additions
[03:16] <copernic> ok, I see now... great
[03:17] <copernic> also, it would be nice to group packages in rosetta so that we could know what exactly to translate to have a 100% localized Ubuntu
[03:18] <cprov> stub: rf-built still sitting on 2976 ... bad day in most senses
[03:18] <carlos> copernic, well, all packages at distros/ubuntu/breezy are packages to translate for Ubuntu. But I suppose you mean the ones with a GUI vs. text mode ones, right?
[03:18] <copernic> yep, and those that come with default installation
[03:19] <copernic> to get a 100% localized desktop and main apps, then continue effort to get additional apps too
[03:20] <copernic> because there are so many deprecated packages there, one does not know what to translate at first
[03:20] <copernic> not gnome-like at all :)
[03:21] <carlos> copernic, yeah, we have that in mind already
[03:22] <carlos> but first we need to finish the migration to use launchpad as the development tool for Ubuntu
[03:22] <carlos> and then we will have that information to start "playing" with it
[03:22] <copernic> yes of course
[03:22] <kiko> cprov, I can try rsyncing down the -devel tree..
[03:22] <copernic> for ex. there are 5 different gtk+2.0 to translate, which is going into the next release...
[03:22] <matsubara> cprov: the rf-built is like that since yesterday. I thought it was a problem with our prebuilt script, but it seems to be a problem there. Salgado said to me that has happened before.
[03:23] <kiko> cprov, matsubara: should I pull down the devel tree?
[03:23] <carlos> kiko, what was the problem with your recent merge?
[03:23] <cprov> kiko: it's not the same ... don't worry
[03:23] <carlos> kiko, what was wrong?
[03:23] <kiko> carlos, hmmm?
[03:23] <kiko> oh
[03:23] <kiko> non-7.4 compatible.
[03:23] <cprov> matsubara: yes, it has happened before, several times :(
[03:24] <kiko> cprov, launchpad/devel isn't updated either? gross
[03:24] <carlos> copernic,  that's another issue. will not happen again with dapper and will try to finish fixing them for breezy
[03:24] <cprov> kiko: where anthem of chinstrap ?
[03:24] <carlos> kiko, hmmm, is it related to the suggestions changes I did last week?
[03:25] <kiko> cprov, chinstrap
[03:25] <kiko> carlos, yes.
[03:25] <jamesh> bradb: the current import code does not import aliases (I didn't see them in the Malone interfaces).  It does have special case handling of the bugzilla aliases debzilla creates though
[03:25] <carlos> I didn't know I introduced a new feature....
[03:25] <cprov> kiko: right, it's old also in chinstrap
[03:26] <kiko> jamesh, I think we should import them -- for the reasons above. how bad is that?
[03:26] <jamesh> (generating an equivalent bug task against debian and linking up the watch)
[03:27] <jamesh> kiko: I don't see aliases in the Malone data model
[03:27] <kiko> jamesh, they are called "nicknames" IIRC.
[03:27] <jamesh> kiko: ah.  I completely missed that.
[03:28] <jamesh> I guess we can pull that over (shouldn't be too difficult to get working tomorrow)
[03:28] <jamesh> bug.name
[03:28] <kiko> I think we should pull it over, yes.
[03:29] <kiko> it is an interesting feature, though less interesting for the obvious reasons and more so for the consequence of having a stable, pre-generatable reference to a bug
[03:29] <kiko> as if you could say "I'm going to file bug 23211 on that"
[03:30] <jamesh> I don'
[03:30] <jamesh> t suppose there is any reason to keep the debzilla aliases, right?
[03:30] <daf> you mean the mom aliases?
[03:30] <kiko> why not, jamesh?
[03:31] <jamesh> kiko: redundant information
[03:31] <kiko> I'd keep them
[03:31] <kiko> just because it's cheap
[03:32] <jamesh> they are aliases like "deb12345"
[03:34] <copernic> carlos: have you finished with your school you mentioned so much ? :)
[03:34] <kiko> daf, bradb: #canonical-meeting?
[03:34] <carlos> copernic, not really...
[03:35] <bradb> a cool use case for aliases is duplicates
[03:35] <copernic> oh man...
[03:35] <carlos> copernic, I'm on it but slowly....
[03:35] <kiko> stub, let me know when you're IRCable
[03:35] <carlos> only 8 exams to go O:-)
[03:35] <copernic> carlos, lord help everyon with schools ...
[03:36] <carlos> lord?
[03:36] <kiko> god
[03:36] <copernic> God :)
[03:36] <copernic> LOL
[03:36] <carlos> ok ;-)
[03:36] <carlos> it's not a matter of 'lord' it's a matter of expanding the days to have more than 24 hours ;-)
[03:37] <carlos> and of course... being more motivated to finish them... 
[03:37] <carlos> but I think I'm near there
[03:37] <copernic> but the latter is very unrealistic :)
[03:37] <copernic> I mean the 24 hours
[03:37] <bradb> though i've been too lazy to do the clicking required to set a bug name so that i could use that name for future dup'ing
[03:38] <kiko> bradb, are you terribly lagged?
[03:38] <copernic> our goverment (Azerbaijani) had a decision to use Linux in education sector, so there's kinda boom in here, we'll be busy translating staff these months
[03:38] <carlos> copernic, did they choose already a distribution?
[03:38] <stub> staging is rebuilding itself - might be a while. I need to reoptimize the restore procedure for PG8
[03:38] <stub> kiko: Yo
[03:38] <kiko> stub, hey man
[03:39] <copernic> carlos: nope, but it all depends on what linux users group advice the most
[03:39] <copernic> and we all seem in favour of Ubuntu
[03:39] <kiko> stub, have two performance items to talk to you that the malone meeting brought up
[03:39] <carlos> copernic, cool
[03:39] <copernic> afther that decision, microsoft stared to translate windows too :)
[03:39] <copernic> started
[03:39] <carlos> anyway, the choose of Linux is already really good news
[03:40] <copernic> yes, I could not believe it for days
[03:40] <ddaa> We go to the top of the country list. What's the next?
[03:40] <kiko> stub, one is substring searching in specific fields. how bad is that on our current db? I know that bugzilla does that sort of query on a read-only mirror (shadow) database..
[03:40] <ddaa> oops, the first is Afghanistan...
[03:41] <ddaa> mh... I'm not sure they really care about linux there...
[03:41] <kiko> stub, the other is the impact of no batching in terms of the removal of limit -- I suspect the problem is more that we issue O(N) queries in certain pages, and batching works around that.
[03:41] <stub> kiko: We can get away with it if the fields are 'short' or the number of rows are 'few'. We have been cautions so far on what 'short' and 'few' means.
[03:42] <kiko> stub, a few thousand rows at most 
[03:42] <stub> kiko: But the only real way of knowing is to test, and to have a plan B in case the database grows enough to make it impractical
[03:42] <kiko> stub, but summary and description...
[03:42] <kiko> okay.
[03:42] <stub> I'd rather have better fti searching though
[03:43] <daf> we can make things better by doing the substring searches *after* applying other filters like status, milestone, etc.
[03:43] <copernic> carlos: is integration with KDE planned in Rosetta?
[03:43] <kiko> stub, the problem is isolating -- a substring search just in the summary field.
[03:43] <stub> substring isn't that good, particularly as services like google don't do it.
[03:43] <stub> But if people want it
[03:44] <kiko> an fti query in a specific field would be almost as good
[03:44] <kiko> but the problem is that our fti today is a collage of fields
[03:44] <kiko> so... it works well until you want to  search in a specific field
[03:44] <stub> That is different to what I had heard before, which is people want to search for 'foo' and have everything search and results returned in relevance order.
[03:45] <bradb> stub: Is Bug's fti being updated in prod?
[03:45] <stub> bradb: I havn't checked sorry.
[03:45] <bradb> ok
[03:46] <stub> kiko: Yes - the major problem with batching is that on some pages we were issuing 3 or 4 queries per row being displayed.
[03:46] <kiko> stub, okay. so if we are to offer unlimited queries, it needs to be in pages that we make sure don't do that.
[03:47] <stub> kiko: Crafting the SQL query manually (either sending it from Python or sticking it in the database as a view) could avoid that.
[03:47] <kiko> stub, I don't know how to avoid using a view with sqlobject. do you?
[03:47] <stub> Also, rendering huuge lists just takes too long
[03:47] <stub> kiko: Why use SQLObject when it isn't appropriate?
[03:48] <kiko> stub, I guess, mainly because the change will be less painful to implement.
[03:48] <kiko> what would you use to deliver the information to templates? dictionaries?
[03:49] <stub> kiko: I've seen code that is way more obfuscated that it needs to be - a simple SQL query and a for loop iterating over the results returned is often much, much simpler to maintain and understand.
[03:49] <stub> square pegs and round holes
[03:50] <stub> (but it depends on the individual case what approach to take of course)
[03:50] <kiko> hmmm you confused me there.
[03:51] <stub> cur.execute("SELECT foo.name, ...... FROM Foo, bar, baz WHERE ......"); return cur.fetchall()
[03:52] <kiko> which will return a list of lists?
[03:52] <stub> There is no need to construct SQLObject classes, define views etc. etc. if the only purpose they would serve is to needlessly complicate code
[03:53] <kiko> I guess case-by-case investigation is necessary to evaluate that.
[03:54] <sivang> -> back
[03:55] <kiko> stub, can you look into bradb's problem and email launchpad when you have an idea of what's wrong?
[03:58] <stub> bradb: yup. Looks like the trigger isn't working. I'll need to fix that tomorrow.
[03:58] <bradb> stub: Phew, thanks for confirming my suspicion :)
[03:59] <kiko> whew
[04:02] <kiko> jamesh, I don't care too much about those -- I don't think any tool relies on them. perhaps better safe than sorry.. perhaps not.
[04:04] <stub> Bah. Fixing the triggers might mean  a few hours of downtime :-(
[04:04] <kiko> stub, what's wrong?
[04:05] <stub> I can switch the triggers back on easily enough. But I need to rebuild the indexes so they match the current data (as the indexes are currently out of date and getting more so every hour)
[04:05] <kiko> stub, why were they off?
[04:06] <stub> Dunno. I'll investigate tomorrow. 
[04:06] <kiko> ok.
[04:06] <kiko> thanks stub 
[04:19] <carlos> copernic, yes, exactly the same thing as we are going to do with GNOME
[04:22] <copernic> great to hear that !
[05:04] <LarstiQ> bradb: what was it?
[05:04] <bradb> LarstiQ: renaming the package dir from bzrtools-<version> to bzrtools, the build will succeed
[05:05] <LarstiQ> doh!
[05:05] <LarstiQ> such simple things, and they can wreck your day :/
[05:06] <bradb> indeed
[05:32] <tonii> hola
[05:32] <tonii> alguien me puede ayudar que no me deja entrar en la web de ubuntu para pedir los cds ???
[05:32] <dilys> Merge to devel/launchpad: [r=SteveA]  fix bug 3712 (bad assignee link on bug summary page), (r2989: Brad Bollenbach)
[06:30] <SteveA> kiko-fud: ping
[06:52] <SteveA> kiko-fud: ping
[07:42] <AlinuxOS> hello guys... still no possibility of .po file uploading (automatic translating) ?
[07:43] <AlinuxOS> carlos, jordi ?
[07:45] <carlos> AlinuxOS, it's fixed
[07:46] <carlos> AlinuxOS, it's already importing things
[07:46] <AlinuxOS> so I' retry...
[07:46] <AlinuxOS> or still must wait for yesterday e-mails?
[07:48] <carlos> AlinuxOS, hmmm, it should be imported at this point
[07:49] <carlos> could you check just in case the notification email failed?
[07:52] <carlos> jordi, could you announce that the imports are working again? (rosetta-users && ubuntu-translators)
[07:56] <AlinuxOS> carlos, I'll retry now an import :)
[07:56] <carlos> AlinuxOS, ok
[07:58] <jbailey> bradb: ping?
[07:58] <AlinuxOS> Your upload worked. The translation content will appear in Rosetta in a few minutes. :)
[07:58] <bradb> jbailey: pong
[07:59] <jbailey> bradb: What's this email re: bzrtools about?
[07:59] <AlinuxOS> so I'm waiting :) 10 minutes :)
[07:59] <AlinuxOS> then I'll tell you if it works.
[08:00] <carlos> AlinuxOS, ok, I see the "problem"
[08:00] <carlos> AlinuxOS, https://launchpad.net/rosetta/imports/
[08:00] <bradb> jbailey: Which bzrtools email? There's the "bzrtools FTBFS" one from Robert which explains the problem, and then my email response to Kamion, where he gives me a tip on how to fix it.
[08:00] <carlos> AlinuxOS, there you can see that someone needs to review your upload
[08:00] <carlos> I didn't see your previous import
[08:00] <carlos> I will do it now.
[08:00] <jbailey> bradb: Yours is the only email I see in the thread I think.
[08:00] <AlinuxOS>   	 Vladimer Sichinava
[08:00] <AlinuxOS> here I am.
[08:01] <carlos> yeah
[08:01] <bradb> jbailey: lifeless sent you the problem report to jbailey@raspberryginger.com. https://chinstrap.warthogs.hbd.com/~dsilvers/paste/fileqORkv8.html.
[08:01] <AlinuxOS> ka.po files are our georgian :)
[08:02] <jbailey> bradb: Ah.  I probably won't see the email for another week then.
[08:02] <bradb> ah, ok
[08:03] <bradb> jbailey: Basically, bzrtools has a broken dep, and trying to build it manually fails without manual intervention (renaming the dir to bzrtools and then building it.)
[08:04] <bradb> "the dir", i.e., bzrtools-<version>
[08:04] <jbailey> Right.
[08:04] <jbailey> Umm, hmm.
[08:04] <jbailey> I might try to look at this tomorrow or so.
[08:05] <bradb> Strange that more LP developers haven't complained about this, because it'll break bzr push for them. Maybe others aren't upgrading bzr as often.
[08:06] <jbailey> Possibly.  It would be really nice if LP folks would use released versions and bitch at the bzr devs for not releasing often enough if this is a real problem.
[08:06] <jbailey> At this point I don't seem to be able to log into my home machine.  Hmm. =(
[08:07] <bradb> bummer
[08:08] <jbailey> That might mean I'll look at it on the 20th.
[08:08] <jbailey> niemeyer: Got grumpy? =)
[08:10] <carlos> AlinuxOS, done, should be imported soon
[08:11] <AlinuxOS> :) carlos !! Muchos Grazias :)
[08:11] <carlos> AlinuxOS, ;-)
[08:11] <carlos> do you know Spanish?
[08:12] <AlinuxOS> carlos, no io parlo l'italiano, georgiano, russo :)
[08:12] <AlinuxOS> but I have some friends from Spain :) great people!
[08:13] <carlos> ;-)
[08:13] <carlos> btw, the correct phrase is 'Muchas gracias', but it's close enough to understand it :-D
[08:13] <AlinuxOS> ;)
[08:14] <bradb> buffet, even
[08:14] <AlinuxOS> hehe, where are you in Spain carlos?
[08:17] <carlos> AlinuxOS, Valencia
[08:17] <AlinuxOS> ooooo :)
[08:17] <AlinuxOS> good soccer team :)
[08:18] <AlinuxOS> I'm from Siena, it's near Florence 
[08:18] <AlinuxOS> but originally I'm georgian (Caucasus)
[08:18] <AlinuxOS> carlos, works!!!!
[08:18] <AlinuxOS> well done!
[08:19] <carlos> AlinuxOS, ;-)
[08:19] <carlos> AlinuxOS, Georgian living at Italy ;-)
[08:20] <AlinuxOS> :) carlos exactly :)
[08:20] <AlinuxOS> I speak a non indoeuropian language... :)
[08:21] <AlinuxOS> use english russian and italian to translate into georgian... and I like very much rosetta's way of doing :)
[08:21] <AlinuxOS> very usefull and simple!
[08:22] <carlos> AlinuxOS, I'm happy to know that 
[08:22] <AlinuxOS> :)
[08:23] <AlinuxOS> carlos, what language do you use to program?
[08:23] <carlos> usually C, but since I work on Rosetta... Python
[09:03] <carlos> jordi, ping
[09:09] <kiko> hey bradb, daf: how goes it?
[09:10] <bradb> kiko: Almost done responding to the review. Spotted some breakage, added some simple GeneralFormView tests.
[09:10] <bradb> Landed those bugfixes in malone-smallfixes
[09:11] <kiko> ah, great
[09:11] <kiko> is there anything small matsubara or I could look at?
[09:16] <bradb> bug 3322 would be nice to fix
[09:16] <Ubugtu> Malone bug 3322: "It should be possible to indicate a binary package when filing a bug" Fix req. for: malone (upstream), Severity: Major, Assigned to: Brad Bollenbach, Status: Confirmed http://launchpad.net/bugs/3322
[09:16] <kiko> bradb, your wish, my command, etc.
[09:16] <bradb> :)
[09:18] <bradb> I imagine there would just be a "package name" field on +filebug for distros, that would Just Work, whether you enter a source package name or a binary package name
[09:18] <kiko> that's how I see it as well
[09:18] <bradb> ok, cool
[09:18] <kiko> if the guy supplied a binary package name I'll add it as an extra line to the description
[09:18] <kiko> (and of course try to choose the right source package)
[09:19] <kiko> it is not always trivial but I know enough of the publishing tables to make a best-guess
[09:19] <bradb> kiko: Why add it to the description? We have IBugTask.binarypackagename
[09:19] <kiko> oh, we do?
[09:19] <bradb> we do
[09:19] <kiko> amazing!
[09:20] <kiko> it is even easier then
[09:20] <bradb> indeed
[09:24] <bradb> kiko: If you're looking for one more, fixing bug 5505, so that /bugs/anickname works, would help Keybuk out
[09:25] <bradb> and any /.../+bug/anickname URLs, of course
[09:25] <bradb> In the meantime, he has to brute force package bugs to find a bug matching a nick name.
[09:46] <carlos> see you
[10:04] <XeDoX^Drunk> Hello
[10:04] <XeDoX> Are Ubunto really free
[10:05] <mdke> XeDoX, yes, you need #ubuntu though
[10:06] <XeDoX> Thank You
[10:11] <lifeless> moin
[10:13] <matsubara> hey lifeless 
[10:15] <matsubara> can you check if the rf-built tree is up to date?
[10:33] <AlinuxOS> hello :) me again
[10:34] <jordi> hello
[10:34] <AlinuxOS> One question... can I download all .ka(georgian) files from entire dapper project, I need them to create a Georgian word database.
[10:34] <AlinuxOS> jordi, import works again :) thank you! :)
[10:34] <jordi> yeah
[10:34] <jordi> I'll tell the lists now
[10:35] <AlinuxOS> lists?
[10:35] <AlinuxOS> ah ok :)
[10:36] <AlinuxOS> and what about all ka.po files that I want to scan with kbabel to improve my rough translation.
[10:36] <AlinuxOS> ?
[10:43] <kiko> man
[11:24] <kiko> bug 5505
[11:24] <Ubugtu> Malone bug 5505: "Bug nicknames no longer used" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Brad Bollenbach, Status: In Progress http://launchpad.net/bugs/5505
[11:43] <lifeless> kiko: hey dude
[11:47] <kiko> hey lifeless 
[11:47] <kiko> what's up?
[11:47] <kiko> did you see matsubara's question?
[11:51] <lifeless> kiko: no, I didn't
 can you check if the rf-built tree is up to date?
[11:52] <kiko> it's hampering our merges down here :)
[11:53] <lifeless> next cron run is in 7 minutes, I'll check
[11:53] <kiko> lifeless, it's not working, not sure why.
[11:53] <lifeless> you are getting an error ?
[11:53] <kiko> lifeless, are you game for a review for bug 1512? it's for ddaa, kinda late, but done
[11:54] <lifeless> sure
[11:54] <kiko> no, it's just not updating
[11:54] <kiko> Ubugtu, bug 1512
[11:54] <Ubugtu> (bug <abbreviation> <number>) -- Look up bug <number> in the bugtracker associated with <abbreviation>.
[11:54] <Ubugtu> Malone bug 1512: "Admins creating products should be allowed to set owner and is_reviewed" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Christian Reis, Status: In Progress http://launchpad.net/bugs/1512
[11:54] <lifeless> whats involved in reviewing a bug ?
[11:55] <kiko> lifeless, oh, I want you to review a branch which fixes it
[11:55] <lifeless> oh sure.
[11:56] <lifeless> *that* I know how to do ;)
[11:56] <lifeless> its not on the pending branches summary page ?
[11:57] <kiko> I just landed it
[11:57] <kiko> I can put it there, of course
[11:57] <kiko> but it's a quick one -- your choice
[11:57] <lifeless> well, if you pastebin a diff, I'll read that
[11:57] <lifeless> happily
[11:57] <kiko> sure.
[12:00] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/fileeo3slY.html
[12:00] <kiko> mainly changes to one file
[12:00] <kiko> and then a set of test changes
[12:00] <kiko> and fluff around the corners
[12:01] <kiko-zzz> lifeless, mail me about the review and the -built tree? thanks..
[12:01] <kiko-zzz> really sleepy tonight
[12:01] <lifeless> kiko-zzz: will do
[12:01] <kiko-zzz> zzzzz