[12:12] <kiko> cprov, how do we manage to break that?
[12:13] <cprov> kiko: no idea, will need to investigate why the changesfile was not properly parsed. NascentUpload AHHHHHH !
[12:14] <kiko> argh
[12:14] <cprov> I needs some food now, will investigate it better after dinner, see you ...
[12:15] <kiko> sure
[12:15] <kiko> laters
[12:19] <sabdfl> kiko: who should i ask to do this review?
[12:19] <sabdfl> it's big, but it's neat and tidy
[12:19] <kiko> sabdfl, anybody but me :)
[12:19] <kiko> seriously, probably salgado?
[12:19] <sabdfl> fair enough, but who do you recommend?
[12:19] <sabdfl> ok
[12:28] <sabdfl> it's a very satisfactory branch
[12:28] <sabdfl> :-)
[02:03] <mpt> Goooooooooooooooood afternoon Launchpadders!
[02:23] <mpt> spiv, ping
[02:38] <spiv> mpt: pong
[02:49] <mpt> spiv, given the results I posted to launchpad@ in the "devpad is the new sodium" thread, can you tell me how I may land a branch?
[02:54] <spiv> mpt: did you see jamesh's reply?
[02:59] <spiv> mpt: basically, remove the section specific to the branch from your branches.conf, so that it doesn't override the section with public_repository etc that the PQM plugin uses.
[03:00] <mpt> spiv, that's what I did originally
[03:00] <mpt> Hmm, maybe I pushed between doing that and doing the pqm-submit
[03:01] <spiv> mpt: if it's trying to merge to bzr.dev, then that is probably the problem.
[03:01] <spiv> It's an annoying bug.
[03:06] <mpt> oops
[03:06] <mpt> spiv, I just realized that in that same message, I'd already said that I'd tried just what you suggested :-)
[03:06] <mpt> carlos suggested that last night
[03:06] <mpt> When I do, I get a "not a branch" error
[03:07] <spiv> mpt: hmm.
[03:13] <spiv> mpt: something is screwy, can you pastebin the section that you tried deleting?
[03:14] <spiv> Oh, it's the /home/mpt/hacking/lp/trivial section in your mail?
[03:15] <mpt> yes
[03:15] <mpt> That section is the entire file
[03:16] <mpt> I mean, what I included in the message is my entire branches.conf file
[03:18] <spiv> mpt: I don't see anything wrong there.
[03:18] <spiv> lifeless: ^
[03:19] <spiv> lifeless: mpt is having issues with the pqm-submit plugin that I can't figure out.
[03:19] <spiv> mpt: you shouldn't get "not a branch", though.
[03:25] <spiv> mpt: in the meantime you could construct the PQM mail manually with, echo -e "star-merge $your_url $rocketfuel_url" | gnome-gpg --clearsign | mail -s "[r=foo]  ..." pqm@...
[03:31] <mpt> ok, I'll try that, thanks
[03:36] <lifeless> mpt: what does pqm-submit show if you give it --dry-run
[03:38] <mpt> lifeless: If branches.conf includes the branch-specific info, --dry-run gives the output I posted to launchpad@ (trying to merge into bzr.dev). If branches.conf doesn't contain the branch-specific info, --dry-run gives me "bzr: ERROR: Not a branch" just like a wet run does.
[03:39] <mpt> So it's bug 55005
[03:39] <Ubugtu> Malone bug 55005 in bzr "After a bzr push --remember, bzr pqm-submit tries to merge to the wrong branch" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55005
[03:40] <lifeless> mpt: pastebin please, there have been a number of messages and I want to see the current details
[03:41] <mpt> ok, one moment
[03:45] <mpt> lifeless: https://sodium.ubuntu.com/~andrew/paste/filenw7dkf.html
[03:46] <lifeless> ok
[03:46] <lifeless> now, remove that section from your config, and do another dry run
[03:46] <lifeless> look in ~/.bzr/log and there will be a backtrace
[03:46] <lifeless> pastebin that please
[03:47] <mpt> ok, it should still be there from the second part of the previous paste
[03:47] <lifeless> https://sodium.ubuntu.com/~andrew/paste/fileUhr5I8.html ?
[03:48] <mpt> was that to me?
[03:49] <mpt> lifeless: oh, you meant ~/.bzr.log :-)
[03:57] <mpt> lifeless: It's 2.4 MB and taking an age to pastebin, shall I mail it instead?
[03:58] <spiv> mpt: there should be a backtrace at the end of the .bzr.log when it gives you that error, just pastebin the backtrace, rather than the whole log.
[03:58] <mpt> ahh
[04:00] <mpt> lifeless: https://sodium.ubuntu.com/~andrew/paste/fileDBZTSP.html
[04:00] <lifeless> whats your branches.conf look like ?
[04:01] <mpt> https://sodium.ubuntu.com/~andrew/paste/fileD40MaV.html
[04:02] <lifeless> well
[04:02] <lifeless> there is no branch called 'branch' 
[04:02] <lifeless> in /home/warthogs/archives/mpt/launchpad
[04:02] <lifeless> on devpad
[04:02] <lifeless> what is your local branch called ?
[04:02] <mpt> "trivial"
[04:03] <lifeless> on your hard disk
[04:03] <mpt> yes
[04:03] <mpt>  /home/mpt/hacking/lp/trivial
[04:03] <spiv> lifeless: /home/mpt/hacking/lp/trivial according to his bzr.log
[04:03] <spiv> (looking at 3rd line)
[04:03] <lifeless> ok
[04:03] <mpt> which is pushed to sftp://devpad.canonical.com/home/warthogs/archives/mpt/launchpad/trivial
[04:03] <lifeless> mpt: cd to /home/mpt/hacking/lp/trivial
[04:03] <lifeless> and run 'bzr inof'
[04:03] <lifeless> erm
[04:03] <lifeless> 'info'
[04:03] <lifeless> pastebin that
[04:04] <mpt> https://sodium.ubuntu.com/~andrew/paste/filevKv1t5.html
[04:09] <lifeless> ok
[04:09] <lifeless> theres no local repository for this branch
[04:09] <spiv> Ah.
[04:09] <lifeless> because of that, the repository heuristics in pqm-submit are failing
[04:09] <lifeless> spiv: can you take it from here ? (get mpt working like you do)
[04:10] <spiv> lifeless: yep
[04:10] <spiv> lifeless: thanks for the diagnosis
[04:10] <lifeless> danke
[04:11] <spiv> mpt: we need to create a repository in /home/mpt/hacking/lp to be shared between your launchpad branches, much like the one on sodium.
[04:12] <mpt> ah, I was meaning to get around to that anyway :-)
[04:12] <mpt> otherwise I'd run out of disk space in a couple of months
[04:12] <spiv> mpt: "bzr init-repo --trees /home/mpt/hacking/lp" will create it (and set it to build working trees by default).
[04:12] <mpt> thanks lifeless
[04:12] <spiv> mpt: then we need to make your launchpad branches use that repo :)
[04:12] <mpt> spiv: and that won't nuke the branches already in that directory?
[04:13] <spiv> mpt: init-repo by itself just makes a .bzr directory with a few basic control files in it.
[04:13] <mpt> ok
[04:13] <mpt> done
[04:13] <spiv> hmm, I think jamesh has a script to simplify this process slightly, just a sec.
[04:14] <mpt> spiv, or if the instructions on https://launchpad.canonical.com/WorkingWithSharedRepositories are still accurate, I can just follow that
[04:15] <spiv> Yeah, they probably are, I'll take a look.
[04:16] <spiv> mpt: they seem ok, although I think they describe how to make a new directory structure for this rather using your existing one.
[04:17] <spiv> mpt: but I guess that's fine.
[04:17] <mpt> well, I'll start from "Adding branches to the Repositories"
[04:18] <spiv> mpt: sounds good.
[04:18] <mpt> ... after deleting my existing ./rocketfuel
[04:18] <spiv> mpt: well...
[04:19] <spiv> mpt: yeah, that's simplest :)
[04:19] <mpt> but, er
[04:19] <mpt> spiv, I don't see how ~/src comes into existence in those instructions
[04:20] <spiv> mpt: you rsync rocketfuel-built to somewhere local?
[04:22] <mpt> yes, /home/mpt/hacking/lp/rocketfuel :-)
[04:22] <spiv> ah.
[04:22] <mpt> (I guess I was right to rename it rather than deleting it...)
[04:22] <spiv> You probably didn't want to delete that, then :(
[04:22] <spiv> Ah, phew.
[04:22] <mpt> :-)
[04:23] <mpt> so, bzr branch ./rocketfuel.old -r 100 rocketfuel
[04:23] <spiv> So the stuff about pulling ~/src/rocketfuel-built doesn't really care about where you have a copy of rocketfuel, just that you have one somewhere.
[04:23] <mpt> right
[04:29] <mpt> spiv, is it ok to get several "Conflict adding file" warnings during those successive pulls? (the ones in the Python block)
[04:32] <spiv> mpt: that doesn't sound right.
[04:32] <spiv> mpt: but should be reasonably harmless, if you do a bzr revert it should tidy it up.
[04:33] <mpt> spiv: https://sodium.ubuntu.com/~andrew/paste/fileAaR2lE.html
[04:33] <mpt> it's ongoing
[04:34] <spiv> mpt: I'll see if I can reproduce that
[04:37] <spiv> Yep, I can, and with current bzr.dev too.
[04:40] <spiv> mpt: I'm pretty certain that's a bug in bzr (or perhaps in our launchpad revision history?), but once its done if you do a revert it should all be fine.
[04:40] <mpt> ok
[04:41] <spiv> mpt: (regardless of silliness in the working tree, the repository of revisions will be intact)
[04:42] <spiv> Hmm, that step would be much quicker if it was just a branch directory with no working tree.  Ah well.
[04:42] <spiv> mpt: I'm off to lunch, but everything should be fine from there.
[04:43] <mpt> thanks spiv
[06:19] <mpt> @#$%&!
[06:19] <spiv> mpt: ?
[06:20] <spiv> (you forgot to include a question mark in your punctuation ;)
[06:21] <mpt> hooray
[06:21] <mpt> After all that repositorying, I forgot about the original bug, and ended up trying to merge into bzr.dev again
[06:22] <mpt> So, the key is to never --remember until the bug is fixed
[09:59] <carlos> danilos: hi, meeting time?
[10:10] <danilos> carlos: ping
[10:12] <sivang> morning matsubara 
[10:14] <matsubara> morning sivang 
[10:18] <ddaa> Good morning.
[10:21] <sivang> hey ddaa 
[10:58] <carlos> stub: hi would be possible to force an staging DB update ?
[10:58] <stub> Sure.
[10:59] <carlos> stub: thanks
[12:14] <SteveA> danilos, carlos, jordi: ping
[12:14] <danilos> SteveA: pong
[12:14] <carlos> SteveA: pong
[12:58] <sivang> morning SteveA 
[12:59] <SteveA> hi
[01:21] <jamesh> carlos: I just replied to mpt's message about the 98-cocacknowledge.txt error -- the bug should be pretty easy to fix
[01:22] <carlos> jamesh: ok, let me see
[01:22] <mpt> yay
[01:22] <carlos> mpt: will you fix it ? or should I do it?
[01:22] <jamesh> mpt: it is a test that would only pass yesterday
[01:23] <mpt> Ah, so I was being punished for being too slow :-)
[01:23] <stub> timebomb
[01:24] <jamesh> which was quite convenient, since it was merged yesterday
[01:24] <mpt> carlos, I won't be able to fix it in the next 10 hours
[01:24] <carlos> mpt: I will do it then
[01:25] <spiv> jamesh: ah, those good ol' "[trivial] " commits :)
[01:33] <kgoetz> i just had a quick look and cant find a bug (but i'll ask if someone heres seen one): is there a bug open on marking support requests as dupes? i have 3 or 4 requests that can be marked as dupes, and it would save me linking all of them to the same 4 bug reports each time
[01:37] <jamesh> kgoetz: I don't think duplicate support requests are supported.  You can link multiple requests to a single bug though
[01:39] <kgoetz> jamesh: thanks. perhaps i will file a bug on it then, linking to a bug to mark requests as dupes seems a bit unintutive
[01:41] <jamesh> kgoetz: when he comes on line, perhaps you could talk to flacoste
[01:41] <jamesh> kgoetz: he is working on the support tracker these days
[01:42] <kgoetz> ok. i'll just pm that to myself. thanks jamesh 
[01:47] <danilos> jamesh: hi, pushing from a branch of local shared repository to devpad shared repository is like really slow, is that normal?
[01:48] <danilos> jamesh: should I maybe rsync it instead?
[01:49] <LarstiQ> danilos: what format are they in?
[01:49] <LarstiQ> danilos: and how slow is slow?
[01:49] <danilos> LarstiQ: like taking 40 minutes already
[01:49] <LarstiQ> danilos: and how much are you pushing exactly?
[01:49] <danilos> LarstiQ: they are all in knit format
[01:50] <danilos> "how much" as in?
[01:50] <danilos> revisions?
[01:50] <LarstiQ> yeah
[01:50] <jamesh> danilos: whether the local branch is in a repo or not shouldn't make a difference
[01:51] <danilos> well, I only have one revision, but I need to push them all (so ~3800, but I thought those would be picked up from shared repo on devpad)
[01:51] <jamesh> danilos: maybe you could try creating a basis branch remotely to push to and see if that makes a difference
[01:51] <spiv> jamesh: (although if the local branch isn't in a repo the pqm-submit plugin will get confused)
[01:52] <LarstiQ> danilos: if those revisions actually are in the remote repo, yes. Otherwise you'll be pushing all of it
[01:52] <spiv> danilos: if those ~3800 already exist in the remote repo, then you're right, it should be pretty quick.
[01:52] <jamesh> danilos: i.e. ssh to devpad and run "bzr branch -r $REV_I_BRANCHED_FROM /home/warthogs/archives/rocketfuel/launchpad/devel $DEST"
[01:52] <danilos> jamesh: ok, I'll try that
[01:52] <spiv> danilos: It usually takes ~4 minutes for me to push changes for a launchpad branch (and ~8 min to push a new launchpad branch).
[01:52] <jamesh> spiv: new branch or existing branch?
[01:53] <danilos> well, it's been long since 8 minutes
[01:53] <jamesh> ah
[01:53] <spiv> jamesh: ~4 for existing, ~8 for new.
[01:53] <spiv> danilos: Right, it definitely sounds like something has gone wrong for you.
[01:53] <danilos> btw, should I do push from repo or working directory?
[01:54] <spiv> danilos: from the branch directory; you push branches rather than repos.
[01:55] <spiv> Your repo on sodium seems to have rocketfuel in it already (I just checked the output of "bzr info /home/warthogs/archives/danilo/launchpad/")
[01:56] <danilos> spiv: I meant repo/launchpad/branchname vs. work/launchpad/branchname (checkouts)
[01:56] <SteveA> spiv: "your repo on devpad"
[01:56] <spiv> danilos: oh, right.  I'm not sure, I have my checkouts in my branches.  I wouldn't expect it to make a difference, but I'm not certain.
[01:56] <spiv> SteveA: that too ;)
[01:57] <ddaa> danilos: you just have to be in a bzrdir which has a branch, a repo or a checkout both have one
[01:57] <danilos> ddaa: ok, great to hear that it doesn't make a difference
[01:57] <ddaa> even light checkouts have a branch, it's effectively symlink
[01:57] <carlos> cprov: hi, around?
[01:57] <danilos> ddaa: yeah, I am talking of lightweight checkouts
[01:57] <cprov> carlos: yup
[01:58] <carlos> cprov: I'm getting a test error on distrorelease.txt
[01:58] <carlos> I did some changes there about translations
[01:58] <danilos> crap, bzr: ERROR: Could not acquire lock LockDir(/home/warthogs/archives/danilo/launchpad/.bzr/repository/lock)
[01:58] <spiv> danilos: you can only push one branch into a repository at a time.
[01:58] <mpt> danilos, are you pushing or pulling any other branch? You can't do more than one if you're using a repository
[01:59] <carlos> but the error is https://sodium.ubuntu.com/~andrew/paste/filerjBSP2.html
[01:59] <mpt> danilos, If not, bzr break-lock
[01:59] <carlos> cprov: I don't know how my changes could cause that error
[01:59] <cprov> carlos: looking ...
[01:59] <danilos> mpt: well, I cancelled one with C-c, so it probably didn't end up yet
[01:59] <carlos> cprov: https://sodium.ubuntu.com/~andrew/paste/fileDBItyM.html <- Full test
[01:59] <SteveA> and now it's time for...
[02:00] <SteveA> yet another launchpad development meeting
[02:00] <malcc> Yay
[02:00] <SteveA> GOOD MORNING!
[02:00] <SteveA> who's here?
[02:00] <malcc> me
[02:00] <mpt> me
[02:00] <matsubara> me
[02:00] <Kinnison> me
[02:00] <BjornT> me
[02:00] <spiv> me
[02:00] <Kinnison> (for the last time)
[02:00] <carlos> me
[02:00] <stub> me
[02:00] <ddaa> me
[02:00] <danilos> me
[02:00] <bradb> me
[02:00] <cprov> me
[02:00] <SteveA> kiko-zzz: ?
[02:01] <stub> Agenda:
[02:01] <stub>  * Roll call  * Agenda  * Next meeting  * Activity reports  * Actions from last meeting  * Oops report (Matsubara)  * Bug report report (mpt)  * Production and staging (Stuart)  * Launchpad 1.0 status reports  * Sysadmin requests ----  * Python demo status update (James H)  * Approving new bug tags (Brad)  * Proper use of PendingReviews (Robert)  * (other items) ----  * Keep, Bag, Change  * Three sentences  
[02:01] <kiko-zzz> morning
[02:01] <stub> Next meeting same bat time, same bat channel?
[02:01] <salgado> me
[02:02] <stub> Any objections?
[02:02] <stub> 5
[02:02] <stub> 4
[02:02] <stub> 3
[02:02] <mpt> I'll be in transit
[02:02] <stub> excused
[02:02] <stub> 2
[02:02] <mpt> Sic transit, gloria Thursday
[02:02] <stub> 1
[02:02] <ddaa> I'll be on vacation
[02:02] <stub> Ok two down, but enough to keep the meeting for next week same day/time/channel
[02:02] <stub> Activity reports. Who is up to date?
[02:03] <stub> me
[02:03] <kiko> me
[02:03] <spiv> me
[02:03] <ddaa> me
[02:03] <BjornT> me
[02:03] <flacoste> me
[02:03] <SteveA> not me (I have been sprinting)
[02:03] <matsubara> i'm not
[02:03] <danilos> me
[02:03] <bradb> me, after sending yesterday's right now...
[02:03] <malcc> merriam, summary
[02:03] <carlos> I'm not...
[02:03] <mpt> not up to date
[02:03] <danilos> (but summarized last week)
[02:03] <salgado> I'm not
[02:03] <malcc> me
[02:03] <malcc> summary
[02:03] <malcc> (auto-complete madness)
[02:03] <stub> james is excused due to sprinting this week
[02:03] <Kinnison> malcc: fairly mad yes
[02:04] <cprov> me
[02:04] <stub> Thanks for getting back on track danilos
[02:04] <ddaa> malcc: merry auto-complete
[02:04] <Kinnison> I'm not up to date
[02:04] <stub> And Bjorn
[02:04] <stub> Kinnison: Should we expect activity reports between now and you heading off?
[02:04] <jamesh> me
[02:04] <jamesh> I'm not up to date
[02:05] <Kinnison> stub: Given it's today and tomorrow, it seems unlikely
[02:05] <stub> :-)
[02:05] <spiv> Kinnison: what about after? ;)
[02:05] <Kinnison> spiv: For that, you'll have to watch my blog
[02:05] <stub> Action items from last meeting
[02:05] <Kinnison> (ooer)
[02:05] <stub>  * mpt to mail kiko, CCing the list, when [https://help.launchpad.net/MaloneHighlights MaloneHighlights]  screenshots are done  * malcc, cprov, to document Soyuz bug tags  * mpt and bradb to work together on Launchpad bug tags  
[02:05] <stub> MaloneHghlights is cool
[02:05] <kiko> mpt did that. I don't think soyuz stuff was done
[02:06] <mpt> I did the screenshots and mailed the list, but didn't work with bradb
[02:06] <malcc> cprov did some work on the Soyuz tags, but it's been another crazy week in Soyuz land, I don't know if it got finished
[02:06] <bradb> there was no work that i know of that mpt and i needed to do with bug tags
[02:06] <cprov> kiko: it's not, we need to sort that product deletion first.
[02:06] <stub> So do we have soyuz bug tags and general Launchpad bug tags documented somewhere? Or is it still pending
[02:07] <kiko> stub, LaunchpadTagUsage or something
[02:07] <bradb>    https://help.launchpad.net/TaggingLaunchpadBugs
[02:07] <stub> malcc, cprov: Is that suitable for soyuz too?
[02:08] <stub> oops, ui, timeout seems to not be particularly comprehensive for soyuz
[02:08] <stub> So it should remain an action item? malcc, cprov?
[02:08] <cprov> stub: not really, we need to decide if we will contribute or not with project-wide tags, except "ui" 
[02:09] <cprov> stub: yes, please, we will sort it at some point this week
[02:09] <stub> ok. Two done, one to go.
[02:09] <stub> OOps report with our host Matsubara...
[02:09] <matsubara> Today's oops report is about bug 44860 which is up for review on kiko's queue. kiko would you be able to answer that today so danilos can merge it?
[02:09] <Ubugtu> Malone bug 44860 in rosetta "Crash when we try to pass a query string to a POFile that doesn't exist yet." [Critical,In progress]  http://launchpad.net/bugs/44860
[02:09] <kiko> matsubara, I reviewed it last night, will send out today
[02:10] <matsubara> thanks kiko 
[02:10] <matsubara> Also danilos and kiko, you guys are taking care of the +translate page time out (bug 30602), aren't you?
[02:10] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:10] <danilos> matsubara: yeah, I'm working on 30602
[02:10] <matsubara> okie danilos thanks. I'm done stub
[02:10] <danilos> matsubara: I have some ideas to test when staging is refreshed
[02:10] <kiko> sorta
[02:11] <stub> Ok. On to bug reports with mpt.
[02:11] <matsubara> danilos: great. let's talk about it after the meeting.
[02:11] <mpt> There are 14 Critical bugs known in Launchpad. Today we're looking at the oldest 6 of them:
[02:11] <mpt> * Bug #2497 (/people/*/+translations times out for prolific translators), Confirmed, Critical, kiko
[02:11] <mpt> kiko, how's it going?
[02:11] <Ubugtu> Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Critical,Confirmed]  http://launchpad.net/bugs/2497
[02:11] <danilos> matsubara: ok
[02:11] <mpt> * Bug #30602 (ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate), Confirmed, Critical, danilos
[02:11] <mpt> That was already discussed in the Oops report
[02:11] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:11] <mpt> * Bug #31038 (private), Fix Committed, Critical, cprov
[02:11] <mpt> Well done cprov! Remember to verify it after the next rollout
[02:11] <mpt> * Bug #31609 (buildd maintainers need to be informed of build failures), 
[02:11] <mpt> In Progress, Critical, cprov
[02:11] <Ubugtu> Malone bug 31609 in soyuz "buildd maintainers need to be informed of build failures" [Critical,In progress]  http://launchpad.net/bugs/31609
[02:11] <kiko> mpt, stub offered to help
[02:12] <mpt> * Bug #35965 (exceptions in process-upload not communicated to uploader), Confirmed, Critical, malcc
[02:12] <Ubugtu> Malone bug 35965 in soyuz "exceptions in process-upload not communicated to uploader" [Critical,Confirmed]  http://launchpad.net/bugs/35965
[02:12] <cprov> mpt: sure, tks
[02:12] <mpt> * Bug #31308 (Cannot set branch associated to a product series), Confirmed, Critical, waiting until lifeless finishes bzr work
[02:12] <Ubugtu> Malone bug 31308 in launchpad-bazaar "Cannot set branch associated to a product series" [Critical,Confirmed]  http://launchpad.net/bugs/31308
[02:12] <mpt> malcc, are you making progress on 35965?
[02:12] <stub> kiko: Poke me after please. I think I have an email to respond to on that.
[02:12] <malcc> mpt: process-upload is strewn across my desk in parts at the moment, in the form of my process-upload-tidy branch, which is in review
[02:13] <kiko> stub, sure
[02:13] <malcc> mpt: I need to land that first before I start making more changes to the same code
[02:13] <mpt> ok
[02:13] <ddaa> 31308: braindumped some spec on the ML, waiting for sabdfl feedback, as I think a schema change would make it much simpler.
[02:13] <mpt> Since that was so quick we'll do a couple more
[02:13] <mpt> * Bug #44860 (Crash when we try to pass a query string to a POFile that doesn't exist yet), In Progress, Critical, danilos
[02:13] <Ubugtu> Malone bug 44860 in rosetta "Crash when we try to pass a query string to a POFile that doesn't exist yet." [Critical,In progress]  http://launchpad.net/bugs/44860
[02:13] <mpt> danilos, any blockers?
[02:13] <mpt> * Bug #48860 ("Also notified" makes difficult to unsubscribe), Confirmed, Critical, bradb
[02:13] <Ubugtu> Malone bug 48860 in malone ""Also notified" makes difficult to unsubscribe" [Critical,Confirmed]  http://launchpad.net/bugs/48860
[02:13] <mpt> bradb, have you worked out how to fix that one yet? :-)
[02:13] <danilos> mpt: nope, this one is waiting for kiko's review (just test changes and improvements)
[02:13] <matsubara> that's the one which will be sorted today
[02:13] <ddaa> In effect, the schema change would ack that vcs-import != productseries and allow the vcs-import branch to be different from the productseries branch
[02:14] <bradb> mpt: haven't even thought about it
[02:14] <mpt> danilos, great
[02:14] <kiko> danilos, I reviewed it yesterday so it will go out today
[02:14] <bradb> i have some ideas that i'll think through further when i get time
[02:14] <danilos> kiko: ah, ok, great, thanks :)
[02:14] <mpt> bradb, kiko said it doesn't involve reintroducing ignore subscriptions, but just quietly I think it might :-)
[02:14] <mpt> anyway, that's all SteveA
[02:14] <bradb> mpt: heh
[02:14] <kiko> mpt, it's easy to fix that one -- make it unsubscribe the user from whatever bug his subscription comes from.
[02:14] <mpt> ddaa, are you able to take over 31308?
[02:15] <kiko> mpt, that doesn't require an ignore subscription.
[02:15] <kiko> (which is an aberration)
[02:15] <mpt> But then if the bug gets reopened, he's marooned
[02:15] <mpt> anyway
[02:15] <SteveA> mpt meant "that's all stub"
[02:15] <mpt> this is not a design meeting
[02:15] <kiko> mpt, that's too bad.
[02:15] <mpt> Sorry, yes, that's all stub
[02:15] <bradb> kiko: have to consider the "Also notified" case of being a bug contact
[02:15] <SteveA> I like the colour maroon, fwiw
[02:15] <stub> Production and staging (this week LIVE!)
[02:15] <ddaa> mpt: I have effectively taken it, at least until the design is settled.
[02:15] <kiko> bradb, he can't unsubscribe. next question. :)
[02:15] <stub> Staging is still not autoupdating. Blocked on RT605 I think, which should really be simple.
[02:16] <stub> We have discovered why passing through Host: headers to the production systems would screw up the vhosting. It was working on staging because not all the vhosts were getting the header passed through.
[02:16] <stub> (We will hopefully fix that today)
[02:17] <stub> We are currently working out ways to avoid downtime for rosetta translations for dapper and edgy. This discussion is ongoing.
[02:17] <SteveA> salgado: we'll be looking at making shipit use the new vhosting stuff
[02:17] <stub> I think that is all. Questions on my gibberish?
[02:18] <SteveA> salgado: testing on staging first
[02:18] <salgado> SteveA, cool!
[02:18] <SteveA> so, some time from salagdo/matsubara to test this on staging will be appreciated
[02:18] <SteveA> before we roll it out
[02:18] <sivang> hrm, is the meeting now?
[02:18] <SteveA> hi sivan
[02:18] <stub> staging will be brought back up after the meeting, as the db update is now done
[02:18] <sivang> re SteveA 
[02:18] <SteveA> the meeting is at the same time each week! :-)
[02:18] <stub>  * Launchpad 1.0 status reports
[02:18] <carlos> sivang: every Thursday at 12:00 UTC
[02:19] <danilos> Rosetta 1.0:
[02:19] <danilos> - firefox import/export: stalled for bug-fixing (good progress previously)
[02:19] <danilos> - oo import/export: blocked on firefox
[02:19] <danilos> - translation review: carlos to start on today
[02:19] <SteveA> and also... opening edgy
[02:19] <SteveA> that's important, so really should be a spec
[02:19] <danilos> hum, haven't thought about it that way
[02:19] <SteveA> with our latest plan in there
[02:19] <kiko> indeed I have no idea what's going on there.
[02:19] <SteveA> it's a big chunk of work
[02:20] <danilos> carlos, care to create one?
[02:20] <SteveA> kiko: I'll fill you in after the meeting
[02:20] <SteveA> but i think a spec will be good, anyway
[02:20] <SteveA> and make this a 1.0 feature, critical
[02:20] <sivang> SteveA: right, it's even in the topic - I just had to run off for some real life stuff, and lost track of time. bad sivang!
[02:20] <danilos> SteveA: sure, lets just try not to get lost in this
[02:21] <SteveA> thanks danilos 
[02:21] <stub> Malone? Soyuz?
[02:21] <cprov> kiko: I suppose will be sorting Soyuz-1.0 porperly in the sprint, is that ok or do you want a braindump before it 
[02:21] <kiko> danilos, it's more likely you'll get lost without a spec. :)
[02:21] <carlos> - opening edgy to translations: code in place, planning the script run and blocked on adding a 'read only' mode for Rosetta
[02:21] <cprov> properly ....
[02:21] <danilos> kiko: nah, I am thinking of getting lost in all the things we've got to do :)
[02:22] <bradb> Malone 1.0: release management considered harmful (still at least a few hours of UI fixes left), guided bug filing halted around 40% of the way right now
[02:23] <stub> bored now
[02:23] <bradb> oh, and writing the help doc is blocked on the above
[02:23] <kiko> there is more malone work...
[02:23] <kiko> cprov, go over what the current status is, regardless
[02:24] <kiko> flacoste?
[02:24] <BjornT> More Malone 1.0: simple bug keywords - almost done. keeping bugs concise - almost done
[02:24] <flacoste> Question Tracker 1.0
[02:24] <flacoste> - New workflow (search before creation in review, rest is stalled pending
[02:24] <flacoste> further review of the spec by Kiko)
[02:24] <flacoste> - New views (pending implementation of new workflow)
[02:24] <flacoste> - Karma in the question tracker (???)
[02:24] <flacoste> - Localization (not started) 
[02:24] <cprov> anyway, Soyuz 1.0, will basically consists of establishment of current infrastructure, performance imporvements, specially in publisher land and PPA
next week, i'll make sure to ask BjornT beforehand, and have the report paste-ready</suckage>
[02:24] <flacoste> actually, Karma assignment in the question tracker is implemented as of yesterday
[02:24] <kiko> cprov, we know what it will consist of. what's the current status. :)
[02:25] <BjornT> stub, kiko: btw, what exactly are these status updates supposed to contain, apart from what's available at 1.0/+specs?
[02:25] <SteveA> Localization?
[02:25] <cprov> right, PPA have been discussed a lot, good progress in spec, has mark approval
[02:25] <stub> BjornT: I have no idea. I only work here.
[02:25] <flacoste> SteveA: that's an approved spec for the question tracker
[02:25] <SteveA> flacoste: what do you mean by Localization?
[02:25] <kiko> BjornT, a progress report, essentially.
[02:25] <flacoste> SteveA: ability to post a question and get it answered in a non-English language
[02:25] <kiko> cprov, no, PPA is in a shambles -- no progress so far at all!
[02:26] <flacoste> SteveA: https://launchpad.net/products/launchpad-support-tracker/+spec/localized-support
[02:26] <BjornT> kiko: isn't the +specs page enough for that? did you send an email about this?
[02:26] <salgado> SteveA, https://launchpad.canonical.com/LocalizedSupportRequests
[02:26] <kiko> BjornT, there was a meeting topic about it last week. and no, the specs page is not enough -- this is to talk about how it's going, what's hard, what's not, etc.
[02:26] <cprov> kiko: several critical bugs fixed and good performance improvement in cron.daily, we are saved up to 15 minutes in average (currently under 30 minutes most of the times)
[02:27] <kiko> cprov, yeah. good work!
[02:27] <kiko> SteveA, infrastructure/launchpad 1.0?
[02:27] <BjornT> kiko: well, <SteveA> kiko: yep. let's discuss the format later and try it next week. <SteveA> we'll mail out something early next week 
[02:27] <SteveA> flacoste: we already have a spec on localizing launchpad.
[02:27] <cprov> kiko: even if it's not implemented yet, i think it's worth to mention that we have a established plan for PPA, finally ;)
[02:27] <SteveA> flacoste: I don't see a mention of that in the support tracker spec
[02:27] <kiko> cprov, we don't AFAIK. since when?
[02:27] <kiko> SteveA, it's just a special case for the support tracker.
[02:28] <SteveA> flacoste: I also find it surprising that the spec involves adding launchpad infrastructure, yet hasn't had a review by the infrastructure team
[02:28] <cprov> kiko: ehe, since last meeting from malcc & mark
[02:28] <kiko> cprov, yesterday? :)
[02:28] <SteveA> kiko: it talks about localizing the application
[02:28] <cprov> kiko: yes
[02:28] <SteveA> kiko: and internationalizing it is needed before localizing, surely
[02:28] <kiko> SteveA, ask me after the meeting
[02:28] <SteveA> kiko: ok.  phone call after the meeting
[02:28] <kiko> IRC
[02:28] <SteveA> nope
[02:28] <SteveA> gotta lunch
[02:28] <kiko> then email
[02:28] <SteveA> nope
[02:28] <SteveA> too busy, won't read
[02:28] <cprov> kiko: nothing special changed, but we don't have any blockers, which is very good, IMO
[02:28] <SteveA> and we need a catchup
[02:28] <kiko> next week then.
[02:29] <SteveA> before the call tomorrow
[02:29] <stub> Are we done on 1.0 status reports?
[02:29] <stub> If so,  * Sysadmin requests
[02:29] <stub> RT 605 from memory
[02:29] <danilos> #14579 (VoIP: in its third week so far)
[02:30] <stub> Which needs rocketfuel-built mirrored to asuka at a minimum (2nd or third week)
[02:30] <stub> 5
[02:30] <stub> 4
[02:30] <stub> 3
[02:30] <stub> 2
[02:30] <stub> 1
[02:31] <kiko> 0
[02:31] <stub> James says  * Python demo status update (James H)n isn't needed
[02:31] <stub>  * Approving new bug tags (Brad)
[02:31] <bradb> https://help.launchpad.net/TaggingLaunchpadBugs
[02:31] <stub> Anything to add that isn't on the wiki page?
[02:31] <bradb> there are more tags for review and approval
[02:32] <bradb> not from me right now
[02:32] <kiko> I thought a bit about this yesterday
[02:32] <kiko> which is why I proposed the codeofconduct and rosetta-imports tags
[02:33] <kiko> there are a lot of bugs that should be categorized like this
[02:33] <SteveA> ok
[02:33] <stub> search seems a bit vague
[02:33] <SteveA> I'm +1 on rosetta-imports
[02:33] <kiko> my question is: should we group "categories" or "components" using tags as well.
[02:33] <danilos> +1 on rosetta-imports
[02:33] <SteveA> I'm +1 on CoC (although, maybe it should be a product... :-/ )
[02:33] <mpt> In most applications that use tags, the way to get them approved is to start using them
[02:34] <carlos> rosetta-imports++
[02:34] <mpt> Perhaps the approval process should be replaced by the ability to combine two tags into one?
[02:34] <matsubara> xmlrpc sounds useful, I can think of a couple of bugs that could use it.
[02:34] <ddaa> mpt++
[02:34] <SteveA> and I'm +1 on cleanup
[02:34] <ddaa> less worflow, more forgiving ui, please
[02:34] <SteveA> I'm dubious about "search"
[02:34] <danilos> mpt: and maybe even renaming tags?
[02:35] <mpt> danilos, sure
[02:35] <SteveA> I'd likek to see examples for the others before I give my own approval for them
[02:35] <stub> Open a spec or wishlist item on merging and renaming tags if people want that.
[02:35] <kiko> yeah.
[02:35] <danilos> I'd be +1 for trivial as well
[02:36] <SteveA> next week, and let's see some examples before then
[02:36] <stub> Onto * Other items
[02:36] <stub> Other items anyone?
[02:36] <stub> 6
[02:36] <jamesh> LaunchpadFormView
[02:36] <stub> 5
[02:37] <jamesh> This is the stuff me and BjornT were working on last week
[02:37] <jamesh> it is a new base class for developing forms, as a replacement for GeneralFormView and the other form view classes
[02:38] <danilos> jamesh: ah, nice, any API docs somewhere?
[02:38] <sivang> jamesh: flacoste noted it could make it easier to have custom error messages per invalidated input on Choice() ?
[02:38] <jamesh> It provides a cleaner api, and has a few new features (multiple submit buttons, customising submit button labels, etc)
[02:38] <jamesh> there is some docs in lib/canonical/launchpad/doc/launchpadform.txt
[02:39] <jamesh> at this point we'd like people writing new forms to try and use LaunchpadFormView
[02:39] <mpt> yay for custom labels
[02:39] <jamesh> but eventually we'd like to move all the forms over
[02:39] <SteveA> we're working on some better widget stuff here in london at the moment
[02:39] <SteveA> but that's not finished yet
[02:39] <jamesh> There will be a few more features being added in the future
[02:39] <danilos> jamesh: cool, thanks for that, I'll certainly look into it
[02:40] <SteveA> reviewers: please note that new forms should use the new LaunchpadFormView stuff
[02:40] <danilos> well, and thanks to BjornT as well :)
[02:40] <ddaa> Good to know, I'm dusting off some old web ui work now. I'll hold back the form improvements,
[02:40] <jamesh> in my branch I've got support for overriding a widget's error message, and setting initial form focus without the tabindex problems we've currently got
[02:40] <flacoste> jamesh: so that hasn't landed yet?
[02:40] <jamesh> flacoste: those two improvements I listed above haven't, no.
[02:40] <jamesh> flacoste: should go in soon though.
[02:41] <BjornT> SteveA: is there a spec/notes on the new widget stuff?
[02:41] <SteveA> we're writing them now
[02:41] <SteveA> so, not up yet
[02:41] <BjornT> ok
[02:41] <jamesh> that's about it.  If you have problems with the new infrastructure, mail the list, file a bug or ping me or Bjorn on IRC
[02:41] <mpt> Can/should make check include a countdown on the number of forms still using the old *FormViews?
[02:41] <stub> * Keep, Bag, Change
[02:41] <stub> 7
[02:42] <stub> 6
[02:42] <stub> 5
[02:42] <stub> 4
[02:42] <stub> 3
[02:42] <ddaa> CHANGE: move vcs-import data out of ProductSeries
[02:42] <flacoste> jamesh: what about AddView and EditView... maybe after the meeting
[02:42] <stub> 2
[02:42] <stub> 1
[02:42] <bradb> change: weekly tag approval
[02:42] <SteveA> bradb: talk with me later about what you'd like to change
[02:42] <jamesh> flacoste: talk after meeting
[02:42] <SteveA> specifically
[02:42] <bradb> SteveA: ok
[02:43] <stub> ddaa: Is that something for your Monday meeting?
[02:43] <SteveA> ddaa: raise that in monday' s meeting
[02:43] <ddaa> ok
[02:43] <stub>  * Three sentences
[02:44] <malcc> DONE: Landed bug 54039, process-upload-tidy review response, drescher rollout (+bug 55877), finished handover with Kinnison, met with Mark, initial PPA planning.
[02:44] <malcc> TODO: PPA. PPA. PPA. Land process-upload-tidy, then bug 35965.
[02:44] <malcc> BLOCKED: No.
[02:44] <Ubugtu> Malone bug 54039 in soyuz "Broken release files in unchanged pockets" [Critical,Fix released]  http://launchpad.net/bugs/54039
[02:44] <Ubugtu> Malone bug 55877 in soyuz "cron.daily tickling mirrors before cleaning up" [Critical,Fix released]  http://launchpad.net/bugs/55877
[02:44] <mpt> DONE: bug fixes, MaloneHighlights artwork, set up local repository
[02:44] <mpt> TODO: travel to London, Launchpad sprint, travel to Vilnius
[02:44] <mpt> BLOCKED: bug 55005 is annoying; terrorists
[02:44] <Ubugtu> Malone bug 35965 in soyuz "exceptions in process-upload not communicated to uploader" [Critical,Confirmed]  http://launchpad.net/bugs/35965
[02:44] <flacoste> DONE IBugLinkTargets now use a selection to remove bugs. Switch to a new
[02:44] <flacoste> laptop. Started adding search to link bug UI.
[02:44] <Ubugtu> Malone bug 55005 in bzr "After a bzr push --remember, bzr pqm-submit tries to merge to the wrong branch" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55005
[02:44] <danilos> DONE: worked on bug 30602 (taking a lot of my time), (attempts at) pqm-submit 1788
[02:44] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:44] <sivang> DONE: Sent 2 patches to Kiko, one [trivial]  for fixing some instructions caption on blueprint's +addspec - landed, and another waiting to be merged fixing malone #52038.
[02:44] <flacoste> TODO Enjoy the beach at Cape Cod
[02:44] <danilos> TODO: bug 30602, put bug 2237 on review, pqm-submit 44860, finish firefox import
[02:44] <danilos> BLOCKED: no
[02:44] <matsubara> DONE: sprint, new oops format spec, new format for oops report analysis together with james
[02:44] <matsubara> TODO: finish the spec on the new oops format, implement the parser for it.
[02:44] <matsubara> BLOCKED: no
[02:44] <Ubugtu> Malone bug 52038 in blueprint "Please rename "Braindump" state to "New"" [Wishlist,In progress]  http://launchpad.net/bugs/52038
[02:44] <flacoste> BLOCKED Waiting for kiko's review of SupportTrackerSpec and tt-search/nl
[02:44] <Ubugtu> Malone bug 30602 in rosetta "ERROR IN: https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+pots/vlc/tl/+translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:44] <sivang> TODO: Crunch more important bugs, specifically with interest in helping bradb with UI fixes as much as I can, mind some mentoring and showing around.
[02:44] <BjornT> DONE: code reviews. various work on bug tags. code reviews.
[02:44] <bradb> DONE: Release management, some bug fixes, improving Upstream status filter options.
[02:44] <BjornT> TODO: finish up the bug tags stuff. start on bug forwarding workflow.
[02:44] <flacoste> -query branch
[02:44] <BjornT> BLOCKED: no
[02:44] <Ubugtu> Malone bug 2237 in rosetta "Preferred languages (and link to change them) twice on translation template page" [Medium,In progress]  http://launchpad.net/bugs/2237
[02:44] <Kinnison> DONE: last bits of handover, verifying branch status for malcc, writing of archive-checker design document for malcc, unsubbing from bugs etc.
[02:44] <sivang> BLOCKED:  none
[02:44] <bradb> TODO: Put release management up for review.
[02:44] <cprov> DONE: commiting soyuz/+spec/overrides-consistency-check (archive-tools), bug fixes for #31038 (dup uploads check, queue-ui), bug #54649 (supporting custom uploads in queue tool,  small-fixes), soyuz rollout (3823, 3824, 3825, 3835, 3837, 3848,3855, 3875), PPA & ArchiveRework specification update, Soyuz Metting (VOIP), code reviews.
[02:44] <cprov> TODO: PPA (support for PPA in poppy), get code reviewed and merge old fixes
[02:44] <cprov> BLOCKED: None
[02:44] <Ubugtu> Malone bug 54649 in soyuz "queue tool accept/reject actions don't support custom formats" [Critical,Fix committed]  http://launchpad.net/bugs/54649
[02:44] <jamesh> DONE: sprint (Vilnius and London), LaunchpadFormView work, clean up OOPS analysis scripts with matsubara
[02:44] <jamesh> TODO: finish London sprint, code reviews, dyson fix
[02:44] <jamesh> BLOCKED: no
[02:44] <Kinnison> TODO: Finish polish of document, unsub from lists, last few bugs, specs etc, any last minute HRness which may turn up.
[02:44] <bradb> BLOCKED: No.
[02:44] <spiv> DONE: Holiday!  Progress on bzr smart server.  Reviews.
[02:44] <spiv> TODO: Reviews.  bzr smart server.
[02:44] <spiv> BLOCKED: no.
[02:44] <ddaa> DONE: tweak branch table, importd-bzr-upgrade, importd-publish-source
[02:44] <ddaa> TODO: rollout importd-bzr-upgrade, more importd-publish-source (bug 37897), extend $branch/+edit (bug 51130).
[02:44] <ddaa> BLOCKED: no
[02:44] <Ubugtu> Malone bug 37897 in launchpad-bazaar "renaming project, product or series breaks vcs imports" [High,Confirmed]  http://launchpad.net/bugs/37897
[02:44] <Kinnison> BLOCKED: No
[02:44] <stub> DONE: Sprint
[02:44] <Ubugtu> Malone bug 51130 in launchpad-bazaar "cannot rename a branch I own" [Critical,Confirmed]  http://launchpad.net/bugs/51130
[02:44] <stub> TODO: Sprint
[02:44] <stub> BLOCKED: Sprint
[02:44] <SteveA> DONE: sprints, meetings
[02:44] <salgado> DONE: Implemented SupportTrackerKarma, code review, lots of random fixes
[02:44] <salgado> TODO: Get my branches reviewed and land them, lots of code review, more random fixes
[02:44] <salgado> BLOCKED: No
[02:44] <SteveA> TODO: sprints, meetings
[02:44] <SteveA> BLOCKED: no
[02:44] <kiko> DONE: fix CoC workflow, launchpad reports, catching up, reviews
[02:44] <kiko> TODO: more reviews, more fixing of CoC workflow
[02:44] <kiko> BLOCKED: no
[02:44] <carlos> DONE: vacations, migrate translations, XaraLX deletions, pending mail, user support
[02:45] <carlos> TODO: Add a way to put Rosetta in read only mode, start TranslationReviews spec, finish catching up with email
[02:45] <carlos> BLOCKED: no
[02:45] <SteveA> kiko: we can shorten that to "CoCFlow"
[02:45] <kiko> not if we want to keep this channel PG-13
[02:45] <sivang> kiko: heh
[02:45] <stub> Done! Go home!
[02:45] <carlos> ;-)
[02:45] <SteveA> thanks stu
[02:46] <SteveA> and an on-time meeting too!
[02:46] <kiko> niemeyer, CoC signing workflow
[02:46] <jamesh> kiko: that doesn't sound much better :)
[02:46] <niemeyer> stub: I hope I manage to do that on saturday
[02:46] <carlos> cprov: I will have lunch now. Could we talk when I'm back?
[02:46] <kiko> jamesh, it wasn't meant to :)
[02:46] <cprov> carlos: ohh, ok
[02:47] <LarstiQ> kiko: does the signing result in a CoC ring of trust?
[02:47] <stub> A CoC ring?
[02:48] <jamesh> flacoste: re: AddViews and EditViews, we included a LaunchpadEditFormView class that includes a helper that implements most of the boilerplate found in the action method
[02:48] <jamesh> flacoste: we didn't see much benefit in a separate AddView given the way the forms are used in most of Launchpad
[02:48] <mpt> LarstiQ, this reminds me of Microsoft's Customer Update and Notification Tool
[02:49] <jamesh> flacoste: of course, I'm open to suggestions if you disagree
[02:49] <flacoste> jamesh: so you don't intend to convert most LaunchpadAddView to form?
[02:49] <LarstiQ> mpt: heh
[02:49] <jamesh> flacoste: the intent would be to convert most AddView style forms to LaunchpadFormView directly
[02:50] <jamesh> flacoste: rather than having a separate base class for them
[02:50] <flacoste> jamesh: nah, I think that for simple cases LaunchpadAddView and LaunchpadEditView are fine, if you need anything more fancy, you would use LaunchpadEditView directly
[02:50] <flacoste> jamesh: ok
[02:51] <jamesh> flacoste: the LaunchpadEditFormView just makes sure the fields get filled in with values from the context, and provides a method to apply the changes to the context and sends an SQLObjectModifiedEvent
[02:52] <jamesh> flacoste: (note that SQLObjectModifiedEvent is not really specific to SQLObject)
[02:53] <flacoste> jamesh: ok, i'll take a closer look at LaunchpadFormView as it landed in RF and send you my comments
[02:53] <SteveA> flacoste: I'd like to talk with you later about the i18n stuff
[02:53] <flacoste> jamesh: I've already started using formlib for some forms, so I'll probably have to convert them to LaunchpadEditView
[02:53] <flacoste> SteveA: anytime you want
[02:53] <salgado> SteveA, flacoste, I'd like to join this conversation, please
[02:54] <jamesh> flacoste: that'd be good.  Makes it easier to roll out improvements that affect all forms.
[02:54] <flacoste> SteveA: yeah, salgado is the assignee for that spec
[02:54] <SteveA> ok.  we in london are going for lunch now.
[02:54] <SteveA> but also, please look up the existing launchpad i18n spec
[02:54] <flacoste> SteveA: what's the name?
[02:54] <SteveA> we shouldn't reinvent things that have already been analyzed here
[02:54] <SteveA> can't remember
[02:54] <SteveA> but also also, please mail the launchapd list when there's infrastructure-like work going on
[02:54] <SteveA> so that we can get communication going about these things
[02:55] <SteveA> I'd hate for us to end up solving i18n in two or more different ways
[02:55] <flacoste> SteveA: copy that
[02:55] <salgado> https://launchpad.canonical.com/LaunchpadI18n
[02:55] <flacoste> SteveA: (that's 24H slang in case you didn't know which kind of means got it)
[02:56] <SteveA> I thought it meant "go to kinkos"
[02:56] <SteveA> but, cool anyway :-)
[03:48] <salgado> spiv, around?
[03:48] <kiko> salgado, thanks
[03:48] <salgado> hey kiko, you didn't forget that shipit review, did you?
[03:49] <spiv> salgado: yep
[03:49] <salgado> spiv, I have two small branches on your queue (I guess you've noticed them already :-); any idea when you'll have time to review them?
[03:51] <spiv> salgado: Let's see... I'm about half-way through the mirror-management diff, so tomorrow definitely, maybe even tonight.
[03:53] <spiv> salgado: support-tracker-karma doesn't look too involved, so probably tomorrow for it too.
[03:53] <salgado> spiv, cool, thanks!
[03:53] <spiv> salgado: when are you going to review my one-liner that's been in your queue for *12* days? :)
[03:54] <salgado> oh, crap. I forgot it. sorry
[03:54] <salgado> I need help to review that. (I guess it's the posix shell branch, right?)
[03:55] <sabdfl> kiko: what do you think about having a way for users to "tell us what they want to do" when they are stuck, and for us to use that question:
[03:55] <spiv> salgado: right.
[03:55] <sabdfl>  a) to search an FAQ database and try to give them a good anser, and
[03:55] <spiv> salgado: I'm no shell expert either, which is why I didn't just [trivial]  it :)
[03:55] <sabdfl>  b) to keep track of the places people get stuck in LP so we can improve the pages for those scenarios?
[03:56] <sabdfl> i'm thinking we could store those questions together with the page-template name that rendered the page, so we could review those every month or so and see where people are getting stuck on a particular page
[03:56] <spiv> salgado: feel free to punt it back the rejected queue if you can't do it (or don't want to find an shell arcana expert to consult).
[03:56] <kiko> sabdfl, well, tickets, bugs and unused features are usually an indication of what parts of launchpad are unclear, and we have plenty of input from there
[03:56] <salgado> spiv, I'll try to find an expert first
[03:57] <kiko> sabdfl, for instance, my current CoC work is being done after triaging tickets and bugs on the subject and realizing how arcane the procedure was
[03:57] <kiko> sabdfl, I could list of the top of my head another 5-10 areas that need similar work done
[03:57] <sabdfl> understood, and that's good work
[03:57] <sabdfl> but once we have the system basically tuned, i think it would still be a cunning plan
[03:57] <sabdfl> users would be searching for HOWTO's or tips or FAQ's
[03:57] <kiko> sabdfl, what sort of UI element would we use to convey where we are stuck? something like google code's Help link?
[03:58] <sabdfl> but we would store the search together with the page name that it was performed off
[03:58] <sabdfl> not sure - possibly just a "search for help" option
[03:58] <kiko> yes, you can definitely explore the fact that you know where the user was when he reached for help
[03:58] <sabdfl> see - most users will not file bugs or tickets
[03:58] <kiko> yes
[03:58] <sabdfl> but they might search for help
[03:58] <sabdfl> ok, we can look at that post-2.0 :-)
[03:58] <kiko> so tickets and bugs really only highlight the most distressing problems
[03:58] <sabdfl> yes
[03:59] <sabdfl> we should get those under control first
[03:59] <kiko> but the fact that we have them suggests we should concentrate on those areas first ;)
[03:59] <sabdfl> with OOPS'en
[03:59] <kiko> right, exactly
[03:59] <kiko> well, not just oopses
[03:59] <kiko> for instance, lots of people failing to register gpg keys
[03:59] <kiko> and failing to sign the CoC
[03:59] <kiko> filing bugs
[03:59] <kiko> I bet 1 bug filed is at least 20 users who couldn't do it
[04:02] <rancell> Hi all, I've found a bug in dd (coreutils) but when I go to report it in Launchpad I get "coreutils does not use Malone as its bug tracker. To report a bug about coreutils, please use its official bug tracker.". Where should I report?
[04:04] <bradb> rancell: /distros/ubuntu/+filebug
[04:04] <rancell> bradb, thanks
[04:04] <bradb> no prob
[04:05] <kiko> sabdfl, ^^^ indication of confusing UI. :)
[04:05] <kiko> how fitting
[04:05] <mpt> And I reported that bug :-)
[04:06] <kiko> mpt, why don't you fix it, too? One simple solution might be to add "To report a but about coreutils as packaged in a distribution, use ..."?
[04:06] <bradb> or:
[04:07] <bradb> Perhaps you meant to report the bug in one of these packages?
[04:07] <kiko> bradb, requires packaging link
[04:07] <bradb> _coreutils in Ubuntu)
[04:07] <mpt> I will, when I get time
[04:08] <bradb> kiko: not always. for coreutils, for example, we could have made a good guess;.
[04:08] <kiko> bradb, that sort of guess is best done to prefill the packaging links.
[04:09] <mpt> bug 42480
[04:09] <Ubugtu> Malone bug 42480 in malone "Report a bug about product that doesn't use Malone should include link to product's official bug tracker" [Wishlist,Confirmed]  http://launchpad.net/bugs/42480
[04:10] <bradb> mpt: that wouldn't have solved rancell's problem
[04:10] <mpt> Why not?
[04:10] <kiko> the issue I have with packaging is that it links specific series IIRC
[04:11] <bradb> mpt: ISTM he went down to the product road when he meant to report the bug in Ubuntu (otherwise, presumably, he would have wondered why I gave him an ubuntu filebug link in response)
[04:12] <kiko> agreed with bradb 
[04:12] <mpt> Well, that's another bug I also reported ...
[04:13] <rancell> bradb: Yup I wanted to file the bug against Ubuntu but knew the package so went there first to check if it had already been reported
[04:14] <salgado> spiv, I don't see what's the problem that you're trying to solve with that one-liner;  I get the same result running both lines in dapper's dash
[04:18] <flacoste> kiko: has mpool and mpt comments have made you change your mind about adding search functionality to +linkbug?
[04:18] <kiko> no.
[04:19] <kiko> in fact they have made it even more opposed to that specific UI.
[04:19] <flacoste> why?
[04:20] <kiko> because I don't think that it is geared towards the right use case
[04:20] <SteveA> hi
[04:20] <flacoste> kiko: which is according to you linking to only one bug?
[04:21] <kiko> flacoste, well, that's part of it. plus the fact that you will almost never link to multiple bugs listed using /the same search string/
[04:21] <flacoste> kiko: not if you use the product/package-name name to get most bugs 
[04:22] <flacoste> bradb, kiko: have you actually used the feature?
[04:22] <kiko> flacoste, you're contriving. there's no way you can argue that that's a major use case!
[04:22] <flacoste> to link to specs for example?
[04:22] <bradb> flacoste: no. like most people that use Launchpad, i'm too lazy
[04:22] <kiko> flacoste, dude, finding a bug is searching for needles in haystacks
[04:23] <bradb> i've linked bugs to specs
[04:23] <jamesh> or cucumbers in haystacks
[04:23] <bradb> but a multi-select UI would have taken me offguard
[04:23] <flacoste> kiko: the use case is 'I know there is a bug about this, i just don't know it's id, it was about 'such and such')
[04:23] <kiko> flacoste, see what bradb said. a multi-select UI is NOT what the end-user would be expecting.
[04:24] <kiko> now there may be a communication issue here
[04:24] <kiko> I think that search for the bug as part of the UI
[04:24] <flacoste> that it's because the name of the action is 'Link to bug'
[04:24] <kiko> is laudable
[04:24] <kiko> I think the multi-select approach is inappropriate
[04:24] <kiko> and furthermore
[04:24] <kiko> I think that to do search-to-link properly
[04:24] <kiko> you need to do workflow
[04:25] <kiko> allowing the end-user to confirm what he's done, make sure he's found all the bug he wants, etc
[04:25] <flacoste> what kind of workflow?
[04:25] <kiko> which is overkill.
[04:25] <kiko> OVERKILL :-)
[04:25] <kiko> so
[04:25] <kiko> some suggests that are lightweight
[04:26] <kiko> and that would help mitigate the problems you point out:
[04:26] <kiko> - offer a link to search for bugs
[04:26] <kiko> - after linking to a bug, you can put up a message with the summary and description of bug you linked, so the person can go back and correct if it was wrong
[04:26] <kiko> - you /could/ prompt the user to confirm if he has actually linked to the correct bug. but I think that would make the feature even harder to use.
[04:27] <flacoste> the linked bug already appears in the related bug portlet
[04:27] <kiko> portlets are really not the sort of notification UI I was mentioning above :)
[04:27] <kiko> in fact portlets could be called anti-notification UI. :)
[04:27] <flacoste> could appear in the notification area also
[04:30] <SteveA> stub, flacoste, salgado: let's discuss the i18n issues on #launchpad-meeting
[04:30] <kiko> flacoste, that I think is definitely worth it.
[05:02] <carlos> lifeless: hi, around?
[05:03] <kiko> carlos, did you manage to land a fix to unbreak the test suite?
[05:03] <carlos> kiko: not yet
[05:03] <carlos> I have the fix in my branch
[05:03] <kiko> ok, I'll do it
[05:03] <carlos> but I'm getting another error that cprov is looking at
[05:03] <carlos> kiko: ok
[05:03] <kiko> no need, I have a fix here with another bunch of crap
[05:05] <sivang> bradb: I'm interested in helping with the UI fixes you mentioned at the meeting, however I suspect I will require some minor getting started mentoring on some of them.
[05:05] <kiko> carlos, but don't be blocked by me anyway
[05:06] <carlos> kiko: don't worry, if you merge your branch before me, I will fix the conflict
[05:06] <carlos> otherwise.... you lose ;-)
[05:06] <kiko> I always lose
[05:22] <jamesh> kiko: so you've submitted a fix for the 98-cocacknowledge bug?
[05:23] <kiko> jamesh, I have it in my tree, but not yet. wanna do it?
[05:24] <bradb> sivang: you might want to find a small bug or two that interest you, to get more familiar with the terrain.
[05:24] <jamesh> kiko: sure.  I was just going to remove the date portion from the pagetests
[05:25] <carlos> hmm, I have changes in my tree that I didn't change
[05:25] <kiko> jamesh, do it
[05:25] <bradb> sivang: then, ideally, send me a patch for it, and I'll give you specific suggestions on getting into the Malone vibe
[05:26] <SteveA> bug 54987
[05:33] <SteveA> Keybuk: nice email
[05:34] <Keybuk> :)
[05:34] <SteveA> Keybuk: this is feasible now that we have a single namespace for products, projects and distros
[05:34] <Keybuk> the biggest thing needs to be the loss of the "GPG signed e-mail and launchpad account" requirement though
[05:34] <Keybuk> people who submit bugs aren't developers, they're users
[05:34] <Keybuk> and users don't have that kind of fancy setup
[05:34] <bradb> +1
[05:35] <SteveA> silly idea:
[05:35] <SteveA> allow users to set "my secret bug filing word" in launchpad
[05:35] <SteveA> and then they just need to say "antigiraffe" in an email
[05:35] <SteveA> for it to be allowed through
[05:35] <bradb> don't make me think!
[05:35] <Keybuk> meh, that's still complicated ... they need to go to launchpad before they can submit bugs
[05:36] <SteveA> it may be complicated
[05:36] <SteveA> but then we can have fun looking up people's chosen words later
[05:36] <Keybuk> and ringing their telephone banking and trying it as their password? :)
[05:36] <SteveA> is it possible to eat *too many* grapes?
[05:36] <Keybuk> FOLKS!  WE HAVE A REVENUE STREAM!
[05:36] <kiko> Keybuk, so you want to make it easier for people to file bugs? do you realize we have more than enough bugs already? :)
[05:36] <Keybuk> kiko: as an upstream, yes
[05:37] <SteveA> dude, we're creating bugs as fast as we can
[05:37] <SteveA> we can hardly keep up with the filing rate
[05:37] <Keybuk> I have almost no bugs because people aren't using Malone, because it's too hard to submit a report
[05:37] <sivang> bradb: where can I find a list of stuff that are important for a milestone?
[05:37] <Keybuk> whereas in the last two weeks, I've had about a dozen in my INBOX directly
[05:39] <kiko> Keybuk, it's little harm for you to forward those mails to new@bugs.launchpad.net, though..
[05:39] <bradb> sivang: for malone: https://launchpad.net/products/malone/ . the Milestones portlet.
[05:39] <kiko> Keybuk, I'll offer to contact those people for you and ask them to register their bugs on launchpad though. :)
[05:39] <Keybuk> kiko: there's no point though
[05:40] <Keybuk> if I forward the mail, then it loses the fact the bug is attached to the original submitter
[05:40] <Keybuk> comments/status changes/etc. don't go to the submitter, they flood me
[05:40] <Keybuk> so I'd then have to use Malone AND e-mail the user
[05:40] <kiko> Keybuk, that person won't get email anyway unless they are launchpad-registered.
[05:40] <Keybuk> at that point, Malone is doing nothing for me
[05:40] <Keybuk> kiko: that's what I want to change
[05:40] <Keybuk> I want users to be registered automatically when they submit bug reports
[05:40] <kiko> Keybuk, we can't spam people who haven't registered explicitly. 
[05:40] <kiko> now 
[05:40] <kiko> I agree with lazy account creation
[05:40] <kiko> as they file bugs
[05:41] <kiko> but they still need to "do work"
[05:41] <kiko> and I suspect that the reason you get email instead of bug reports
[05:41] <Keybuk> kiko: you were doing a push of getting upstreams to use Malone, and what their problems were, right?
[05:41] <kiko> is not because people won't create accounts
[05:41] <kiko> but because they find it easier just to mail you.
[05:41] <kiko> right.
[05:41] <Keybuk> as an upstream, I thought I'd co-operate and I asked everyone who'd mailed me why they hadn't used Malone
[05:41] <Keybuk> and all but one actually responded
[05:41] <kiko> cool
[05:41] <Keybuk> and that was the findings
[05:41] <Keybuk> - the web interface looked "scary"
[05:42] <Keybuk> - the web interface required them to register, which was complicated, they just wanted to submit a bug
[05:42] <kiko> Keybuk, can you please email me these findings?
[05:42] <Keybuk> - the e-mail interface instructions were huge
[05:42] <kiko> I can't be on IRC right now
[05:42] <Keybuk> kiko: it's in your INBOX right now
[05:42] <bradb> fyi, bug 50653
[05:42] <Keybuk> that's where this conversation started, because I sent an e-mail
[05:42] <Ubugtu> Malone bug 50653 in malone "Malone should support craigslist-style anonymous bug reporting" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50653
[05:42] <kiko> wow
[05:42] <kiko> ok
[05:42] <Keybuk> - email required GPG signatures ... most didn't even know what GPG was
[05:43] <Keybuk> - email required first having visited the web page
[05:43] <Keybuk> etc.
[05:43] <Keybuk> ie. it was just too complicated to file a bug with Malone
[05:43] <Keybuk> and FAR easier just to mail me
[05:43] <Keybuk> so as an upstream, there seems to be little point to Malone, because none of my users are using it
[05:43] <Keybuk> the _only_ user to have ever submitted a bug there was an Ubuntu develoepr!
[05:43] <Nafallo> Keybuk: hi there :-). nice to see you again.
[05:43] <Keybuk> Nafallo: "again"?:)
[05:44] <Nafallo> Keybuk: yea, was like ages since I saw you last time, so again ;-)
[05:44] <Keybuk> heh, I'm online every day <g>
[05:45] <Nafallo> oh. I thought you where on vacation or something since I haven't seen your nick say something :-).
[05:46] <bundy_all> hello to all
[05:48] <Keybuk> Nafallo: nah, just busy developing stuff
[05:48] <Keybuk> IRC is a hell of a distraction from real work
[05:48] <Nafallo> oh. nice. something testable then? :-)
[05:48] <Keybuk> so I've been vaguely avoiding using it too for a few weeks so I can actually have stuff finished before FeatureFreeze :)
[05:49] <bundy_all> Can anybody tell me is that offer with free ubuntu cd is still valid ?
[05:50] <LarstiQ> Keybuk: well, keeping bugreports away is something some upstreams desire ;)
[05:52] <bradb> bundy_all: Visit https://shipit.ubuntu.com/ for your freedom buffet. Ask #ubuntu if you want to know more.
[05:53] <bundy_all> bradb Thank you
[05:53] <bradb> no prob
[05:59] <carlos> jamesh: you are too fast...
[06:00] <carlos> I just sent my merge request that fixes the timebomb too...
[06:00] <carlos> so I guess I will get a conflict :-(
[06:00] <sabdfl> salgado: did you see my review request, do you have bandwidth to handle that?
[06:01] <salgado> sabdfl, just replied to it. I'll start it today for sure, but may not be able to finish today, then I'll finish tomorrow
[06:01] <salgado> is that okay?
[06:04] <salgado> kiko, I want to stick https://sodium.ubuntu.com/~andrew/paste/filecHCp8r.html in that branch you just reviewed.  is that okay?
[06:05] <salgado> jamesh, thanks for the correction on the FAQ
[06:05] <kiko> salgado, I think that will be ineffective, to be honest. but sure. <strong tal:content> though.
[06:05] <sabdfl> salgado: that's fine - thanks! if all is ok i will update to review comments, and land over the weekend, for rollout next week
[06:05] <sabdfl> stub: would that be alright?
 does nothing inside a "notification message"
[06:06] <salgado> kiko, ^
[06:06] <stub> eh?
[06:06] <salgado> and <strong> too
[06:06] <kiko> salgado, why are you adding strong then?
[06:06] <kiko> sabdfl, I'd prefer it went through staging-baking
[06:06] <salgado> kiko, the first strong is not in a notification message
[06:06] <kiko> we're not doing trigger-rollouts for a while now
[06:06] <stub> sabdfl: Yes, we can roll out your landing next week if you land it soon
[06:06] <sabdfl> kiko: i will hammer it on staging - that way it will get more testing than staging usually would
[06:07] <sabdfl> if it's flaky i'll let you know
[06:07] <kiko> salgado, so that's what I was talking about.
[06:07] <kiko> <strong tal:content>
[06:07] <kiko> instead of using a span.
[06:07] <kiko> sabdfl, well, it also lets us look at it and see if we can make improvements to it over the week
[06:07] <sabdfl> it does introduce a lot of new checks and constraints, so there may well be issues
[06:07] <kiko> instead of surprise landing. it's the policy we're taking 
[06:07] <kiko> so let's leave it to bake on staging for a week
[06:07] <kiko> there's no sprint coming up
[06:07] <kiko> we have the time
[06:07] <stub> Which is of course preferred ;)
[06:07] <sabdfl> kiko: i'm at a UI sprint next week
[06:08] <SteveA> carlos: if you mv your directory on devpad out of the usual place, pqm will fail quickly on the merge
[06:08] <kiko> sabdfl, that's fine. we can fix problems too. :)
[06:08] <sabdfl> kiko: i'll let you know if i think it needs extra work, thanks
[06:08] <SteveA> carlos: although, I supopse if there is a conflict, it will make it fail early anyway
[06:08] <kiko> sabdfl, sure. I just want to make sure that good rollout practices are followed. I'm sure you can appreciate that :)
[06:09] <salgado> kiko, the one where I use <strong> I have other things inside it, that's why I use the <span replace="context" />.  in the other case, it won't help using a <strong> because it's already inside a <p class="notification message">
[06:09] <sabdfl> very much so! if salgado gets me that review, and there are no showstoppers, i will be able to do plenty of testing sunday
[06:09] <sabdfl> if its flaky i'll recommend rolling out something pre-landing
[06:10] <kiko> I'd prefer that it waited for a week on staging, unless there's something that is a showstopper to roll out
[06:10] <sabdfl> you've already said that ;-)
[06:10] <kiko> everybody wants their stuff in immediately -- but we should avoid doing it unless we need to
[06:10] <kiko> yeah, I have
[06:12] <stub> If there is no sprint or anything needing the landing next week, it indeed should not be pushed out.
[06:12] <salgado> kiko, saw my message explaining why I'm using <strong> in one case and not in the other?
[06:13] <stub> 'Oooh shiney' is not a good reason to risk the production systems, especially as people are now starting to get antsy about downtime.
[06:15] <kiko> salgado, hmmm. it seems you're missing a </strong> then.
[06:16] <niemeyer> kiko: pre-joins!
[06:16] <salgado> kiko, no, it's there
[06:17] <kiko> salgado, I need glasses. r=kiko
[06:17] <kiko> niemeyer, oh-oh. somebody told you that dirty secret? I did it because I could!
[06:17] <salgado> stub, have you defined the revision that is going to production next week?
[06:17] <stub> salgado: Nope
[06:18] <niemeyer> kiko: I'm gonna give you generic joins dude
[06:18] <kiko> salgado, yes. it was YESTERDAY. :)
[06:18] <ddaa> Hey, anybody can think of objects that would need reassigning when changing the owner of a Branch?
[06:18] <niemeyer> kiko: *Just* for you
[06:18] <niemeyer> kiko: Stuart says you own me a bj
[06:18] <kiko> salgado, stub: take it off channel! before I have a heart attack!
[06:18] <salgado> eh?
[06:19] <kiko> stub, stop promising blow jobs from me ok
[06:19] <stub> But you said!
[06:19] <sabdfl> oh my eyes
[06:19] <kiko> why me
[06:20] <LarstiQ> it must be that pie picture
[06:20] <stub> :)
[06:20] <sabdfl> taking the bullet
[06:24] <sivang> bradb: How do I reach the bugs targetted for 1.0 from https://launchpad.net/products/malone/+milestone/1.0 ?
[06:25] <bradb> sivang: they're all shown on that page
[06:25] <kiko> what an odd question
[06:25] <sivang> bradb: on https://launchpad.net/products/malone/+milestone/1.0 I see only specs
[06:25] <bradb> sivang: yeah, that indicates there are no bugs for that milestone. admittedly, that's a confusing UI.
[06:48] <sivang> bradb: so where do I find those bugs? ;)
[06:48] <bradb> sivang: on 1.1
[06:49] <sivang> bradb: ah,
[07:00] <elmo> bradb: is there any spec you know of for adding a 'Report a bug in this application' to the launchpad-integration stuff?
[07:03] <bradb> elmo: https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/LaunchpadIntegration is one mention of that stuff (and specifically not mentioning the word "bug")
[07:04] <elmo> hmm
[07:04] <elmo> what do you think of the idea?  obviously it's only useful for cases where the app isn't crashing, but it would allow new users to get straight to a page where they can start typing about their bug
[07:05] <jamesh> to pass non-trivial info to the bug page, we'd need some way of feeding data to LP unauthenticated and getting back a token to use in a URL
[07:06] <jamesh> given that launchpad-integration just calls the web browser with a URL as argument
[07:06] <elmo> ah, hmm, true
[07:07] <bradb> we discussed that in paris
[07:07] <bradb> i'm trying to remember the spec name
[07:07] <jamesh> I think we discussed it the first time round too (in Sydney)
[07:09] <bradb> elmo, jamesh: https://wiki.ubuntu.com/BugReportingTool was the more up-to-date thing about reporting bugs from the desktop
[07:10] <elmo> holy cow
[07:10] <elmo> that BERT thing seems, erm, interesting
[07:12] <bradb> the idea was to drive the user to the web UI, rather than rebuild a Malone UI for the desktop
[07:15] <jamesh> elmo: it does sound a little more complicated than necessary
[07:23] <sivang> seems the spec is just about adding some more automatically generated bug data for submission into the web ui yes?
[07:27] <jamesh> sivang: sure.  The debian reportbug script provides a bunch of information about the package version plus dependencies in the initial report
[07:28] <sivang> jamesh: I see.
[07:28] <jamesh> sivang: since the "API" for reporting a bug is opening the web browser at a particular URL, and this data is a bit larger than you'd fit in a URL query string, you need something more complicated
[07:28] <jamesh> (although maybe not quite as complicated as the description in that spec)
[07:29] <sivang> right, even a bit more environmental data will be immediately helpful.
[07:37] <sivang> be back later dudes
[07:43] <sladen> ...when you have no X, you have to use 'lynx' for launchpad.  Lynx and launchpad do not mix;  in fact, it's not even possible to do an advanced search with javascript!
[07:44] <sladen> s/with/without/
[07:51] <ddaa> sladen: aren't there text mode browsers that suck less than lynx? w3m for example?
[07:52] <jamesh> sladen: looks like it is going to the wrong URL
[07:53] <jamesh> sladen: the "advanced search" link is to "?advanced=1"
[07:54] <sladen> jamesh: indeed...  I guess that it's striping the URL back to the '/', rather than +bugs?advanced... 
[07:54] <jamesh> sladen: lynx interprets that as e.g. https://launchpad.net/products/launchpad/?advanced=1, while Firefox interprets it as https://launchpad.net/products/launchpad/+bugs?advanced=1
[07:54] <jamesh> yeah
[07:54] <jamesh> sladen: could you report a bug about it? :)
[07:55] <jamesh> assuming you can get to the bug submission form
[07:55] <sladen> jamesh: sure will, but there is no way I'm going to even attempt to /file/ it from Lynx...
[07:55] <sladen> :)
[08:26] <SteveA> kiko: for the tags, why rosetta:imports and not rosetta-imports ?
[08:26] <kiko> SteveA, I don't know. perhaps because it was soyuz:foo already. your choice, I'm easy.
[08:27] <jamesh> kiko: I don't think a colon is allowed in a tag
[08:27] <jamesh> we don't allow them in user names, iirc
[08:27] <jamesh> and it is the same validator
[08:27] <kiko> jamesh, is a tag a valid name? ok. luckily I didn't try using it!
[08:28] <kiko> actually it wasn't soyuz:foo. who am I trying to fool!
[08:28] <SteveA> so, hyphen it is
[08:28] <SteveA> I updated the page with the tags that were agreed earlier today
[08:29] <jamesh> kiko: yeah.  If it becomes a problem, we can loosen the restrictions
[08:29] <SteveA> salgado: ping
[08:29] <jamesh> which is easier to do that tightening them later on
[08:29] <kiko> jamesh, I am not even arguing for that. I am defeated. hypens it is.
[08:30] <SteveA> salgado: stu and I have in pqm converting shipit to use the new vhosts support
[08:30] <SteveA> we'll be trying it out on staging soon
[08:31] <salgado> SteveA, cool!  are you guys going to update staging today or wait till tomorrow?
[08:31] <SteveA> depends when pqm does the work
[08:32] <SteveA> shipit on staging is broken right now, in preparation for this landing
[08:33] <ddaa> They appear to mean the same thing, yet they have different name and different visual effects...
[08:33] <ddaa> and TextWidget.width has no visible effect
[08:34] <ddaa> Setting them to the same value, as in TitleWidget and SummaryWidget, leads to different field widths in the browser...
[08:35] <ddaa> There's something rotten in the kingdom of Widgark
[08:40] <jamesh> ddaa: maybe TextWidget doesn't have a width attribute
[08:42] <flacoste> kiko: what do you think about adding 'Cancel' buttons on forms? (and mpt if he's sleep-walking)
[08:42] <flacoste> as mpool suggested?
[08:42] <kiko> flacoste, if you have started an operation and want to go back, it makes some sense.. but mpt is the authority there
[08:43] <flacoste> because often there is no single click that can bring you back where you were before
[08:43] <flacoste> you have to use the back button
[08:43] <SteveA> I agree with flacoste 
[08:43] <flacoste> it is very easy to do with formlib
[08:43] <kiko> the back button is a valid button though. and it is single-click. :)
[08:44] <SteveA> my online bank FINES you $1 every time you press the back button
[08:44] <SteveA> or so it feels
[08:44] <SteveA> they certainly punish you
[08:44] <flacoste> indeed, but if you already submitted the post with errors... it will be two clicks and you'll have to acknowledge the this was a 'POST' request dialog
[08:45] <flacoste> we could even add a standard 'Cancel' button to LaunchpadFormView 
[08:46] <SteveA> flacoste: try it in the support tracker to start with
[08:46] <SteveA> and we'll see how it goes in practice
[08:46] <SteveA> and get some feedback from mpt
[08:46] <SteveA> just because I agree doesn't mean it is a good idea
[08:46] <jamesh> I wonder how that would affect the button order if it was implemented in the base class
[08:46] <flacoste> SteveA: fine
[08:47] <flacoste> jamesh: actually, it wouldn't work
[08:47] <kiko> hey jamesh 
[08:47] <kiko> I have an ascii armoured dump of a key
[08:47] <kiko> a pubkey
[08:47] <kiko> how do I get its full fingerprint?
[08:47] <jamesh> flacoste: yeah.  Looks like they don't use a class advisor for @action, so don't have access to the parents when setting up actions
[08:47] <flacoste> jamesh: exactly
[08:48] <jamesh> kiko: import it into a keyring, look at what ID it prints when you do this
[08:48] <jamesh> kiko: then do "gpg --fingerprint ID"
[08:48] <jamesh> flacoste: might be considered a bug in formlib ...
[08:48] <flacoste> jamesh: could be done by massaging the actions attribute after class definition though
[08:48] <kiko> jamesh, so I need to import it first? no chance to not do so?
[08:49] <jamesh> kiko: you can use "gpg --keyring foo --import filename" to import into a different keyring
[08:49] <flacoste> jamesh: like in setupWidget or somewhere like that
[08:49] <kiko> k
[08:49] <jamesh> then "gpg --keyring foo --fingerprint ID"
[08:50] <jamesh> flacoste: yeah.  Something like we do in the Navigation classes (walk __mro__ looking for a special attribute name in the class dicts)
[08:51] <flacoste> jamesh: i was thinking something simpler: just add the 'Cancel' action to the actions attribute in setupWidgets :-)
[08:51] <flacoste> unless it's there of course
[08:51] <jamesh> flacoste: ah :)
[08:51] <ddaa> jamesh: what do you mean?
[08:52] <jamesh> ddaa: the TextWidget class doesn't seem to mention a "width" attribute -- just "displayWidth" and "displayMaxWidth"
[08:52] <ddaa> I tried renaming displayWidth to width in TitleWidget, and I then get the default TextWidget width
[08:52] <jamesh> ddaa: so it isn't too surprising if it doesn't do anything special when you set that attribute
[08:52] <ddaa> right
[08:53] <ddaa> but there is TextAreaWidget.width
[08:53] <ddaa> and for the same value, width and displayWidth yields different widths in the actual web page.
[08:54] <ddaa> And I would like my forms to look a bit more regular
[08:55] <ddaa> besides, displayWidth=44 gives something that's a bit too narrow for real life urls
[08:55] <ddaa> width=44 gives something wider, so the form is going to be that wide anyway, I'd like to put that room to use
[09:34] <flacoste> bradb: ping
[09:34] <bradb> flacoste: pong
[09:34] <flacoste> bradb: have you ever tried using canonical.widgets.bug.BugWidget?
[09:35] <flacoste> i get a validation error because the returned value (a bug) doesn't fully comply with the IBug interface
[09:35] <bradb> I wouldn't use that widget.
[09:36] <flacoste> bradb: why?
[09:36] <flacoste> bradb: it looks fine, the problem is more with the fact that Bug doesn't fully comply with IBug
[09:36] <flacoste> bradb: validation errors are:
[09:36] <bradb> because the code is easier to understand you get the bug id from the context or request, depending on what you're doing
[09:36] <flacoste> displayname isn't a unicode string
[09:37] <flacoste> bradb: yeah, at the expense of a lot of duplication
[09:37] <flacoste> give me the bug, I don't care how you got it
[09:41] <bradb> flacoste: what are you doing? form/view/code, etc.
[09:41] <flacoste> i'm working on +linkbug
[09:41] <flacoste> i use BugWidget to get the bug to link to
[09:41] <flacoste> the widget works fine
[09:42] <bradb> what's the schema of the form?
[09:42] <flacoste> Object(schema=IBug)
[09:42] <flacoste> and it fails to validate
[09:42] <flacoste> the displayname isn't a unicode string
[09:43] <flacoste> and for some reasons it feels like the tags field isn't a list
[09:43] <flacoste> a workaround would be to use schema=ISQLBase or even Interface
[09:43] <flacoste> but i find it weird that schema validation fails on IBug
[09:43] <bradb> i don't understand that Object(schema=...) code
[09:43] <flacoste> it means that we don't really test that
[09:44] <BjornT> flacoste: you can even use BugField
[09:44] <bradb> i was expected you'd have a schema like ILinkBugToTicket, with a BugField
[09:44] <BjornT> it's strange that the object widget doesn't simply check that the schema is provided, though.
[09:44] <flacoste> bradb: it does that... and more
[09:45] <flacoste> bradb: it actually validates each and every field in the interface
[09:45] <flacoste> bradb: you didn't expect that?
[09:45] <bradb> I expected:
[09:45] <bradb> class ILinkBugToTicket(Interface):
[09:45] <bradb>     bug = BugField(...)
[09:46] <flacoste> i have errands to make, I'll be back a little bit later
[09:46] <flacoste> bradb: but we can continue that discussion tomorrow at the office
[09:46] <bradb> flacoste: sounds good
[09:46] <kiko> you bake those errands well
[09:46] <kiko> for a guy
[09:47] <bradb> BjornT: how do i select the "no value" option of a RadioWidget, by default? it seems like a bug in Zope 3 that it won't select it by default
[09:47] <flacoste> kiko: it's actually a guy kind of errand: getting a new CD/MP3 player in the car: very important for the long ride of Saturday :-)
[09:48] <ddaa> interesting
[09:48] <ddaa> it looks like working with testbrowser may turn out to be significantly less horrible than old doctests
[09:48] <ddaa> yeah, I'm late, but I get to fix some of the branch-related doctests today
[09:49] <kiko> dude
[09:49] <kiko> testbrowser is da bomb
[09:49] <kiko> it's like natalie portman
[09:49] <ddaa> Well, so far it looks decent
[09:49] <bradb> testbrowser is one of those golden bits of zope 3 with just the right amount of engineering
[09:49] <bradb> unlike, say, the widget framework, which makes me hate everything
[09:50] <ddaa> as opposed to old doctests which were outrageously ugly and painful like mixing tabasco and eye drops.
[09:50] <ddaa> bradb: how interesting, I just rambled about widgets being... interesting...
[09:50] <BjornT> bradb: yeah, it's bug... it's fixed in BugTaskBugTrackerWidget, but it might not be that easy to pull out the fix (RadioWidget is not easy to customize....)
[09:51] <BjornT> bradb: it's also fixed in upstream zope3, but in a backwards incompatible way, so it's not just to simply pull in the fix :(
[09:51] <ddaa> bradb, do you have any clue how to make a given TextWidget get the same actual width as a given TextAreaWidget?
[09:51] <bradb> BjornT: ok, so i need something i can land today. do you have any code i can have to make it work, or should i just convert this from a widget into html?
[09:52] <bradb> ddaa: not even a remotely vague idea, and don't EVER ask me about z3 widgets again! :P
[09:52] <bradb> er, i mean, ignore the bit after the comma
[09:53] <ddaa> BjornT: maybe you'd have an idea?
[09:54] <BjornT> bradb: what you can do is to subclass RadioWidget and override renderItems() with part of BugTaskBugTrackerWidget.renderItems()
[09:55] <bradb> BjornT: ah, right, ok. i guess you mean BugTaskBugWatchWidget
[09:57] <BjornT> bradb: right. the part you need is the code between the '#check if we want to select first item...' and '# Add an option for creating a new bug watch.'
[09:57] <bradb> hm, though that would add more code than just writing the html...
[09:59] <BjornT> bradb: well, you shouldn't think like that, since html will be harder to maintain. although in this case, i wouldn't object if you wrote html instead, since i can't guarantee that it'll actually work...
[10:14] <bradb> BjornT: unfortunately, when i use that code, it hits the "elif value != self.context.missing_value" condition, and evals to True, skipping the else: that would set no_value = "checked"
[10:17] <bradb> oh, i may have found it.../me tries
[10:18] <bradb> YA!
[10:19] <BjornT> bradb: what did you do to fix it?
[10:19] <kiko> sacrifice a kitten
[10:19] <bradb> BjornT: there were two more lines at the top of your method that i needed, that set value to self._missing
[10:21] <BjornT> bradb: right, i was going to suggest that. RadioWidget is kind of buggy..., it's not impossible to you need to put in an 'else: value = self._toFieldValue(value)' after that.
[10:22] <bradb> BjornT: should i (attempt) to extract the renderItem() commonality into a LaunchpadRadioWidget class?
[10:23] <BjornT> bradb: well, are you going to customize the widget further? if not, let's keep that as LaunchpadRadioWidget, and then I can make BugTaskBugWatchWidget inherit from it later.
[10:25] <bradb> BjornT: no, i don't want to customize it further. i'll just call it LRW then and move on.
[10:25] <bradb> thanks for the help
[10:25] <BjornT> cool
[10:26] <kiko> bed! this early! bah
[10:34] <laszlok> can someone help me with importing a POT file?
[10:40] <kiko> laszlok, what's up?
[10:52] <bradb> kiko: do you have time to review this upstream status patch? 8 files changed, 98 insertions(+), 95 deletions(-)
[10:52] <kiko> bradb, tonight, yes. pastebin
[10:52] <kiko> (for reply tomorrow IOW)
[10:53] <bradb> kiko: https://sodium.ubuntu.com/~andrew/paste/fileZqkEKX.html , thanks
[10:54] <kiko> salgado, can you do some over-the-shoulder today? I need to land this fix to GPG handling..
[10:54] <salgado> kiko, I'm revieweing sabdfl's branch now, and I need to go in a few minutes. (have classes today)
[10:56] <kiko> salgado, argh. not even 10 minutes to fix /your/ regression?
[10:56] <kiko> what time's your classes
[10:57] <salgado> kiko, seriously, I'm in a rush.  I need to go home first to do some laundry, otherwise I won't have time.  I have classes from 19 to 23h
[10:57] <kiko> buuummmmer
[10:58] <laszlok> kiko: i thought jordi set me up so my uploads would automatically, but my latest file still says needs review after almost a week
[10:59] <kiko> laszlok, it may not be approved yet. can you find it in /imports? can you get me a URL?
[10:59] <laszlok> kiko: https://launchpad.net/rosetta/imports/+index?target=products&status=all&type=all&start=225&batch=75
[10:59] <laszlok> the jokosher.pot one
[11:03] <salgado> kiko, mail me the diff and I'll review it first thing in the morning tomorrow
[11:08] <kiko> bradb, do you have some time to look at a patch today? I'll swap and review yours meanwhile
[11:08] <bradb> kiko: sure
[11:08] <kiko> bradb, I mainly want a look over my tests to see if I could do something better
[11:08] <kiko> ah! cool
[11:09] <kiko> okay, one more second and I'll have a diff up for you.
[11:10] <bradb> ok
[11:11] <kiko> bradb, this patch:
[11:12] <kiko> - adds a README file explaining what keys are in the zeca keys directory
[11:12] <kiko> - factors the GPG handling of the person code into a separate view class
[11:12] <kiko> - corrects the GPG handling that salgado broke on tuesday
[11:12] <kiko> - tests it thoroughly
[11:12] <kiko> - converts a test to testbrowser
[11:12] <kiko> - fixes some cosmetic issues
[11:13] <kiko> here goes: https://sodium.ubuntu.com/~andrew/paste/filekbUPrE.html
[11:13] <kiko>  8 files changed, 353 insertions(+), 265 deletions(-)
[11:13] <jamesh> kiko: are you going to check this in as trivial? :)
[11:13] <bradb> kiko: doh!
[11:13] <kiko> oh wait
[11:13] <kiko> jamesh, no, I want review :)
[11:13] <kiko> wait up bradb I forgot the bzr adds
[11:13] <jamesh>  - checks to see if today is 2006-08-10
[11:14] <kiko> no it doesn't :-P
[11:14] <kiko> bradb, jamesh: https://sodium.ubuntu.com/~andrew/paste/fileXUVJeq.html
[11:14] <kiko> comments from both are welcome
[11:18] <jamesh> kiko: could you add a note to the README saying that the keys in lib/canonical/launchpad/ftests/gpgkeys should be symlinked to the appropriate names in lib/canonical/zeca/ftests/keys
[11:18] <jamesh> that there should be symlinks for each subkey ID
[11:18] <kiko> okay, sure.
[11:19] <jamesh> (i.e. for a normal key there will be a symlink for the main signing subkey and one for the encryption subkey)
[11:23] <jamesh> some of your comments appear to have been written in the future too
[11:24] <jamesh> why does this bit work? : assert "111" not in key, "The keyserver is not running, help!"
[11:25] <kiko> jamesh, which comments?
[11:25] <kiko> jamesh, (111) Connection refused.
[11:25] <kiko> jamesh, I was hoping you had fixed that crack-addled API but I guess you didn't get that far :)
[11:26] <jamesh> kiko: any reason for switching editpgpkeys.pt over to 2col layout?
[11:27] <kiko> oh. 
[11:27] <kiko> 09-10
[11:27] <kiko> doh
[11:27] <kbrooks> how do i make a bug related to another?
[11:27] <kiko> jamesh, yeah, it needs to be wide enough for the <input>, because the fingerprint is long.
[11:27] <kiko> kbrooks, you can't currently. you can however add "Bug 232131" in the bug description and it will linkify.
[11:28] <kiko> kbrooks, note that you /can/ dupe bugs though.
[11:29] <kiko> laszlok, what's the name of the potemplate, do you know?
[11:29] <laszlok> kiko: the file name is jokosher.pot
[11:29] <kiko> laszlok, yep. but the potemplate.. I'll check.
[11:30] <kiko> laszlok, well, I did something. let's hope it will work :-)
[11:31] <laszlok> kiko: do i have to bug you guys everytime i upload something
[11:31] <kiko> jordi, danilos[gone] , carlos: when you come back, know that I edited the jokosher import.. and set its template to "jokosher". kthxbye
[11:31] <kbrooks> lol
[11:31] <kiko> laszlok, I don't think so, but I'm not the right person to ask today. I will know tomorrow!
[11:31] <kbrooks> "kthxbye"....
[11:31] <kiko> kbrooks, note that carlos is not even online. oh well..
[11:31] <laszlok> kiko: thanks :)
[11:32] <kbrooks> kiko: noted. :-) :P 
[11:32] <jamesh> kiko: and if you're creating a getURLForKeyInServer(), we might want to update GPGKey.keyserverURL to use it
[11:32] <kiko> jamesh, where is that? let me see
[11:33] <bluefoxicy> hi kiko :)
[11:33] <kiko> oh-oh
[11:33] <kiko> I was discovered!
[11:33] <kiko> :)
[11:33] <jamesh> database/person.py
[11:33] <kiko> hey bluefoxicy 
[11:34] <kiko> sure
[11:34] <kiko> jamesh, is that tested?
[11:34] <bluefoxicy> kiko:  I put in a support request for that information and a blurb about making it accessible through some interface for the future.  Everyone is probably busy anyway :>
[11:35] <kiko> bluefoxicy, I saw it, and I haven't forgotten it, I swear
[11:35] <bluefoxicy> kiko:  still not in a hurry; I'm waiting for the crash reporter to get to a point where it'd make sense for pitti and friends to start working on a strategy for dealing with the data
[11:35] <bluefoxicy> which will be edgy+1 probably
[11:39] <kiko> cool.
[11:44] <jamesh> kiko: I think so.  It is used in one of the person RDF export
[11:45] <kiko> right
[11:46] <kiko> http://keyserver.ubuntu.com:11371/pks/lookup?search=0x12345678&op=index
[11:46] <kiko> jamesh, so it works. thanks for the hint, done.
[11:47] <kiko> jamesh, it's hardcoded :-(
[11:47] <kiko> launchpad/templates/rdf-macros.pt
[11:48] <jamesh> kiko: it isn't hard coded in person-foaf.pt
[11:48] <kiko> jamesh, what's rdf-macros for anyway? how weird.
[11:49] <kiko> owner_foaf_gpg is unused I think
[11:49] <jamesh> I think it is used in the product/project RDF dumps
[11:49] <kiko> oh
[11:50] <kiko> it's used inside itself
[11:50] <kiko> how weird.
[11:50] <kiko> ok, I'll fix that too.
[11:59] <kiko> bradb, how's it going?
[12:03] <sabdfl> kiko: what's hitting an xmlrpc server on LP, looking for a key?
[12:03] <bradb> kiko: still going. only about a third of the way through.
[12:04] <kiko> sabdfl, what key? that's most odd.
[12:04] <kiko> what method, too?
[12:05] <sabdfl> where is the full doc of xmlrpc API's?
[12:05] <sabdfl> i would like those to be documented rigorously, in a single place, with markings to indicate stable vs experimental api's
[12:05] <sabdfl> also, an api review mechanism