[11:00] <bradb> I'm confused about the difference. ISTM that it should still work ok from the outside, i.e., encoding method calls in xml and posting them to a URL.
[11:01] <bradb> Even if, underneath, we've made infrastructure changes.
[11:03] <SteveA> about what difference exactly?
[11:04] <SteveA> the issue is that Zope by default accepts xmlrpc POSTs and regular browser HTTP on the same port
[11:04] <bradb> SteveA: I'm confused about what changes we could have made from the way Z3 does things that would prevent an http() post to a URL with some XML not work.
[11:04] <SteveA> we don't
[11:04] <SteveA> we use a different server for each
[11:05] <bradb> SteveA: right, so that main issue is getting a test xmlrpc server running as part of the test suite?
[11:06] <SteveA> not really
[11:06] <SteveA> it is about dispatching to the correct server from an http() call
[11:06] <SteveA> the way i want to do that is by dispatching based on the host specified
[11:07] <SteveA> this will make the pagetests clear, and is required for when we start doing more stuff with hosts like malone.launchpad.net or bugs.launchpad.net
[11:08] <bradb> SteveA: for something that works right now, should posting to http://localhost:9000/... with some xml work?
[11:08] <bradb> (in a test)
[11:08] <SteveA> it is a bug if it works
[11:09] <SteveA> sorry
[11:10] <bradb> SteveA: what naming standard and file layout do you suggest for xmlrpc views?
[11:11] <SteveA> what do you see in launchpad/xmlrpc ?
[11:11] <bradb> right. I noticed there was a view called BranchSetAPI. I was expecting BranchSetXMLRPCView
[11:13] <bradb> or, in my case, FileBugXMLRPCView
[11:13] <SteveA> the thing is, it represents an external API
[11:13] <SteveA> we know it is a view
[11:13] <SteveA> we know it is xmlrpc
[11:13] <SteveA> because it is in launchpad/xmlrpc/
[11:14] <SteveA> you'll be asking for FileBugXMLRPCViewPythonClassInASCII next ;-)
[11:14] <bradb> bah!
[11:14] <SteveA> or hungarian style...
[11:15] <SteveA>   ACPVXFileBug
[11:15] <bradb> it seems like the same argument could be made for browser views
[11:15] <bradb> we know it is a view
[11:15] <bradb> we know it is browser
[11:15] <bradb> because it is in launchpad/browser/
[11:15] <SteveA> we don't call them WhateverBrowser
[11:16] <SteveA> we might consider not calling them WhateverView
[11:16] <SteveA> although, it is good to distinguish them from just Whatever
[11:18] <bradb> yeah. z3 doesn't seem to have many examples to look for guidance on the naming either, but I'll just go with canonical.launchpad.xmlrpc.FileBugAPI then
[11:19] <SteveA> thank you
[11:20] <bradb> np, thanks for the guidance
[12:51] <sabdfl> kikoman... go home!
[12:55] <kiko> never!
[12:56] <kiko> I have an interview report to write
[12:56] <kiko> I have THIRTY-FIVE emails from you in my inbox
[12:58] <kiko> sabdfl, btw, call tomorrow post-launchpad-meeting, check?
[12:59] <sabdfl> yes, i have 3pm UTC +1
[01:00] <kiko> oh, wonderful, that's even better.
[01:00] <kiko> I was expecting 2pm UTC+1
[01:00] <kiko> sabdfl, you have email from jordi, btw -- he'd appreciate your input there
[01:01] <SteveA> kiko: you need to read the mail from claire re-arranging the times
[01:01] <kiko> I just read it and had been confused.
[01:01] <kiko> re-read
[01:01] <kiko> I had read it before
[01:05] <SteveA> see you tomorrow.
[01:05] <kiko> l8z
[01:14] <marcin_> hi all
[01:14] <kiko> hello marcin_
[01:15] <marcin_> kiko: hi
[01:15] <marcin_> I woud like to talk about some change/improvement in bug management in LP
[01:16] <marcin_> could you tell me what do you think about an idea to separate hardware related bugs from other usability/feature request/bad code etc. bugs?
[01:17] <kiko> marcin_, basically classifying bugs, right?
[01:17] <kiko> marcin_, so there are some strategies you can use for this today
[01:17] <marcin_> we have a very long list of hardware related bugs that are unconfirmed for a long time simple because they are related to some hardware specific issues
[01:17] <kiko> first, you can add to the bug summary or description a simple keyword which you can then use to search
[01:17] <kiko> for instance
[01:18] <kiko> [!ubuntu-hardware!]
[01:18] <marcin_> and since bug-squad don't have an access to specific hardware they cannot solve or confirm these bugs
[01:18] <kiko> and then doing a serch for that.
[01:18] <kiko> right
[01:18] <kiko> the other thing you can do is define a hardware-bug-squad team
[01:18] <kiko> and subscribe that team to the relevant bugs
[01:18] <kiko> then use that team's subscribed bugs listing
[01:19] <kiko> the third way that could be done is through a feature which malone does not yet possess -- a form of classifying bugs using a string attribute.
[01:19] <marcin_> kiko: right...
[01:19] <marcin_> another question is - how many bugs are reported with mail?
[01:20] <marcin_> and how many with Malone - launchpad web application?
[01:20] <kiko> marcin_, that is an excellent question, and I don't know the answer to it! I am humbled!
[01:21] <kiko> marcin_, I'm putting a question out and I'll try getting you an answer soon.
[01:21] <marcin_> well because the problem is that if for example 90% bug reports goes from Malone than maybe simple solution is to add additional button to form
[01:21] <kiko> what sort of button>
[01:22] <marcin_> but if most of bug reports goes by mail than [ubuntu-hardware]  in summary could be usefull
[01:22] <marcin_> well button 'mark this bug as hardware related' or something like this
[01:22] <kiko> that proposal is controversial
[01:23] <kiko> because it is really specific to ubuntu and to hardware-related software
[01:23] <kiko> which is not as generic as malone would like to be
[01:23] <marcin_> well we currently got "This bug is a security issue"
[01:24] <marcin_> why not add another?
[01:24] <kiko> all software can present security issues, though.
[01:24] <kiko> hardware-related is a lot more specific.
[01:24] <kiko> and note also that we are trying to find a way of getting rid of that option too!
[01:24] <marcin_> hmm why?
[01:24] <kiko> because it is often misused.
[01:27] <marcin_> ok I understand - but is there any reason why Malone doesn't have any 'wizard' that could help to report bugs and then make these reports more friendly to bug-squad ppl?
[01:27] <marcin_> if you got some buttons in single form then they really can be missed very often
[01:28] <kiko> marcin_, what do you mean by a wizard?
[01:28] <marcin_> but you always can add some js code to split form to two or more steps
[01:29] <marcin_> 'wizdard' or 'druid' propably in Linux world - a kind of form that has more than 1 step
[01:29] <kiko> right, but what would the steps be?
[01:30] <marcin_> and then user can provide some information in each step - click 'next' and then provide some more info
[01:31] <marcin_> well for example: 1. select package, 2. is this hardware related bug?, 3. is this secutity issue?, 4. what version of ubuntu you use, 5. provide bug description
[01:31] <marcin_> etc.
[01:37] <kiko> that is really a custom workflow for ubuntu
[01:38] <kiko> which is interesting but difficult to do with our current generic UI
[01:40] <carlos> night!!
[01:49] <marcin_> kiko: is there any reason why you cannot improve this UI?
[01:49] <marcin_> kiko:  and make this more web2.0 than it currently is?
[01:50] <kiko> marcin_, we can improve the UI in many ways, including making it more dynamic "web2.0", but we need to take care to ensure that Malone remains generic and not Ubuntu-specific.
[01:50] <kiko> such a wizard as you are suggesting violates that second constraint. but there are other ways of addressing that!
[01:51] <marcin_> hmm I can agree with you but only partially
[01:51] <marcin_> because I think that if you got a lot of informations from user in well organized way
[01:51] <kiko> there's also an implementation difficulty, because what you say would require special code inside Launchpad to handle Ubuntu (and potentially other products/distros that wanted a custom workflow)
[01:51] <marcin_> you can always parse/transform this to simple txt message that could fit 'generic' malone
[01:52] <kiko> indeed that can be done in any front-end, including a web front-end that reposts information to launchpad.
[01:53] <marcin_> if you got 'Launchpad integration' package in Ubuntu
[01:53] <marcin_> and you add links to Rosetta in 'Help' menu
[01:53] <marcin_> then I think that this URL should be ubuntu-specific
[01:55] <marcin_> and for example - I can see very often this in Malone or in support requests
[01:55] <marcin_> I see bug report - than answer from some admin/bug triager "please provide ubuntu version you use"
[01:55] <marcin_> this question is a waste of time
[01:56] <marcin_> because I agree that Malone should be generic - but also there is no reason why it cannot have information about ubuntu version inside?
[01:56] <kiko> well
[01:56] <kiko> there is a proposal to capture that version in a text field and attach that to the description
[01:57] <kiko> just hasn't been done
[01:57] <kiko> we're considering it
[01:58] <marcin_> hmm stupid question then - is Malone/LP open source?
[01:58] <kiko> nope :)
[01:58] <marcin_> (afair it is not)
[01:58] <kiko> however
[01:58] <kiko> I am listening to your concerns
[01:58] <marcin_> right :)
[01:59] <kiko> even if we can't do exactly the solution you are proposing, I am aware of the issues you are raising and we are trying to find good ways of solving them
[01:59] <kiko> we're working on xml-rpc interfaces to various parts of launchpad
[01:59] <kiko> which would allow custom bug-filing apps to work easily
[01:59] <kiko> we're working on a guided bug form, which could include some of the information that you are citing
[02:00] <kiko> we are attempting to get work started on using AJAX more extensively in launchpad
[02:00] <marcin_> really nice...
[02:00] <marcin_> ajax is my hobby from few months ;)
[02:00] <kiko> and finally, we will eventually have some support for custom keywords, though the form in which that will be implemented is yet undefined
[02:00] <kiko> yeah, it is pretty cool ain't it
[02:00] <marcin_> do you work for Canonical?
[02:01] <kiko> indeed I do!
[02:02] <marcin_> I can see information on ubuntu.com that Canonical needs webmaster...
[02:03] <kiko> indeed we are looking
[02:03] <marcin_> I thought about it but unfortunately I'm just a beginner in Python development
[02:04] <kiko> are you interested in applying?
[02:04] <kiko> why don't you give it a shot anyway?
[02:04] <marcin_> well maybe I should try
[02:05] <marcin_> I'm not sure about requirements, about time and of course about money
[02:06] <marcin_> and another thing is that I got job so... not sure if I want to change...
[02:06] <kiko> right
[02:07] <kiko> that's something to consider always. :)
[02:07] <marcin_> but I'm also do a lot of things with Ubuntu
[02:07] <marcin_> s /I'm/I
[02:07] <marcin_> so it could be nice to work directly for Canonical
[02:08] <marcin_> do you know if this is a full time job?
[02:11] <marcin_> kiko: and if you would like than take a look at my specification I added to LP: https://launchpad.net/distros/ubuntu/+spec/webuntu
[02:11] <kiko> marcin_, I believe it is, but you'll need to submit a request to find out.
[02:12] <kiko> marcin_, ah interesting. so you are suggesting a set of web apps for managing ubuntu with a common look-n-feel?
[02:12] <marcin_> kiko: it's only draft but I will add better integration with LP as something to TODO list :)
[02:12] <kiko> heh
[02:12] <kiko> good point
[02:12] <marcin_> (tomorrow - it's 2:12 am here and I'm pretty tired)
[02:13] <marcin_> yes I think that linux is excellend 'server' system
[02:13] <marcin_> s/ excellend/excellent
[02:13] <marcin_> so it could be nice to use it's potential
[02:14] <kiko> yeah, managing it is really only for console ninjas today :)
[02:14] <marcin_> and with modern browsers we can do magic things with UI
[02:15] <marcin_> so ubuntu could work as something like 'Media Center' replacement etc.
[02:15] <marcin_> propably it could be easier and faster to develop web UI than wait for Gnome/KDE folks ;)
[02:17] <kiko> yeah
[02:17] <marcin_> maybe I will start to work on this project and then I will submit request to Canonical :-)
[02:17] <kiko> okay, time for me to roll zzzwards
[02:17] <kiko> good luck with your application
[02:17] <kiko> and feel free to ask if you need any help
[02:17] <marcin_> kiko: ok thanks
[02:19] <lifeless> jamesh: ping, your reviews are getting old
[02:46] <jamesh> lifeless: yeah.  I'll sort them out today
[03:14] <lifeless> spiv: new reviews por vous
[03:15] <spiv> lifeless: thanks
[03:15] <spiv> lifeless: any luck with the triple-branch merge?
[03:18] <lifeless> spiv: doing it after I finish ddaa's branch.
[03:19] <spiv> lifeless: Woo!
[03:29] <jamesh> lifeless: is the new wiki immutable for you?
[03:29] <lifeless> jamesh: fixed now
[03:29] <lifeless> jamesh: it was.
[03:29] <jamesh> so it is.
[04:30] <mpt__> Goooooooooooooooooooooooood afternoon Launchpadders!
[04:30] <ajmitch> hi
[05:49] <lifeless> spiv: these are merges of bzr and bzrtools right ?
[05:55] <lifeless> spiv: tests running
[06:20] <mpt> stub, staging won't let me log in
[06:21] <stub> works for me....
[06:23] <stub> mpt: Make sure you are using https://staging.launchpad.net/. Also, the cookie name changed recently for staging so if you have some sort of wierd cookie privacy thing setup you might have trouble.
[06:23] <lifeless> stub: are we using zope 3.2 in prod now ?
[06:23] <stub> Yes
[06:23] <lifeless> stub: the production tree on balleny still has 3.0 in sourcecode
[06:23] <lifeless> stub: should I fix that ?
[06:23] <stub> Hmm.... mpt is right.
[06:24] <mpt> I cleared my cookies half an hour ago and hadn't tried it since, so that can't be the problem
[06:24] <stub> lifeless: That is synced from rocketfuel built - how would that have happened?
[06:24] <stub> lifeless: And I don't see how the tests would pass either... are you sure?
[06:24] <lifeless> bzr info sourcecode/zope/
[06:24] <lifeless> ...
[06:25] <lifeless>       parent branch: sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/zope/3.0/test
[06:26] <lifeless> stub: how are you syncing it ? rsync ?
[06:26] <lifeless> spiv: two failures
[06:26] <stub> mpt: Looks like we are setting the correct cookie on login, but not checking the correct one for authentication purposes. Thankfully this only bites us on staging.
[06:26] <stub> lifeless: rsync
[06:27] <lifeless> and we are talking about ~/production/launchpad for pqm on balleny ?
[06:27] <lifeless> morning stub
[06:27] <lifeless> bem
[06:27] <lifeless> meh
[06:27] <lifeless> morning SteveA
[06:29] <stub> lifeless: Yes
[06:30] <lifeless> stub: ok, I'm checking
[06:31] <lifeless> stub: your rsync is faulty
[06:32] <lifeless> stub: its clearly not the content of chinstrap:/home/warthogs/archives/rocketfuel-built/launchpad
[06:32] <stub> ------------------------------------------------------------
[06:32] <stub> revno: 32
[06:32] <stub> committer: Canonical.com Patch Queue<EMAIL_ADDRESS>[06:32] <stub> branch nick: 3.2
[06:32] <stub> timestamp: Thu 2006-05-11 12:25:40 +0100
[06:32] <stub> message:
[06:32] <stub>   Add missing __init__.py's identified by spiv
[06:32] <stub> It is *a* 3.2 branch
[06:33] <lifeless> intruiging
[06:34] <stub> And test.py is definitely the 3.2 one
[06:34] <lifeless> anyhow, I'll finish these merges and look closer
[06:38] <stub> mpt: I've found the problem and will commit it
[06:41] <stub> mpt: If you log onto production, you should find you are also logged onto staging if you don't want to wait ;)
[06:41] <stub> Hmm... maybe.
[07:24] <lifeless> stub:
[07:24] <lifeless> File "/home/pqm/production/bzr/lib/canonical/database/sqlbase.py", line 371, in canonical.database.sqlbase.quote
[07:24] <lifeless> Failed example: quote("'hello'")
[07:24] <lifeless> Expected: "'\\'hello\\''"
[07:24] <lifeless> Got: "'''hello'''"
[07:24] <lifeless> is that indicative of skew between sqlobject and launchpad ?
[07:26] <jamesh> lifeless: sounds like it is (see stub's message about the quoting change)
[07:26] <lifeless> jamesh: yes, thats why I'm asking ;)
[07:26] <lifeless> spiv: ping
[07:27] <jamesh> lifeless: btw, the pending-reviews page is working again (had to add some code to pass the appropriate http auth header when grabbing the wiki page)
[07:27] <spiv> lifeless: pong
[07:28] <stub> lifeless: That test should have been updated. Maybe I neglected to push?
[07:30] <lifeless> spiv: what commit message do you want ?
[07:30] <lifeless> jamesh: grazzi
[07:30] <spiv> lifeless: for the launchpad/bzr/bzrtools branches?
[07:31] <lifeless> spiv: yes
[07:32] <spiv> lifeless: Something along the lines of "Update importd tests for bzr 0.8" for lp and "Update to recent upstream bzr.dev/bzrtools" for bzr/bzrtools.
[07:32] <lifeless> spiv: reviewed by ? or trivial ?
[07:32] <spiv> Unreviewed, so I guess it's trivial ;)
[07:32] <lifeless> muhaha
[07:33] <spiv> rs=spiv might be more accurate ;)
[07:33] <lifeless> and self referential
[07:34] <spiv> They aren't huge changes, but I really really want them in so I can stop sourcecode/* tests failing (I will do the merge to re-enable that as soon as this lands), and to unblock a bunch of other things for me and ddaa.
[07:34] <lifeless> spiv: me too
[07:37] <lifeless> spiv: its in
[07:37] <spiv> lifeless: many thanks!
[07:40] <lifeless> stub: production (pqm@balleny:~/production/launchpad/sourcecode) subbranches are out of date with respect to the chinstrap rocketfuel-built.
[07:40] <lifeless> stub: including zope
[07:40] <lifeless> stub: what command are you using when you sync them ?
[07:41] <stub> Erm.... you would have been the last person to rebuild it with the 1.63 rollout
[07:41] <lifeless> stub: I didn't rebuild it, I updated it. This would explain it as 1.62 was pre-knit
[07:41] <stub> Only cherry picks since then, and I don't update the subbranches for that unless necessary
[07:41] <stub> ok
[07:42] <stub> Man bzr push takes ages (when you have bittorrent running)
[07:42] <lifeless> bt uses all bandwidth, news at 11.
[07:45] <lifeless> stub: bpqm@balleny:~/production/sqlobjectupdate/sourcecode/sqlobject$ bzr merge sftp://chinstrap/home/warthogs/archives/stub/sqlobject/quotingfix
[07:45] <lifeless> Nothing to do.
[07:45] <stub> Still pushing...
[07:49] <lifeless> stub: conflicts:
[07:50] <lifeless> bzr merge sftp://chinstrap/home/warthogs/archives/stub/launchpad/trivial
[07:50] <lifeless> bzr: WARNING: Text conflict in database/sampledata/current.sql
[07:50] <lifeless> bzr: WARNING: Text conflict in lib/canonical/launchpad/interfaces/potemplate.py
[07:50] <lifeless> bzr: WARNING: Text conflict in lib/canonical/launchpad/scripts/bugnotification.py
[07:50] <lifeless> bzr: WARNING: Text conflict in lib/canonical/launchpad/zcml/potemplate.zcml
[07:50] <stub> I'm still pushing
[07:50] <lifeless> 4 conflicts encountered.
[07:50] <lifeless> stub: garh, ok
[07:51] <stub> I killed the sftp push and rspush is underway
[07:51] <lifeless> stub: well, say when you want me to do this
[07:53] <stub> lifeless: done
[07:59] <lifeless> stub: I still get
[07:59] <lifeless> pqm@balleny:~/production/sqlobjectupdate/sourcecode/sqlobject$ bzr merge sftp://chinstrap/home/warthogs/archives/stub/sqlobject/quotingfix
[07:59] <lifeless> Nothing to do.
[07:59] <lifeless> stub: is it possible you merged that in already to some branch ?
[08:00] <stub> Nope, because the tests won't pass without the SQLObject fix being landed. The only change on that branch should be the docstrings in sqlbase.py :-/
[08:00] <lifeless> did you update production ?
[08:01] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/filecuFtP1.html
[08:02] <stub> lifeless: No - the production branch I just updated sourcecode/SQLObject
[08:02] <stub> I think
[08:02] <lifeless> stub: that will be it.
[08:03] <lifeless> ok, merge test running
[08:10] <stub> lifeless: If I did something like push changes to ~/archives/rocketfuel/launchpad/production/1.63 on balleny, could I trigger PQM errors like mpt reported?
[08:13] <lifeless> stub: no
[08:14] <lifeless> stub: there was an sftp glitch, something killed pqm ? or something like that.
[08:14] <lifeless> that left the branch on chinstrap locked.
[08:14] <lifeless> someone else came along and unlocked it
[08:14] <lifeless> stub: not though, please dont use rsync between the rocketfuel archives
[08:14] <stub> ok. I was wondering if I needed to disable pqm when doing that sort of operation now things seem to be using repositories
[08:15] <lifeless> as long as you use 'bzr push', not 'bzr rspush', no, it will all just work.
[08:15] <stub> lifeless: ok.
[08:16] <lifeless> stub: worst case it might fail to grab the lock, but if it does that, and you get an error, tell me - its a condition we should handle anyway
[08:20] <lifeless> jamesh: ping
[08:20] <lifeless> jamesh: what did you think of the europython abstract discussion?
[08:20] <lifeless> spiv: you too ^
[08:28] <spiv> lifeless: I don't have any new insights to offer.  Pretending to be an attendee, I'm not sure if you're focusing on making plugins in python or a specific way of testing, so I'm not really sure what to expect.  It sort of sounds like two different talks put together.
[08:29] <lifeless> spiv: I just got a test failure from importd tests
[08:29] <lifeless> test_pty_output (importd.tests.test_baz2bzr.TestBaz2bzrPublishFeature)
[08:29] <spiv> lifeless: crud.  What test?
[08:29] <lifeless> Output:
[08:29] <lifeless> 'importing<EMAIL_ADDRESS>into bzrworking\r'
[08:29] <lifeless> '0/2 revisions\r'
[08:29] <lifeless> '1/2 revisions\r'
[08:29] <lifeless> '2/2 revisions\r'
[08:29] <lifeless> 'Cleaning up\r'
[08:29] <lifeless> 'Import complete.\r'
[08:29] <lifeless> '0/1 read knit index\r'
[08:29] <lifeless> '1/1 read knit index\r'
[08:29] <lifeless> '0/1 read knit index\r'
[08:29] <lifeless> '1/1 read knit index\r'
[08:29] <lifeless> '0/1 read knit index\r'
[08:29] <lifeless> '1/1 read knit index\r'
[08:29] <lifeless> '0/1 read knit index\r'
[08:31] <lifeless> running it again
[08:31] <spiv> I've never seen that locally.  I wonder what's different...
[08:32] <lifeless> 'make check_merge 2>&1 | less'
[08:43] <jamesh> lifeless: the talk sounds interesting.  I agree with Steve about emphasising plugins over testing
[08:46] <spiv> lifeless: I cannot reproduce that locally :/
[08:57] <lifeless> spiv: mleep
[08:58] <lifeless> spiv: fails again
[08:58] <lifeless> spiv: the expect value for the test is :
[08:58] <lifeless> Expected:
[08:58] <lifeless> 'importing<EMAIL_ADDRESS>into bzrworking\r'
[08:58] <lifeless> '0/2 revisions\r'
[08:58] <lifeless> '1/2 revisions\r'
[08:58] <lifeless> '2/2 revisions\r'
[08:59] <lifeless> 'Cleaning up\r'
[08:59] <lifeless> 'Import complete.\r'
[08:59] <lifeless> ''
[08:59] <lifeless> failing tests are:
[08:59] <lifeless> test_pipe_output (importd.tests.test_baz2bzr.TestBaz2bzrPublishFeature
[08:59] <lifeless> test_pty_output (importd.tests.test_baz2bzr.TestBaz2bzrPublishFeature
[09:00] <lifeless> sqlobjectupdate$ bzr revno
[09:00] <lifeless> 3600
[09:00] <lifeless> pqm@balleny:~/production/sqlobjectupdate$ bzr revno sourcecode/bzr
[09:00] <lifeless> 1370
[09:00] <lifeless> pqm@balleny:~/production/sqlobjectupdate$ bzr revno sourcecode/bzrtools
[09:00] <lifeless> 216
[09:02] <lifeless> rf-built is up to date on chinstrap
[09:06] <spiv> lifeless: does just "make importdcheck" fail?  (I'm pretty sure it should be the same, but let's be certain)
[09:20] <lifeless> spiv: checking
[09:25] <lifeless> fails
[09:33] <spiv> Well that's something at least ;)
[09:37] <spiv> lifeless: all of a sudden I can reproduce, I'm not sure why.
[09:37] <lifeless> yay
[09:38] <lifeless> so rf is borked until this is fixed.
[09:38] <lifeless> should I rollback, or are you on it ?
[09:39] <spiv> lifeless: I'm on it.  The "fix" is just to extend the expected output; this actually lines up better with how it was before I updated it.  The way these tests work needs rethinking though, because this is a very fragile way to test whatever it's trying to test...
[09:39] <lifeless> regex matching ?
[09:39] <lifeless> (i agree)
[09:39] <spiv> Something like that, first we need to figure out precisely what we're trying to test for.
[09:40] <lifeless> david needs output
[09:40] <spiv> Tests without a clear purpose are something I'm increasingly uncomfortable with...
[09:40] <lifeless> otherwise the job is considered 'hung' and get skilled
[09:40] <lifeless> s/skill/kill/
[09:40] <spiv> I see.  I'll file a bug on the subject after I fix, push and merge.
[09:42] <cprov> good morning, hackers
[09:42] <lifeless> spiv: pqm is disabled
[09:42] <lifeless> spiv: fix, push, tell me :)
[09:43] <spiv> lifeless: thanks (and thanks for bearing with me!)
[09:44] <SteveA> lifeless: morning
[09:44] <lifeless> hi SteveA
[09:46] <spiv> (and I still have no idea why the another, supposedly equivalent, tree I have for this behaves differently, but first things first...)
[09:48] <lifeless> echo $PYTHONPATH
[09:55] <spiv> lifeless: pushed: sftp://chinstrap.ubuntu.com/home/warthogs/archives/spiv/launchpad/importd-pty-test-fix/
[10:09] <lifeless> spiv: I think it might be a race condition on stderr
[10:11] <lifeless> spiv: so I expect this will toggle and fart around. We'll want a pattern based test soon IMO.
[10:13] <spiv> lifeless: Hmm, I don't think it's a stderr issue.  test_pipe_output uses stdout=PIPE, stderr=STDOUT but fails anyway.
[10:13] <lifeless> spiv: well, its done and pushed
[10:13] <spiv> (pity, because it's a good theory!)
[10:13] <lifeless> may the farce be with you
[10:14] <spiv> Heh.
[10:14] <spiv> lifeless: Let's find out... :)
[10:14] <lifeless> I got my batteries today
[10:14] <SteveA> spiv, jamesh, stub: i'd like to arrange a skype call tomorrow, either individually, or we can try a conference, to talk over some issues about the ORM for launchpad, project "L" and the other project "L".
[10:15] <lifeless> I now have ~12 hours real world run-time on batter
[10:15] <SteveA> deep fried electrons
[10:15] <spiv> lifeless: whee
[10:16] <spiv> SteveA: Sounds good.  I'd guess that roughly this time (i.e. 0800 UTC) is probably good for everyone.
[10:16] <SteveA> okay, that suits me well too.
[10:20] <stub> yer
[10:23] <stub> I might not be the brightest spark though - I seem to have flu or tonsillitis or other nasty.
[10:25] <jamesh> SteveA: okay
[10:45] <spiv> lifeless: is pqm running again?
[11:23] <lifeless> https://launchpad.net/ | developer meeting: Thu 25 May, 1200UTC (wiki:MeetingAgenda) |<EMAIL_ADDRESS>(wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39
[11:59] <carlos> jordi: ping
[11:59] <jordi> pong
[11:59] <carlos> jordi: could you send the Rosetta announcement?
[11:59] <carlos> I think you should do it as our public face
[12:00] <jordi> I can, yes
[12:00] <jordi> should I take it from the wiki?
[12:00] <carlos> yes
[12:14] <sabdfl> BjornT: is https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc up to date?
[12:19] <SteveA> bjorn is out running some errands
[12:21] <SteveA> also, that page should be moved over to help.launchpad.net
[12:24] <carlos> SteveA: should we move now all Rosetta pages from wiki.ubuntu.com to help.launchpad.net ?
[12:24] <carlos> SteveA: if the answer is 'yes', do we have a standard way to name the pages there?
[12:26] <SteveA> there's two things we're doing with help.ubuntu.com
[12:26] <SteveA> one of them is that we're going to have a mapping from types of pages in launchpad to pages on the wiki
[12:26] <SteveA> so, for example, a person's edit gpg keys page will get a page on the wiki, where help on that page can be written down
[12:26] <SteveA> the other thing we're going to do with help.launchpad.net
[12:26] <carlos> right
[12:27] <SteveA> (argh... read help.ubuntu.com and help.launchpad.net earlier)
[12:27] <SteveA> is to have documentation explaining things users need to know about, like how to use the email UI
[12:27] <SteveA> and how to use rosetta effectively
[12:27] <SteveA> now, to answer your question
[12:28] <SteveA> we need to keep in mind that right now, Rosetta is most focused on ubuntu
[12:28] <SteveA> on making ubuntu translated well
[12:28] <SteveA> so we must be careful to provide information and docs to people who want to help with ubuntu, if those docs will help in that case
[12:30] <carlos> well, the FAQ page is not ubuntu specific
[12:30] <carlos> and I think it's a general rule about how to handle translations in Ubuntu and other distros/products
[12:31] <carlos> so I guess the FAQ page could be moved
[12:32] <SteveA> okay
[12:32] <SteveA> but make sure that ubuntu people aren't lost for help
[12:32] <SteveA> so, leave pointers to the new pages when those pages are moved
[12:33] <mpt_> bah, Internet Explorer is stupid
[12:33] <BjornT> sabdfl: yeah, MaloneEmailInterfaceUserDoc should be up to date.
[12:34] <carlos> SteveA: yeah, the idea was to note the movement
[12:34] <carlos> SteveA: there are links on launchpad that should be updated too
[12:34] <SteveA> BjornT: is that page referred to from launchpad anywhere?
[12:35] <BjornT> SteveA: yeah, i think so. in some about box.
[12:35] <BjornT> SteveA: https://launchpad.net/malone, on the left.
[12:35] <SteveA> okay.  i'd like you to change the link to help.launchpad.net/UsingMaloneEmail and move that doc there
[12:36] <SteveA> unless your or mpt_ can think of a better page name
[12:37] <SteveA> also, i wonder if the email interface should have a version number
[12:37] <SteveA> so we can note the version number in the docs
[12:37] <SteveA> and we'll know that things are kept up to date
[12:43] <BjornT> yeah, could be worth having a version number
[12:48] <sabdfl> thanks BjornT
[12:51] <mpt_> hmmm
[12:56] <SteveA> hmm ?
[12:57] <mpt_> SteveA, how might I do ++debug++source on the 404 page?
[12:57] <mpt_>  /fqhwgads/++debug++source doesn't work
[12:57] <SteveA> you put that first
[12:57] <SteveA>  /++debug++source/asdasd
[12:58] <mpt_> ah, beautiful, thanks
[12:58] <SteveA> Znarl: ping
[12:58] <Znarl> SteveA : Pong?
[12:58] <SteveA> hi.  bjorn and i are having trouble editing pages on help.launchpad.net
[12:58] <SteveA> any idea what might be up
[12:58] <SteveA> we're both logged in to it
[12:59] <Znarl> SteveA : Do you have an example page that doesn't work for you?
[12:59] <SteveA> https://help.launchpad.net/UsingMaloneEmail
[01:00] <Keybuk> hi guys,
[01:00] <Keybuk> do we have any stats on the number of people who've used "Translate this Application" or "Get Help Online" ?
[01:01] <Znarl> SteveA : Ok, fixed.
[01:01] <SteveA> thanks, what was wrong?
[01:01] <SteveA> Keybuk: the apache logs will tell.  no stats though.
[01:02] <Keybuk> SteveA: any chance of a quick guess?
[01:02] <mpt_> Get Help Online has never been implemented
[01:03] <SteveA> mpt_: what does "implemented" mean?
[01:04] <mpt_> SteveA, I mean even roughly following Mark's idea of having and editable list of support options for each distribution or product
[01:05] <mpt_> Kiko and I put in a dummy page just before the Breezy release, and iirc it hasn't been changed since
[01:05] <mpt_> the spec is LaunchpadIntegrationHelpPage
[01:06] <SteveA> Keybuk: i think all the apache access goes via gangotri, so the steps for any kind of guess are to get access to the apache logs, and then do a grep | wc -l on them
[01:06] <mpt_> though iirc the current spec is a *bit* more complex than it should be, in that it should just be a set of (link, title, description)
[01:06] <Keybuk> SteveA: do you not have anybody on your staff with access? :(
[01:07] <SteveA> sure, various people have access to gangotri, including me.  i haven't looked at apache logs on there though, i only know where the launchpad stuff is
[01:07] <SteveA> maybe Znarl can offer advice on where apache logs live
[01:14] <SteveA> Keybuk: okay, i have the logs
[01:20] <salgado> stub, around?
[01:20] <stub> salgado: yes
[01:21] <salgado> stub, do you have a dump of the production db handy, for me to apply it on mawson?
[01:21] <stub> There is one a few days old in ~stub on mawson
[01:22] <stub> lifeless: Did that SQLObject/launchpad landing work?
[01:24] <salgado> stub, I think it should be fine... can you remind me how to apply it?
[01:26] <stub> salgado: pg_restore --no-acl --no-owner --dbname=mynewlycreateddb thefile.dump
[01:28] <salgado> stub, cool. /me notes that somewhere so he won't forget anymore
[01:28] <salgado> cprov, around?
[01:32] <salgado> spiv, ping
[01:32] <spiv> salgado: pong
[01:32] <salgado> hi spiv
[01:33] <salgado> spiv, kiko reviewed my mirror-management2 branch, and he asked me to check with you if you could review one test
[01:33] <salgado> it's one of those twisted tests
[01:33] <spiv> Sure, got a link/pastebin?
[01:34] <salgado> spiv, it's the test_distributionmirror_prober.py on https://chinstrap.ubuntu.com/~jamesh/pending-reviews/salgado/launchpad/mirror-management2/full-diff
[01:34] <salgado> I added more tests on that file, to test the prober for release mirrors
[01:35] <Yannig> Other dumb questions :p
[01:35] <Yannig> Do I really need to be in https://launchpad.net/distros/ubuntu/dapper/+source/debian-installer/+pots/debian-installer/oc/+translate to upload the debian-installer po file or is it detected automatically?
[01:35] <Yannig> If not, would it be possible to rename the oc.po file into debian_installer_oc.po for example?
[01:36] <spiv> salgado: why bother with the "except Exception, e: self.fail(...)"?  Why not just let the test error?
[01:37] <Yannig> Poor carlos, I take all his time with my dumb questions :p
[01:37] <carlos> Yannig: where do you want to import it?
[01:38] <Yannig> I just fear to make a mistake importing the file into the wrong location
[01:38] <spiv> salgado: is there any Twisted IO involved?  It doesn't look like it, but I'd like to be sure that you don't intend that.
[01:38] <Yannig> I have so many oc.po files... :(
[01:40] <carlos> you need to upload them to the right pofile
[01:40] <spiv> salgado: So, you have a problem.
[01:40] <mpt_> woo
[01:40] <carlos> Yannig: no way to do a single tarball upload
[01:40] <salgado> spiv, about the exception, I think it's nicer to have a proper message and a failure than an error with no clear explanation
[01:40] <mpt_> SteveA, just finished the portlet trimming and the Internet Explorer layout fixes
[01:40] <spiv> salgado: if got_result in test_failure_propagation is wrongly triggered, the self.fail it calls won't have the desired effect.
[01:40] <Yannig> Fair enough, thanks
[01:40] <SteveA> mpt_: cool
[01:41] <spiv> salgado: I think it's nicer to get a full traceback from the source of the error, with an unmangled error message...
[01:41] <Yannig> And would it be possible to rename the oc.po file into debian_installer_oc.po for example?
[01:41] <salgado> spiv, the TestMirrorCDImageProberCallbacks indeed doesn't have IO, it's just for testing that the callbacks do what they're expected
[01:42] <spiv> salgado: Comments in the test with those messages instead would server the same purpose.
[01:42] <salgado> IIRC, the tests for IO are in the TestProberProtocol
[01:42] <Yannig> It would be easier to download several po files
[01:42] <spiv> Anyway, back on got_result: Deferreds catch *all* errors from callbacks (to turn into errbacks).
[01:42] <carlos> Yannig: yes, we don't care about the filename
[01:42] <salgado> spiv, fair enough, I'll remove the try/except and leave a comment
[01:43] <Yannig> Great :)
[01:43] <carlos> Yannig: oh, you mean for downloading it with that name?
[01:43] <carlos> Yannig: yes, I guess it's doable too, please file a bug
[01:43] <lifeless> when is the meeting ?
[01:43] <lifeless> 15 minutes ?
[01:43] <spiv> Your test would still fail correctly because the self.assertEqual([1] , ok).
[01:43] <spiv> Which basically means the got_result part is redundant.
[01:44] <spiv> (If things work, the test will pass without it, and if things don't work, the test will fail without it)
[01:44] <spiv> It's useful to have it for debugging, though...
[01:45] <spiv> Actually, it's definitely useless.
[01:46] <spiv> Twisted already unit tests that d.errback(<a failure>) will fire the first errback.
[01:46] <spiv> You don't need to cover that in your own test.
[01:47] <SteveA> mpt: did you get to talk with kiko about the filebug page?
[01:47] <spiv> So given that you're doing d.errback(Failure(ZeroDivisionError())), adding a callback to d in the test is definitely just a distraction.
[01:47] <mpt> SteveA, no, I haven't seen him awake for several days
[01:47] <SteveA> okay, we should discuss this after the lp meeting
[01:47] <spiv> salgado: Also, dl is totally unused in that test.
[01:48] <Yannig> carlos> Ups, I think I didn't post where it was supposed to (https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/46552) :(
[01:48] <Ubugtu> Malone bug 46552 in debian-installer "po files names" [Normal,Unconfirmed]
[01:48] <spiv> salgado: and the errback added in the "d.addErrback(self.callbacks.ensureOrDeleteMirrorCDImageRelease)" line is never used.
[01:48] <Yannig> Sorry :(
[01:50] <SteveA> meeting in 10 mins
[01:50] <spiv> salgado: does the first half of test_failure_propagation ("Make sure that ensureOrDeleteMirrorCDImageRelease() does not propagate ProberTimeOut or BadResponseCode failures.") actually affect the second half ("Any failure that is not a ProberTimeout or BadResponseCode should be propagated because that is probably a bug in our code.") at all?  It looks like two seperate tests.
[01:50] <SteveA> take a workrave now if you need it
[01:50] <salgado> spiv, that's true. the first two tests already make sure that my callbacks don't propagate timeouts and badresponsecodes. I think I just need to add a third test to make sure they propagate any other exception
[01:50] <lifeless> I have a small ELYNNE
[01:50] <SteveA> me, i'm going to rest my wrists and flex my fingers on some honking blues licks in the style of jeff healey
[01:50] <carlos> Yannig: don't worry, I fixed it
[01:51] <lifeless> I will be back in a few minutes, but may miss the start
[01:51] <spiv> salgado: and make them into three seperate test methods, please.
[01:51] <spiv> salgado: small tests with a clear, specific purpose are better than big rambling tests that try to do a bit of everything.
[01:56] <lifeless> spiv: this ties in with my distaste for many doctest style tests actually.
[01:56] <spiv> lifeless: Yeah, I know what you mean.
[02:01] <salgado> it's time!
[02:01] <kiko-zzz> me
[02:01] <lifeless> you!
[02:01] <SteveA> Welcome to today's launchpad meeting
[02:01] <SteveA> a thunderstorm has just started in vilnius
[02:01] <SteveA> MEETING STARTS
[02:01] <SteveA> who's present today?
[02:01] <mpt> Please return to your seats and fasten your seatbelts
[02:01] <malcc> me
[02:01] <cprov> me
[02:01] <carlos> me
[02:01] <mpt> me
[02:01] <kiko> him
[02:01] <salgado> me
[02:01] <BjornT> me
[02:01] <matsubara> me
[02:02] <stub> me
[02:02] <sivang> me
[02:02] <lifeless> me
[02:02] <SteveA> kiko: his infernal majesty?  surely now
[02:02] <SteveA> kiko: his infernal majesty?  surely not
[02:02] <spiv> me
[02:02] <kiko> the royal him!
[02:02] <jamesh> me
[02:02] <SteveA> ddaa sends apologie
[02:02] <SteveA> s
[02:03] <SteveA> he's on public holidays / vacations, and will be back monday
[02:03] <malcc> This thunderstorm isn't doing your typing any favours Steve
[02:03] <kiko> apologies for being on holiday!
[02:03] <SteveA> malcc: must be the nervous tension
[02:03] <SteveA> either that or too much string-bending just prior to the meeting
[02:03] <SteveA> == Agenda ==
[02:03] <SteveA>  * Roll call
[02:03] <SteveA>  * Agenda
[02:03] <SteveA>  * Next meeting
[02:03] <SteveA>  * Activity reports
[02:03] <SteveA>  * Actions from last meeting
[02:03] <SteveA>  * Launchpad oops milestone report
[02:03] <SteveA>  * Outstanding sysadmin requests
[02:03] <SteveA>  * Production and staging (stub)
[02:03] <SteveA> ----
[02:03] <SteveA>  * (other items)
[02:03] <SteveA>  * launchpad bzr development workflow (robert/jamesh)
[02:03] <SteveA>  * Design discussion with reviewer by voip (Steve)
[02:03] <SteveA>  * Discuss a solution for the Retry exceptions (matsubara, kiko)
[02:03] <SteveA> ----
[02:03] <SteveA>  * Keep, Bag, Change
[02:03] <SteveA>  * Three sentences
[02:03] <SteveA>
[02:03] <SteveA> next meeting: i propose the same time next week
[02:04] <kiko> why not
[02:04] <cprov> yup
[02:04] <SteveA> it is done
[02:04] <SteveA>  * Activity reports
[02:04] <lifeless> godlike
[02:04] <malcc> Dude next month is June
[02:04] <SteveA> after a decent performance last week, this week i suck
[02:04] <salgado> up to date
[02:05] <kiko> I'm there
[02:05] <stub> up to date
[02:05] <BjornT> up to date
[02:05] <jamesh> I suck, but am putting together another summary
[02:05] <malcc> Up to date after a lame summary today
[02:05] <mpt> up to date
[02:05] <SteveA> thanks mpt
[02:05] <spiv> up to date.
[02:05] <matsubara> up to date
[02:05] <SteveA> thanks malcc
[02:05] <carlos> up to date
[02:05] <cprov> i suck, will send a summary for this week, I'm in a sprint anyway
[02:05] <mpt> (but, I batched the last three)
[02:05] <matsubara> I'm also guilty of batching.
[02:05] <SteveA> cprov: sprinters are excused from daily reports, summaries are appreciated
[02:06] <SteveA>  * Actions from last meeting
[02:06] <malcc> We got a last-one-wins concurrency error on the topic, next meeting is still in August
[02:06] <SteveA> there were none
[02:06] <cprov> SteveA: I know, I will do a descent summary this time ;)
[02:07] <SteveA>  * Launchpad oops milestone report
[02:07] <SteveA> matsubara: hit it!
[02:07] <matsubara> Top exceptions are on shipit which are all assigned to Salgado.
[02:07] <matsubara> He has been working on them. Bugs 45601 and 5812
[02:07] <Ubugtu> Malone bug 45601 in shipit "OOPS trying to Cancel the same request on two different tabs" [Normal,In progress]  http://launchpad.net/bugs/45601
[02:07] <matsubara> Another outstanding exception is the Retry one, which I added a item to the
[02:07] <matsubara> MeetingAgenda. Do you want to discuss it now or leave it to later?
[02:07] <mpt> Now we'll never have another meeting
[02:07] <matsubara> as later I mean the Proposed items section
[02:07] <matsubara> let's do it now then
[02:08] <SteveA> yeah, do it now
[02:08] <matsubara> We're seeing lots of Retry exceptions, caused by the session machinery, and
[02:08] <matsubara> stub advised that to debug it properly identify the cause we need bug 31479 fixed..
[02:08] <matsubara> spiv is assigned to it, and said in the last meeting that he would work on it at.
[02:08] <matsubara> the end of this week.
[02:08] <Ubugtu> Malone bug 31479 in launchpad "Retry exceptions should include information about the original query" [Critical,Confirmed]  http://launchpad.net/bugs/31479
[02:08] <stub> I was also going to refactor the session machinery again to make it even friendlier
[02:08] <SteveA> i believe we also have some concurrency improvements in the session machinery landing or landed soon
[02:08] <SteveA> stub: eta ?
[02:08] <stub> I noticed, however, that the number of exceptions dropped from hundreds to two in the last error report, which is very unusual
[02:09] <stub> eta Tuesday
[02:09] <spiv> matsubara: Yeah, that's right near the top of my todo list finally.
[02:09] <matsubara> I think we're good then. kiko, anything else?
[02:09] <SteveA> any idea why the exceptions would drop to two?
[02:09] <SteveA> is there some kind of fault in error reporting?
[02:09] <SteveA> or has some evil DOS attack stopped hitting us?
[02:09] <kiko> I'm not sure. Could be the Shipit DOS :)
[02:10] <stub> Or the condition that was triggering the number of Retrys stopped. Possibly a DOS we didn't notice.
[02:10] <stub> Shipit is as busy as ever
[02:10] <SteveA> stub: would you check the other launchpad logs, just to make sure there isn't an error that somehow isn't sending oopses?
[02:10] <stub> ok
[02:11] <SteveA> thx
[02:11] <matsubara> Top timeouts are the same. Most of them assigned to kiko. kiko, any news about it?
[02:11] <kiko> I've worked on a relatedjoin fix that appears to improve many of them
[02:11] <kiko> I'm also working on adding prejoins to multiple and relatedjoin
[02:11] <kiko> it's going slow because I'm overloaded
[02:11] <kiko> might get in by tomorrow
[02:12] <kiko> spiv will need to review at some point
[02:12] <matsubara> ok
[02:12] <matsubara> Would help a lot the QA job to solve bug 30670. It's currently assigned to stub. Is it feasible?
[02:12] <Ubugtu> Malone bug 30670 in launchpad "Launchpad developers should have admin privileges on staging" [Normal,Confirmed]  http://launchpad.net/bugs/30670
[02:12] <bradb> Uh, I'm on crack. I'm here and up-to-date on activity reports. /me lost track of the time while answering email.
[02:13] <SteveA> i'm not sure about that one
[02:13] <stub> matsubara: It is feasable, but also limits the ability of developers to test stuff.
[02:13] <SteveA> matsubara: an issue there is that it means launchpad developers get to see private bugs
[02:13] <SteveA> and private bugs are mirrored to staging each day
[02:13] <stub> matsubara: A better approach might be to insert superuser accounts using different names/email addresses after the database update, giving you two accounts on staging.
[02:13] <SteveA> stub: i need to implement hats...
[02:13] <stub> SteveA: yup
[02:13] <matsubara> stub: that would do
[02:13] <lifeless> SteveA: pull it off the cdrom
[02:14] <SteveA> i don't want all launchpad developers to have admin access on staging
[02:14] <matsubara> stub: i think it's even easier to do right?
[02:14] <SteveA> i'm happy with just certain people who need it to have such access
[02:14] <stub> matsubara: Yes
[02:14] <lifeless> SteveA: I may be missing something, but dont all developers have db access to staging ?
[02:14] <salgado> lifeless, no
[02:14] <matsubara> lifeless: not the db, but to the web UI
[02:14] <SteveA> lifeless: i'd be not in favour of that either
[02:14] <stub> lifeless: nope. We control it, because it is a full production mirror including security sensitive stuff.
[02:15] <kiko> meneeder
[02:15] <lifeless> stub: yes, aware of that :). Must be mis-recalling.
[02:15] <stub> It generally gets granted on need though
[02:16] <SteveA> matsubara: for what qa purposes do you want admin access on staging?
[02:16] <matsubara> SteveA: sometimes I need to reproduce some bug
[02:16] <matsubara> and it's easier to use staging
[02:16] <mpt> to reproduce bugs in things like source imports
[02:17] <SteveA> okay.  i'm fine with launchpad admins plus matsubara having admin access on staging
[02:17] <SteveA> but not all launchpad devs
[02:17] <SteveA> if stu can rig up something to make that so, that's fine
[02:18] <matsubara> SteveA: ok, I'll update the bug description
[02:18] <matsubara> And as a final note, I'd like to ask developers to use the in-progress status and to append the bug number to your commit messages.
[02:18] <SteveA> matsubara: please give an example of a commit message that is good in this regard
[02:19] <matsubara> Fix bug url (bug summary)
[02:19] <mpt> matsubara, perhaps many of the bugs for which you might need staging are also bugs of insufficient sampledata
[02:19] <SteveA> and, do you mean pqm merge messages, or any old commit messages?
[02:19] <matsubara> SteveA: I mean pqm merge messages
[02:19] <jamesh> so you're interested in mainline log messages
[02:20] <SteveA> i've been talking with jamesh and others about our pqm email messages
[02:20] <matsubara> mpt: yes, that's it. can't think of a real life example right now, though
[02:20] <SteveA> i think developers should be able to say in a "local" commit "fixed bug URL SUMMARY"
[02:20] <mpt> matsubara, an example is that localhost doesn't have anything in the translation import queue
[02:20] <SteveA> and the email should pull these out of the sub-commits
[02:20] <mpt> sampledata doesn't, rather
[02:20] <jamesh> (which makes sense when trying to match up which bugs are fixed in a given rollout)
[02:20] <SteveA> and display them prominently in the email from pqm
[02:20] <SteveA> that way, a developer can focus on one commit at a time
[02:20] <SteveA> and not need to repeat things for pqm
[02:21] <SteveA> but, until we have implemented that, i ask everyone to do as matsubara asks
[02:21] <SteveA> and add "fix bug URL SUMMARY" to pqm messages
[02:21] <bradb> +1
[02:21] <jamesh> full URL rather than just number?
[02:22] <stub> tests can always insert more data into the database in their setup - sampledata should really only be used for data common across many tests and to get the basic app up and running.
[02:22] <Ubugtu> Malone bug 42 in malone "Bug description listed in task is not the correct description" [Normal,Fix released]  http://launchpad.net/bugs/42
[02:22] <SteveA> matsubara: are you okay with just the number?
[02:22] <matsubara> URL helps, but I'm ok with the numbers and the summary
[02:22] <matsubara> s/numbers/number/
[02:22] <SteveA> matsubara: you can write a script that gives you URLs for "bug NNN" patterns
[02:22] <bradb> The /bugs/... URL is good for this.
[02:23] <SteveA> okay, so number and summary, not URL
[02:23] <matsubara> that's it, I'm done. Thanks guys.
[02:23] <SteveA> matsubara: please send an email to the launchpad list clearly stating the requirements we've agreed
[02:23] <SteveA> thanks matsubara
[02:23] <matsubara> ok
[02:23] <lifeless> SteveA: please file a bug with what you would like on launchpad-development-infrastructure.
[02:23] <SteveA> ok
[02:23] <SteveA>  * Production and staging (stub)
[02:23] <kiko> LDI
[02:23] <stub> Production and staging are both running happily. PostgreSQL security issues are under control - nothing further to add over what has already been mentioned on the mailing list and I'm not going to repeat it in a public channel.
[02:23] <stub> Until dapper release, please let me know via the mailing list about cherry pick requests sooner rather than later, as we have to avoid disrupting the distro team during the final stage of getting Dapper out of the door. Regular rollouts may also become irregular too, or skipped entirely - if we miss anything urgent (eg. shipit updates) we can discuss it with mdz.
[02:24] <lifeless> stub: we have one update that is important, soon, which is the supermirror update for bzr 0.8
[02:24] <kiko> stub, we're supposed to roll out the shipit modifications, but they do not involve database changes.
[02:24] <kiko> (right salgado?)
[02:24] <lifeless> stub: spiv knows where that is at in more detail.
[02:24] <stub> Stuff that doesn't involve db changes is easy
[02:25] <salgado> right
[02:25] <spiv> lifeless, stub: I have a bunch of branches related to that I want to land, but I expect to land them tonight.  After that, I'm happy.
[02:25] <SteveA>  * launchpad bzr development workflow (robert/jamesh)
[02:25] <salgado> it'd be good if we could roll out the new mirror prober (which does include db changes), so we can have nice listings of mirrors when dapper is released
[02:25] <SteveA> i don't remember what this is about.  lifeless, jamesh ?
[02:26] <lifeless> you asked for a documented best practice on setup and process for lp development
[02:26] <kiko> salgado, mirror prober for next week, I guess
[02:26] <lifeless> I spoke with jamesh about it, but did not follow up - sorry.
[02:26] <SteveA> okay.  we can defer this to the next meeting
[02:26] <lifeless> (Its in my TODO list, 3rd from the top)
[02:26] <SteveA> i do want to get everyone on the same page with this
[02:26] <spiv> lifeless: just one thing -- what's the URL for the pqm-submit plugin?
[02:26] <SteveA>  * Design discussion with reviewer by voip (Steve)
[02:27] <spiv> (I'm still hand-crafting my pqm messages, when I really shouldn't be...)
[02:27] <lifeless> spiv: bzr.j-a-meinel.org or some such
[02:27] <SteveA> i propose that before starting work on a feature, the person who will develop the feature arranges a voip call with a reviewer
[02:27] <SteveA> to discuss the design approach
[02:27] <jamesh> spiv: there are some details on setting it up on the WorkingWithSharedRepositories page
[02:27] <lifeless> spiv: see james's repository-usage wiki page
[02:27] <spiv> jamesh: thanks
[02:27] <jamesh> spiv: should answer your questions even if you aren't using shared repos yet
[02:27] <SteveA> are reviewers happy to have such conversations?
[02:27] <lifeless> talking with a reviewer about the proposed approach should give you a design review before code is done
[02:28] <mpt> SteveA, does that apply only to those features that aren't covered by specs with Implementation sections?
[02:28] <lifeless> SteveA: yes we are, we talked this over last review meeting.
[02:28] <SteveA> mpt: no
[02:28] <SteveA> lifeless: thanks
[02:28] <spiv> I am, although I fear I won't be available at the right times for most other developers.
[02:28] <spiv> (due to timezones)
[02:28] <jamesh> same here
[02:29] <SteveA> why not bradb ?
[02:29] <bradb> Reviewers will become bottlenecks.
[02:29] <SteveA> are you criticising my choice of necktie?
[02:30] <SteveA> like with code-reviews, i'd like us to try this out
[02:30] <bradb> It's already hard to find their time for a review. Finding their time for a voip call will be equally challenging, I imagine, and add more process than benefit, IMHO.
[02:30] <SteveA> thanks for the naysaying, brad.  let's suck it and see.
[02:30] <bradb> ok
[02:30] <kiko> bradb, well, there is a lot of benefit in discussing design beforehand
[02:30] <bradb> kiko: I agree 100%. I just don't think it should be required to discuss with a code reviewer.
[02:30] <kiko> it should be more or less high-level -- i.e. this class does this part, this does this, etc.
[02:30] <stub> This will move discussions off the mailing list
[02:31] <jamesh> it can potentially reduce the time to review the code after it is done
[02:31] <kiko> bradb, well, who are you going to discuss it with?
[02:31] <bradb> kiko: you, mpt, etc.
[02:31] <jamesh> if it helps avoid issues that would come up during review
[02:31] <bradb> maybe SteveA or BjornT for zopish things
[02:31] <bradb> various other people as appropriatae
[02:31] <mpt> Maybe there's a disconnect here over what "design" means
[02:31] <spiv> bradb: three out of four of those people are reviewers ;)
[02:32] <SteveA> i have had a positive experience discussing designs and implementation approaches pre-implementation for rosetta, previously
[02:32] <SteveA> i believe carlos and daf shared the positive experience
[02:32] <SteveA> and it generally cut time off the implementation
[02:32] <bradb> I'm not arguing against design discussion, of course.
[02:32] <carlos> SteveA: right, but I share the concerns bradb has
[02:32] <bradb> Design discussion is important and informative.
[02:32] <carlos> SteveA: If we have it as a rule
[02:33] <carlos> the overload of our reviewers will be too high
[02:33] <SteveA> i think an attempt should be made to arrange such a call
[02:33] <SteveA> if it isn't possible, that's fine
[02:33] <cprov> SteveA: I had experiences with kiko in Soyuz as well
[02:33] <cprov> good experiences
[02:33] <SteveA> but i want to make it the coder's responsibility to attempt to arrange such a call
[02:33] <kiko> so bradb, to help, you can always consider me for a phone call
[02:33] <SteveA> and report to the list the success or failure of having such a call
[02:33] <lifeless> theres a lot of concern here about reviewer load
[02:33] <kiko> I am in your timezone and you can either bother me on IRC or on the phone, no problem
[02:33] <SteveA> then we'll be able to see how practical it is
[02:33] <mpt> So, what is the relationship between these calls and the Implementation section of the relevant spec?
[02:34] <SteveA> if reviewers say "no, too busy" so be it
[02:34] <mpt> Will they be more detailed? More up to date?
[02:34] <SteveA> mpt: it's a good question.  let's see how the calls pan out.
[02:34] <lifeless> I'd like to note that the review team is coping just fine with load right now, and we are short 3 reviewers - steve, kiko & salgado are all very busy
[02:34] <bradb> kiko: that would help
[02:34] <bradb> if we can move on after a "no, too busy", that's a bit better too :)
[02:34] <SteveA> okay, we've had a lot of good points raised here.
[02:34] <lifeless> a 15 minute phone call before a branch is started will (IME) save far more than 15 minutes at the end of the branch
[02:34] <SteveA> thanks everyone for that
[02:35] <SteveA> here's what we'll do:
[02:35] <lifeless> so the reviewers will actually become *less loaded*, not more.
[02:35] <SteveA>  - before starting on a feature, the coder responsible will contact a suitable reviewer and ask for a pre-implementation call
[02:35] <cprov> lifeless: good point ;)
[02:35] <SteveA>  - the reviewer may reject, or may pass to another reviewer, or accept
[02:36] <SteveA>  - the coder responsible must report to the launchpad list if the call actually happens or not
[02:36] <SteveA>  - the reviewer should summarize the call (in a paragraph only perhaps) to the reviewers list after the call
[02:36] <SteveA> let's try this out for a few weeks, and see what happens
[02:37] <SteveA> please keep up to date with sending the emails.  it's the only way we'll be able to judge how the system is working.
[02:37] <lifeless> can I ask for the reviewer summary to include the call length.
[02:37] <SteveA> you can
[02:37] <carlos> SteveA: should it affects bug fixing too?
[02:37] <SteveA> lifeless: would you be willing to write this up on the wiki?
[02:37] <lifeless> I want to understand the impact on the reviewers of this. So I'm also going to ask that reviewers note how long a branch review takes from now on too.
[02:37] <SteveA> carlos: for a small obvious bug, no.  for something tougher, or with questions, sure, do.
[02:37] <bradb> SteveA: you mean we should send emails like "I tried to arrange a call with spiv, but he was busy. kthxbye."?
[02:37] <carlos> ok
[02:37] <lifeless> reviewers - does that sound ok ?
[02:38] <SteveA> bradb: "and he said he was too busy" sure.
[02:38] <lifeless> SteveA: yes, make an action for me, I'll be happy do to the writeup
[02:38] <SteveA> okay
[02:38] <SteveA> MeetingAction: lifeless to write up pre-implementation voip reviews policy
[02:38] <SteveA> we gotta move it on
[02:38] <SteveA>  * Discuss a solution for the Retry exceptions (matsubara, kiko)
[02:38] <SteveA> has this already been addressed?
[02:39] <matsubara> I think so.
[02:39] <SteveA> okay, thanks
[02:39] <matsubara> unless kiko wants to add something else
[02:39] <SteveA>  * Outstanding sysadmin requests
[02:39] <SteveA> (i forgot from earlier)
[02:39] <SteveA> spiv: i still have that issue outstanding from you
[02:39] <malcc> Yeah I've got one, one sec
[02:39] <SteveA> and i need to talk with elmo about it, as there are some firewalling policy issues to be solved, apparently
[02:39] <kiko> not really matsubara
[02:39] <spiv> SteveA: yep.  I presume the impending dapper release is eating the admins lives atm...
[02:40] <SteveA> it's keeping elmo busy
[02:40] <spiv> SteveA: In the short term, lifeless has provided me a tarball of the logs to date.
[02:40] <malcc> rt #9117, request for access to accounts on drescher cprov tells me I need
[02:40] <SteveA> ah, okay
[02:40] <SteveA> spiv: so i won't push it this week
[02:40] <spiv> SteveA: so it's not urgent atm.
[02:40] <SteveA> malcc: when do you need these?
[02:40] <malcc> SteveA: As soon as possible, so I can start helping to trace live issues
[02:41] <SteveA> please always try to include an estimated due date in RT reports, by the way.  it helps me and sysadmins plan things
[02:41] <SteveA> malcc: okay, noted.  thanks.
[02:41] <SteveA>  * Keep, Bag, Change
[02:41] <SteveA> with a countdown
[02:41] <SteveA> 6
[02:41] <SteveA> 5
[02:41] <mpt> CHANGE: Each week, make the Oops report the last agenda item. Immediately afterward, use whatever time remains to crack the whip on the oldest Critical Launchpad bugs. Crashes are not the only awful failures Launchpad can have; arguably they're less bad than bugs where people think the failure is their fault.
[02:41] <stub> KEEP: zope.testbrowser. Pagetest testing a cookie auth edge case worked first time - I didn't believe it was actually being run.
[02:41] <SteveA> 4
[02:41] <SteveA> 3
[02:41] <mpt> KEEP: stub. He's doing an awesome job.
[02:41] <malcc> stub++, testbrowser rocks
[02:42] <SteveA> 2
[02:42] <salgado> new bzr!
[02:42] <SteveA> 1
[02:42] <spiv> KEEP: matsubara's error report summaries/bug triaging.
[02:42] <salgado> KEEP ^
[02:42] <bradb> indeed
[02:42] <SteveA> ...
[02:42] <SteveA> 0.5
[02:42] <SteveA> PI
[02:42] <matsubara> salgado++
[02:42] <sivang> heh
[02:42] <SteveA> 2
[02:42] <sivang> (re PI)
[02:42] <SteveA> 1
[02:42] <lifeless> sqrt(-1)
[02:42] <SteveA> 0
[02:42] <SteveA> okay done
[02:42] <SteveA> three sentences please
[02:42] <SteveA> post them now
[02:42] <lifeless> DONE: make bzr add take 1/5 the previous time, make bzr commit 10% faster, improve benchmarking facilities to allow lsprofile output of individual portions.
[02:42] <mpt> DONE: MaloneSimplifications, ShipIt fixes, CSS fixes, administrivia
[02:42] <mpt> TODO: DescriptionMarkup + LaunchpadLoginService specs, bugfixes
[02:42] <mpt> BLOCKED: no
[02:42] <lifeless> TODO: WORM proof of concept with martin, make commit faster, study hg for meeting.
[02:42] <malcc> DONE: Learnt more about Soyuz, sprinted with Celso.
[02:42] <malcc> TODO: Finish sprint, fix Soyuz.
[02:42] <malcc> BLOCKED: No
[02:43] <matsubara> DONE: fixed +bugcontact broken link, distro mirror validation, oops report
[02:43] <lifeless> BLOCKED: Nada
[02:43] <matsubara> analysis;
[02:43] <matsubara> TODO: fix oops bugs and more triage;
[02:43] <matsubara> BLOCKED: no
[02:43] <kiko> DONE: interviews, performance patches, many reviews and design discussions
[02:43] <carlos> DONE: Merged and fixed mark's potemplate priority branch, discussion about potemplate RSS, migration to knits, POMsgSetPage UI discussion, Changes to the batching code, Fixed .pot exports, prepared Rosetta and Dapper announcement and a bunch of translation domains fixed to get full translations from Rosetta
[02:43] <carlos> TODO: Finish Karma testing, Fix all test for POMsgSetPage, add more filtering options to the translation import queue (bug #40550), Add a debug page to see how Rosetta behaves with different Browser language selections or IP address that we use to select some content statistics
[02:43] <carlos> BLOCKED: no
[02:43] <Ubugtu> Malone bug 40550 in rosetta "Further filtering options for the Queue" [Normal,Unconfirmed]  http://launchpad.net/bugs/40550
[02:43] <BjornT> DONE: bug fixes. landed a few branches. reviews.
[02:43] <BjornT> TODO: make products have bugtrackers. huge comments -> attachments.
[02:43] <BjornT> reviews. have vacation.
[02:43] <BjornT> BLOCKED: no
[02:43] <spiv> DONE: reviews, got bzr 0.8 merged into rocketfuel AT LAST, ubuntu wiki stuff
[02:43] <spiv> TODO: merge various branches unblocked by bzr 0.8 merge, retry info (bug 31479), research bug 33223
[02:43] <spiv> BLOCKED: no.
[02:43] <salgado> DONE: improvements to the new shipit (including the new custom request page) and finished the mirror prober for release mirrors;
[02:43] <salgado> TODO: land the changes to the mirror prober and the new custom request page for shipit
[02:43] <salgado> BLOCKED: no
[02:43] <Ubugtu> Malone bug 31479 in launchpad "Retry exceptions should include information about the original query" [Critical,Confirmed]  http://launchpad.net/bugs/31479
[02:43] <cprov> DONE: soyuz sprint with malcc, fix on publisher and upload land (malcc tour)
[02:43] <cprov> TODO: reduce the publication turnaround, redesign upload land
[02:43] <cprov> BLOCKED: None
[02:43] <jamesh> DONE: pending-review updates, scheduler work, code reviews
[02:43] <Ubugtu> Malone bug 33223 in launchpad-bazaar "SFTP server should give human-friendly errors for name restrictions" [Normal,Confirmed]  http://launchpad.net/bugs/33223
[02:43] <jamesh> TODO: get scheduler polished and ready to use, launchpad-bazaar stuff as discussed with ddaa, code reviews
[02:43] <jamesh> BLOCKED: no
[02:43] <bradb> DONE: Put implicit subs in review. Long weekend. Fixed a few OOPS and other bugs. Started on release bug management and xmlrpc.
[02:43] <bradb> TODO: Release bug management and xmlrpc. Fix various high priority bugs.
[02:43] <bradb> BLOCKED: No.
[02:43] <kiko> TODO: unload patches in my tree into PQM dammit, review and assist anyone else needing that
[02:43] <SteveA> DONE: various flavours of management stuff, code reviews, phone calls
[02:43] <SteveA> TODO: menus menus menus
[02:43] <SteveA> BLOCKED: my time and focus on code
[02:43] <stub> DONE: Odds and sods.
[02:43] <stub> TODO: Session updates, searching updates
[02:43] <stub> BLOCKED: lifeless to land SQLObject/launchpad fix to rocketfuel
[02:43] <lifeless> stub: thats done
[02:44] <stub> lifeless: ta
[02:44] <stub> BLOCKED: Nope
[02:44] <SteveA> i see no further blockers to be dealt with
[02:44] <kiko> BLOCKED: jamesh still hasn't gotten us a weekly OOPS report, SteveA needs to confirm carlos' travel suggestion
[02:44] <SteveA> thanks kiko
[02:44] <SteveA> jamesh: ?
[02:44] <kiko> I had others but I lost them
[02:45] <stub> BAG: This virus I've come down with :/
[02:45] <jamesh> kiko: gar.  I'll get a manual OOPS report ready for this week and make sure the cron job running for next week
[02:45] <SteveA> MEETING ENDS
[02:45] <SteveA> thanks for your attention everyone
[02:45] <jordi> doh
[02:45] <kiko> jamesh, I thought it was just a matter of running the cronjob with a set of directories instead of a single one?
[02:45] <jordi> Just in time for tthe MEETING ENDS token
[02:45] <jordi> sorry  guys, hectic stuff at work
[02:46] <jordi> SteveA: want my details my msg?
[02:46] <lifeless> bradb: what sort of trouble are you ahving finding reviewers ?
[02:46] <lifeless> bradb: I see one branch of yours in needs-review, which is one day old
[02:46] <bradb> lifeless: Small sample size. :)
[02:47] <bradb> The average review response time for me is about a week.
[02:47] <lifeless> bradb: not really. you have a 15 day old branch in merge-conditional, and no branches in w-i-p
[02:47] <SteveA> oh, i didn't mention w-i-p
[02:47] <SteveA> i'll have to mention that next week
[02:47] <jamesh> kiko: yeah.  Just get it to run the right date commands to work out which directories to scan
[02:47] <lifeless> bradb: We haven't reached a week for any reviews for about 2 weeks.
[02:47] <mpt> Can someone explain to me the point of w-i-p?
[02:47] <mpt> oh, ok, next week
[02:48] <lifeless> bradb: ever since kiko cleaned up cprovs branches in fact.
[02:48] <kiko> lifeless, that's just because I suck, generally reviewers have been timely enough
[02:48] <stub> Oh - I lied. Staging authentication is buggered. I'm landing a fix now. If you are logged in, don't log out until I get to update it.
[02:48] <lifeless> we are aiming for 48 hour turnaround on all reviews at the moment
[02:49] <lifeless> and with very few exceptions we're reaching that
[02:49] <lifeless> (not counting weekends)
[02:49] <kiko> bradb, and instareviews you have asked have been done, hopefully?
[02:49] <SteveA> mpt: i updated the MeetingAgenda page.  i want to move the agenda and meeting summaries to help.launchpad.net
[02:49] <bradb> kiko: yeah, instareviews have been good lately
[02:49] <kiko> bradb, so STOP COMPLAINING :-P
[02:49] <BjornT> lifeless: please reassign carlos' branch, i won't have time to review it before next Thursday.
[02:50] <lifeless> BjornT: ok
[02:50] <mpt> SteveA, not that I think help.launchpad.net should exist in the first place, but why would meeting agendas be on it?
[02:50] <kiko> mpt, it's out public wiki.
[02:50] <kiko> our, gah
[02:50] <SteveA> kiko, mpt: sometime during the next 30 mins i'd like us to discuss some usability questions about the new filebug page
[02:50] <lifeless> BjornT: you have time for brads though ?
[02:51] <mpt> Next ten minutes, please, I have a breakfast appointment
[02:51] <bradb> I think reviewer response time is /improving/ at any rate. I'm guessing the average response time is coming into focus around 3-4 days now.
[02:51] <SteveA> kiko, mpt: this can wait until tomorrow, if preferred
[02:51] <kiko> SteveA, uhhh, "new filebug page"?
[02:51] <SteveA> kiko, mpt: but i *do* want us to discuss it this week.  before a rollout.
[02:51] <mpt> sure
[02:51] <kiko> I strongly recommend any "new filebug page" is presented to distro users before it has a chance of affecting anybody!
[02:51] <bradb> LAND IT
[02:52] <SteveA> well, i'm in favour of rolling it back, actually
[02:52] <BjornT> lifeless: yeah, i'll do bradb's and mpt's today.
[02:52] <SteveA> but, that's for the discussion
[02:52] <kiko> +1 for rolling back any change that doesn't have distro team approval
[02:52] <lifeless> thanks BjornT
[02:52] <lifeless> jamesh: I'm giving you carlos branch
[02:53] <carlos> it shouldn't be too difficult
[02:53] <carlos> it's really small
[02:53] <lifeless> carlos: instareview for you - not enough tests
[02:54] <lifeless> carlos: if you look here - https://chinstrap.ubuntu.com/~jamesh/pending-reviews/carlos/launchpad/bug-46459/full-diff
[02:54] <lifeless> you can see there are 4 lines of test changes
[02:54] <lifeless> and 375 lines of non test changes.
[02:55] <lifeless> this ratio suggests that you have added 375 lines of untested code :(
[02:55] <lifeless> carlos: do you think its well tested ? [I may be missing something]
[02:56] <carlos> lifeless: 4 lines of test changes?
[02:56] <lifeless> lib/canonical/launchpad/ftests/test_system_documentation.py |    4
[02:56] <lifeless>
[02:56] <lifeless> oh, I missed
[02:56] <lifeless> lib/canonical/launchpad/doc/po_export_queue.txt             |   43 +++
[02:56] <bradb> i think 3/4's of my implicit subs additions were tests :)
[02:56] <lifeless> but still, 43:330 is a fairly low ratio.
[02:57] <carlos> lifeless: anyway, I think I could add more tests
[02:57] <lifeless> carlos: looking at your test, it seems to soley test the pass condition
[02:58] <carlos> the pass condition?
[02:59] <carlos> lifeless: I'm not sure that rate would be a good way to see if it's well tested this branch, I'm adding a new view and thus new interfaces and many attributes
[03:00] <carlos> I agree that I can improve the tests, but I hope you don't expect that I get a 1:1 rate...
[03:00] <lifeless> carlos: well, I'm off to bed. I expect jamesh' review will say something similar.
[03:01] <lifeless> carlos: there are tests that test the 'normal' behaviour of a routine
[03:01] <carlos> jamesh: let me do some changes after lunch and leave the review until tomorrow to improve the tests so your review would be more easy
[03:01] <lifeless> and there are tests that test error conditions.
[03:02] <carlos> lifeless: oh, I see what you mean
[03:02] <lifeless> code that has few or no tests of either sort, is often prone to undetected defects in that area.
[03:02] <carlos> right
[03:02] <lifeless> gnight all
[03:03] <carlos> lifeless: night and thanks
[03:03] <spiv> carlos: A rough guideline can be to use the --coverage option of test.py, and see if there's any lines of code you've added that aren't executed.
[03:03] <spiv> s/added/added or changed/
[03:04] <carlos> spiv: do we have such feature??
[03:04] <carlos> wow
[03:04] <carlos> spiv: how does it know what was added or changed?
[03:04] <spiv> carlos: it doesn't, but you should :P
[03:05] <carlos> oh, I see
[03:05] <carlos> that would help me also to improve our current tests, right?
[03:05] <spiv> (but if it did, that would be sweet!)
[03:05] <spiv> Yep.
[03:09] <spiv> carlos: I haven't actually played with --coverage much, so I'm not certain it works properly with code invoked from doctests and other odd stuff.  I expect it's actually fine, but let me know if you have any questions about the results it generates.
[03:09] <carlos> spiv: sure. Thank you
[03:12] <carlos> later
[03:21] <SteveA> lifeless: your recent email about knits for SM landing shortly...
[03:21] <SteveA> lifeless: does that mean the issues with bzr test failures in sourcecode/ are fixed?
[03:26] <spiv> SteveA: Yes, that landed a few hours ago.
[03:26] <SteveA> way cool
[03:26] <spiv> Yeah!
[03:26] <SteveA> high five to bzr-related-to-launchpad folks
[03:28] <spiv> I've done a trivial merge to gnarly, doing a trivial merge to pybaz, probably will need a trivial merge to cscvs, then I can re-enable the sourcecode/* checks!
[03:35] <stub> copy_to_zlog is set to false on the production systems, but the launchpad logs are full of noise
[03:58] <cprov> carlos: ping, have a look at bug 46559
[04:13] <salgado> carlos, cprov, is any of you guys dogfood at the moment?
[04:15] <cprov> salgado: yes
[04:18] <cprov> salgado: I'd say 'depends', what do you need ?  currently I'm publishing stuff in dogfood, I've updated the DB to a 18th May copy of production ...
[04:18] <salgado> cprov, will you be using it the whole day or can I kill it for a code/db update at some point?
[04:19] <salgado> oh, great. that's the one I'm restoring
[04:19] <salgado> so, that means I only need a code update
[04:19] <cprov> salgado: ehe
[04:19] <cprov> salgado: I've kept you tree in place
[04:20] <cprov> salgado: I mean, "your" tree, sorry
[04:20] <salgado> which one is mine?
[04:20] <salgado> hmmm. actually there's a db patch that I'd need to apply
[04:22] <cprov> salgado: shipit-for-dapper, maybe ?
[04:23] <cprov> salgado: you can apply it in the current launchpad_dogfood, might be harmless to the soyuz stuff I'm using, right ?
[04:24] <salgado> it's another branch, actually
[04:28] <carlos> cprov: done and answered
[04:35] <salgado> cprov, yes, it should be harmless; it's just a new table
[04:37] <cprov> carlos: thank you
[04:37] <carlos> np
[04:37] <cprov> salgado: go for it then
[04:47] <spiv> Ah crud pybaz fails with rocketfuel's twisted.
[04:47] <spiv> fails and *hangs*!
[04:47] <spiv> stub, lifeless: pqm seems to be hung :(
[04:56] <spiv> lifeless/stub: please kill the current pqm merge that's hung.  The next merge in the queue fixes the problem.
[04:56] <spiv> Does anyone who's actually awake have access to balleny?
[04:57] <spiv> elmo/Znarl: the current PQM job is hung, could you kill it please?
[04:59] <Yannig> Great: tomorrow, Occitan to-do translations will go under 99 % :D
[04:59] <malcc> Yannig: Nearly done then :)
[04:59] <Yannig> "Nearly", yes :D
[05:00] <Yannig> I just have to recruit some help :p
[05:00] <elmo> stub: done
[05:00] <elmo> spiv even
[05:00] <spiv> elmo: thanks!
[05:00] <Yannig> (for productivity and above all quality...)
[05:00] <spiv> lifeless, stub: elmo sorted me out.
[05:02] <carlos> Yannig: ;-)
[05:05] <lucasvo> is rosetta something like a gettext gui?
[05:10] <mdke> lucasvo: it is like an online poedit/gtranslator/kbabel
[05:10] <mdke> except collaborative
[05:12] <lucasvo> mdke: and how can one add the pofiles?
[05:13] <mdke> lucasvo: they are there already. You add to them by editing online. It is also possible to download one, translate it offline, and upload it
[05:15] <lucasvo> mdke: I don't want to translate
[05:15] <lucasvo> I want to register my project there so other peope can translate
[05:17] <mdke> lucasvo: https://wiki.launchpad.net/RosettaNewImportPolicy
[05:18] <mdke> then you use the "Request Translation Upload" button
[05:20] <lucasvo> hm, so rosetta isn't meant for non ubuntu projects?
[05:21] <mdke> lucasvo: certainly it is
[05:21] <lucasvo> it looks quite complicated
[05:22] <mdke> lucasvo: no, it's easy. You just read that page and then if you are the upstream project maintainer, you can request to use rosetta with "Request Translation Upload"
[05:22] <lucasvo> where is the link?
[05:23] <mdke> lucasvo: https://launchpad.net/products/yourproduct/yourrelease/+translations-upload
[05:28] <lucasvo> oh crap
[05:28] <lucasvo> so I need to register a product and not a project?
[05:29] <lucasvo> what is the difference?
[05:30] <mdke> that is a question that I am not able to help with
[05:30] <mdke> I don't understand it either
[05:30] <spiv> lucasvo: roughly, a project is a group of related products.
[05:31] <lucasvo> crap
[05:31] <lucasvo> can I delete a project?
[05:31] <spiv> lucasvo: that needs an admin, unfortunately :(
[05:31] <spiv> lucasvo: file a support request or mail the launchpad-users list.
[05:31] <mdke> heya spiv
[05:32] <spiv> mdke: hey :)
[05:32] <lucasvo> anybody here who can do it?
[05:32] <mdke> spiv: get my email about the page cache thing? Is that trivial to include?
[05:32] <spiv> mdke: I did. It's trivial to fix up after the script runs.
[05:33] <mdke> spiv: ah, that won't go in the script itself?
[05:34] <spiv> So I think we may as well leave the script alone (seeing as I managed to make one that worked first time for once ;), and get the admins to run a simple find + rm after it runs.
[05:34] <mdke> ok, whatever you prefer
[05:34] <lucasvo> can projects and products have the same nam?
[05:34] <spiv> (or however it was fixed last time)
[05:34] <lucasvo> *name
[05:34] <mdke> spiv: last time?
[05:34] <spiv> lucasvo: yeah, I think so.
[05:35] <mdke> spiv: oh, cachecleaner.py might do the trick
[05:35] <mdke> :)
[05:35] <spiv> oh, if it's already written, even better :)
[05:35] <mdke> just saw it now
[05:39] <spiv> Ok, pybaz fix merged ok, let's see how this merge goes this time...
[06:07] <bradb> mpool: What LP xmlrpc doc did you read to write the register-branch plugin? (Assuming you were the one that wrote it.)
[06:19] <BjornT> bradb: http://bazaar-vcs.org/Specs/BranchRegistrationTool
[06:33] <spiv> YES
[06:33] <spiv> "make check_merge" is back at full strength.
[06:50] <mantiena> hi all
[06:51] <mantiena> SteveA, labas
[07:11] <bradb> BjornT: ah, thanks
[07:13] <mantiena> SteveA, alive ?
[07:33] <SteveA> hi mantiena.  i'm in a phone call
[07:58] <SteveA> hi mantiena
[07:58] <SteveA> i'm about to finish for the day
[07:58] <SteveA> what's up?
[08:15] <kiko> SteveA, ping?
[09:01] <_chaOS_> hello room
[09:02] <_chaOS_> does ubuntu base installation support rpm packages?
[09:02] <_chaOS_> Or what package management program does ubuntu use??
[09:02] <_chaOS_> any one plz?
[09:05] <mdke> _chaOS_: you need #ubuntu
[09:08] <_chaOS_> thank you mdke.
[10:03] <bradb> BjornT: I responded to your review. Do you have time to check it out?
[10:09] <BjornT> bradb: yeah, i might have time to take a look at it soon.
[10:11] <bradb> cool, thanks. /me heads out to pick up a fixed laptop.
[10:16] <mantiena> SteveA, I have few questions about [planned]  rosetta features :)
[10:25] <SteveA> mantiena: you can try the rosetta mailing list
[10:25] <SteveA> then if others have the same questions, everyone can read the discussion and answers
[10:42] <kiko> yay bradb
[10:42] <kiko> good work
[11:02] <mantiena> SteveA, but I more like talk with you directly ?
[11:04] <mantiena> ;)
[11:04] <mdke> I'd like to see more Klingon translations in Rosetta
[11:05] <mdke> jordi: so, if rosetta now prioritises, do we get to compete to get our templates promoted up the list? Do you take bribes?
[11:06] <jordi> mdke: I do!
[11:06] <jordi> no, I actualyl have a grand plan
[11:06] <jordi> I plan to make a wiki page, with a table awith the full list
[11:06] <jordi> so people can input and we can fine-grain this
[11:06] <mdke> cool
[11:06] <jordi> But, when people do a change, it must be explained in the changelog
[11:07] <mdke> changelog?
[11:07] <jordi> a rationale and so
[11:07] <jordi> in the wiki page changes thingy
[11:07] <mdke> which changelog?
[11:07] <mdke> oh right
[11:08] <jordi> and every now and then we can diff last apply against current and apply the changes to rosetta
[11:36] <mantiena> guys, it's normal when my .po files aren't imported in rosetta more than 24 hours ?
[11:37] <jordi> mantiena: it could be. Which po?
[11:37] <jordi> mantiena: Openoffice is being imported, and that takes long
[11:42] <mantiena> jordi, several *-lt.po files
[11:45] <mantiena> for example replaced-gtk-lt.po and eel-lt.po. I exported several files about 26-27 hours ago, fixed some strings and imported again into rosetta after ~2 hours, but they still aren't imported into rosetta and I didn't get email from rosetta about successful import :(
[11:46] <jordi> https://launchpad.net/rosetta/imports/+index?status=APPROVED&type=po&start=700&batch=75
[11:46] <jordi> they are approved, but behind OpenOffice in the queue
[11:48] <kiko> meaning they will be imported AFTER XMAS!
[11:50] <mantiena> :(((((
[11:50] <lifeless> moining
[12:04] <mantiena> jordi, maybe you know aproximatly how much time openoffice will be imported ? I need to fix some more translations before ubuntu dapper, but langpack translation deadline is May 25 ...
[12:05] <zyga> jordi: interesting issue
[12:09] <jordi> zyga?
[12:09] <jordi> mantiena: takes 2 days or so, according to carlos
[12:10] <jordi> I'm not sure, I can't tell you about the dates, but you maybe safe, langpacks will be updated every now and then
[12:10] <jordi> monthly at least
[12:10] <carlos> mantiena: it has been running for a whole day already
[12:10] <jordi> so even if you miss the dapper debut, they'll appear in the next
[12:10] <carlos> I guess on Saturday, it will be done and all pending entries will be imported
[12:10] <jordi> I also have files around the place :)
[12:10] <mdke> mantiena: if the deadline is 25th, that means that it is passed. However, carlos said in his email today that language packs will be regenerated on sunday
[12:10] <zyga> jordi: 99% vs 100%
[12:10] <jordi> zyga: ah yeah
[12:10] <carlos> mdke: yeah, the deadline was moved
[12:10] <jordi> carlos: saw that bug I filed?
[12:11] <jordi> zyga: I think just using a brighter colour would do
[12:11] <carlos> jordi: which one ?
[12:11] <zyga> jordi: I attached a comment
[12:11] <jordi> but I'm sure there'll be some kind of problem with visually impaired people
[12:11] <zyga> it's a pretty simple solution
[12:11] <zyga> jordi: use stripes
[12:11] <jordi> https://launchpad.net/products/rosetta/+bug/46653
[12:11] <Ubugtu> Malone bug 46653 in rosetta "100% vs 99% translations done for a language team" [Normal,Unconfirmed]
[12:12] <zyga> 100% is trivially distinguished when it is displayed with stripes :)
[12:12] <zyga> (waves, ubuntu logos or whatever - any non solid color with high constrast pattern will do)
[12:12] <carlos> mantiena: but if you import them now, your import will be done earlier
[12:12] <jordi> that's true
[12:13] <mantiena> carlos, thanks, so, if I do some fixes in lt.po files this morning (after ~7 hours), will these fixes go in sunday's langpacks ?
[12:13] <jordi> mantiena: yeah, keep them coming, they'll be in the line
[12:13] <carlos> I guess, yes
[12:13] <jordi> mantiena: we hope
[12:13] <carlos> mantiena: I don't think OO.org will be still around on Sunday...
[12:14] <mantiena> fine, then I can go sleep now instead of fixing ;)
[12:14] <carlos> mdke, jordi: You should talk with mpt about that bug
[12:14] <jordi> yah
[12:14] <jordi> should I subscribe him?
[12:15] <carlos> mantiena: that's only true if you do it uploading .po files
[12:15] <mdke> me?
[12:15] <jordi> zyga :)
[12:15] <carlos> if you use the translation form, your translations will be there _now_
[12:15] <carlos> jordi: oh... right...
[12:15] <carlos> mdke: sorry ;-)
[12:15] <carlos> It's a bit late here...
[12:16] <jordi> carlos: another feature for the future is, related to that bug I filed, is that stuff submitted by a human goes to the top of the queue by dfefault
[12:16] <jordi> so it can bypass edgy uploads etc
[12:17] <zyga> carlos: is there any plan to add ubuntu icon to templates from packages in the main archive?
[12:17] <carlos> zyga: well... atm Dapper only has packages in main (for translations)
[12:18] <carlos> we didn't import universe
[12:18] <zyga> oh
[12:18] <zyga> I didn't know
[12:18] <carlos> and Edgy will have a feature (or at least we will try to have it in time) to use something like language packs for universe
[12:19] <zyga> hmm :)
[12:19] <zyga> souns familiar
[12:19] <zyga> I had similar ideas about a year ago
[12:19] <carlos> zyga: will you go to Paris ?
[12:19] <zyga> carlos: paris?
[12:19] <zyga> next ubuntu conn is in paris?
[12:19] <carlos> the Ubuntu sprint
[12:20] <carlos> yes
[12:20] <zyga> unlikely :/
[12:20] <zyga> when will it happen BTW?
[12:20] <carlos> next month
[12:20] <zyga> then absolutely not :/
[12:20] <zyga> marriage, house, kid on the way :)
[12:20] <zyga> no time atm
[12:20] <carlos> I guess I will write something about it there
[12:20] <carlos> zyga: congratulations!
[12:21] <zyga> I look forward to that :)
[12:21] <zyga> carlos: I had an idea about per-package non-deb package
[12:21] <zyga> per-deb-package-i18n-package-with-small-footprint
[12:23] <carlos> yeah, the main idea is not use .deb packages
[12:24] <zyga> basically a .mo file would do
[12:24] <zyga> that, coupled with a custom namespace
[12:26] <mantiena> carlos, hehe, but how I can search for some words in translations if using web translation tool ?
[12:27] <carlos> mantiena: no way.. sorry :-(
[12:28] <mantiena> carlos, I have idea - are there a way to see not 10, but for example 100 translations in page during translation ?
[12:28] <kiko> heh.
[12:28] <mantiena> then I could use simple text search with firefox browser ;)
[12:29] <kiko> carlos, there is a way, right? :)
[12:29] <carlos> yes
[12:29] <carlos> mantiena: use count=100 as an extra argument in the URL
[12:30] <carlos> mantiena: it will change soon, but should work for you at least one more week
[12:30] <carlos> mantiena: something like +translate?count=100
[12:30] <mantiena> carlos, thanks, for me one day will be enough no need for one week ;)
[12:31] <carlos> mantiena: that option will be there, but with another name, that's all
[12:34] <mantiena> hehe, It's working will not sleep for at least 30 min - new fixing with web translation tool is faster, than downloading file from rosetta, fixing and uploading again ;)
[12:34] <kiko> cool. :)
[12:34] <mantiena> carlos, btw, will rosetta have ability to search/replace in web translation more in future ?
[12:35] <carlos> mantiena: yes, we have a high priority functionality that includes a search feature
[12:37] <carlos> kiko: zyga just remembered me another spec I would need to work next month at Ubuntu submit, the one about language packs like feature for universe
[12:40] <kiko> carlos, sounds like you're going to have a busy 3 days :)
[12:40] <carlos> one spec/day
[12:41] <carlos> I need to talk with pitti to schedule sometime before the meeting to talk about the ways to implement this new spec so we have some previous discussion
[12:42] <carlos> but I think he's not around until next Monday, I will call him on Monday
[12:43] <kiko> yeah, I'd do planning up-front definitely
[12:43] <kiko> so you don't waste time there
[12:43] <carlos> right
[12:43] <carlos> good night!
[12:45] <kiko> carlos, still here?
[12:45] <mantiena> mdke, hehe, sometimes find/replace is very good way for fixing translations, sometimes there are typical errors, which can be fixed automatically
[12:46] <carlos> kiko: yes
[12:46] <kiko> carlos, did the rosetta announcement not hit rosetta-users?
[12:46] <mantiena> good night carlos, it was nice to meet you ;)
[12:46] <mdke> mantiena: but words often occur in different context. I agree for spelling errors it might help
[12:46] <kiko> oh, just found it.
[12:46] <kiko> thanks!
[12:47] <carlos> kiko: ;-)
[12:47] <kiko> sorry!
[12:47] <carlos> mantiena: :-P
[12:47] <carlos> see you tomorrow!
[12:48] <mantiena> mdke, I know about context, I use find/replace very rarely, but tonight most my translation fixes can be done by find/replace and then manual review ;)
[01:25] <lifeless> spiv: ping
[02:04] <lifeless> SteveA: ping
[02:27] <Rounin> Hello, I have a question... With regards to the bounty functionality of launchpad, is it possible to change the amount pledged after a bounty is posted? And if so, how is it done?
[02:37] <Rounin> I was just wondering, because I was thinking of creating a bounty for further development of XIM (namely switching of input methods within programs and without the use of env vars + better stability), but it would require a lot more people than me to pledge money
[02:44] <stub> Rounin: Doesn't look like it. The Bounty system is still fairly primative as we have been concentrating on other areas. It currently needs an admin to change the amount for some reason (looks like it was done deliberately but I don't know the rationale)
[02:45] <Rounin> Ah... That's a shame... I guess there needs to be some sort of centralised control to prevent false pledges, but one would need to be able to increase the sum
[02:47] <lifeless> I believe some work is being done on it at the moment, but not sure when that will land
[02:49] <Rounin> I see... THanks, both of you
[03:07] <marcin_ant> I also would like to add that there is currently no way to control bounties and verify if they are closed or not  etc....
[03:24] <spiv> lifeless: pong
[03:30] <mpt__> Gooooooooooooooooooood afternoon Launchpadders!
[03:37] <lifeless> spiv: reviewed your branch
[03:37] <spiv> lifeless: thanks
[03:40] <spiv> lifeless: So, I have a problem with testing other formats than just the repository.  At the moment (i.e. with the current set of formats bzr 0.8 has), if branch format or bzrdir format changes, then the repo format changes anyway, afaict.
[03:41] <spiv> lifeless: which makes constructing a test to exercise the checks tricky.
[03:41] <lifeless> spiv: if/when we bump bzrdir format, I dont expect we'll bump the branch format again, for instance. Nor the repository format.
[03:41] <spiv> (I actually have an comment I forgot to commit and push stating this in the relevant spot in the code :/ )
[03:41] <lifeless> spiv: factor the test into a function identical_formats()
[03:42] <spiv> Right, I'm sure the situation will change in future.
[03:42] <lifeless> then call identical formats with any object that wont match to test the != branch
[03:42] <lifeless> and call with equal objects in each of the three spots to test the == branch of the test
[03:42] <spiv> Just at the moment that testing repository is effectively enough, but clearly not future-proof.
[03:42] <spiv> Hmm, that's a good idea.
[03:43] <spiv> Thanks!
[03:43] <lifeless> I'd rather we had correct and untested code than incorrect and tested, but I think its easy to do correct and tested.
[04:32] <spiv> lifeless: btw, did you see that check_merge is unbuggered?
[04:39] <spiv> lifeless: Hmm, bzrdir.clone looks like it would do too much with e.g. shared repositories to me.
[04:46] <lifeless> spiv: ah yes.
[04:46] <lifeless> spiv: sprout then is the right one
[04:46] <lifeless> spiv: still preserves format
[04:46] <spiv> Ooh, I'll take a look at that.
[04:48] <spiv> lifeless: you mean bzrdir.sprout not branch.sprout?
[04:49] <lifeless> spiv: yes
[04:51] <spiv> I guess I have to pass in the revision_id.  It takes the exact same arguments as clone...
[04:51] <spiv> Anyway, I need to go to lunch.  Back in a while.
[04:51] <mpt_> stub, did you recently fix bug 43983?
[05:23] <stub> mpt_: I think so, yes
[06:22] <mpt_> spiv / jamesh, ping
[06:22] <jamesh> mpt_: yeah?
[06:24] <mpt__> jamesh, I need to revert a series of three revisions to a branch, but they do not include the most recent revision
[06:24] <mpt__> So I've used bzr diff -r to generate the diff of the changes I made that I want to revert
[06:24] <mpt__> I tried using patch -Ru to apply it, but it looks like patch works only for one file
[06:25] <mpt__> and bzr patch doesn't appear to have an "in reverse" option
[06:25] <jamesh> if you want to revert revs 42..45 for instance, "bzr merge -r 45..41 ." might do it
[06:25] <jamesh> "patch -R -p0 < patchfile" would also work if you've got a diff of the changes you want to revert
[06:26] <mpt__> ok, thanks
[06:26] <mpt__> I can't use bzr merge, because my more recent revision is up for review
[06:26] <jamesh> the first option should handle revs that add/delete/move files too
[06:26] <mpt__> whereas I have rs= for the reversion
[06:27] <jamesh> mpt__: the bzr merge command I gave is a self merge
[06:27] <mpt__> I mean, I could use it, but then I wouldn't be able to submit to PQM, because that would still include the more recent revision that hasn't been reviewed yet
[06:27] <mpt__> so I need to apply the diff in reverse to a fresh branch
[06:39] <mpt> jamesh, sorry to bother you again, but how do I push a new standalone knit branch to chinstrap?
[06:40] <mpt> "bzr push --remember --overwrite sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/mpt/launchpad/2006-05-bug-reporting-form/" returns "bzr: ERROR: No repository present"
[06:40] <mpt> and I'm not using a repository
[06:40] <jamesh> mpt: what was in that location before you ran push?
[06:41] <mpt> jamesh, a copy of /home/warthogs/archives/rocketfuel/launchpad/devel (to minimize rsyncing time)
[06:41] <jamesh> mpt: okay.  /home/warthogs/archives/rocketfuel/launchpad/devel is actually a branch inside a repository
[06:41] <jamesh> the repo being at /home/warthogs/archives/rocketfuel/launchpad
[06:42] <mpt> oh
[06:42] <jamesh> so when you copied it, you missed the repo information
[06:42] <mpt> So is there any fast way to push a standalone branch, or do I just have to upload the whole thing?
[06:42] <jamesh> you could try copying one of your existing knit format branches
[06:43] <jamesh> that should give similar speed to taking a copy of rocketfuel
[06:43] <mpt> ok, ta
[06:46] <jamesh> if you had a shared repo on chinstrap, you'd be getting the speed benefits for initial pushes
[06:46] <jamesh> even if you keep with standalone branches locally
[07:03] <spiv> mpt: don't "cp" the branch from rocketfuel, "bzr branch" it.
[07:07] <mpt> spiv, would that be why PQM just told me "Sender not authorised to commit to branch sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel/"?
[07:07] <spiv> mpt: no, that's because PQM doesn't like the trailing /
[07:08] <mpt> so, my new-branch script should contain
[07:09] <mpt> ssh chinstrap bzr branch /home/warthogs/archives/rocketfuel/launchpad/devel /home/warthogs/archives/mpt/launchpad/$1
[07:09] <spiv> Looks sane.
[07:10] <mpt> and bzr branch gets me out of repository-land
[07:27] <mpt> grrr
[07:28] <mpt> spiv, after using the bzr branch method, and re-pushing, I got the same error from PQM
[07:28] <spiv> mpt: how are you generating the PQM request?
[07:29] <spiv> mpt: the request needs ask to merge to "sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel", with no trailing slash.
[07:30] <mpt> I haven't changed this script in ages
[07:30] <mpt> except for changing .bzr/parent to .bzr/branch/parent
[07:30] <mpt> echo star-merge ${MYURL} $(cat .bzr/branch/parent) | gnome-gpg --clearsign | mail -s "$1" "$2"
[07:30] <mpt> hmmmm
[07:31] <mpt> ah, so parent has a slash in it and shouldn't
[07:32] <spiv> Yeah.  I guess you could replace "$(cat .bzr/branch/parent)" with "$(cat .bzr/branch/parent | sed -e s=/$==)"
[07:33] <spiv> But it'd be nice if the branches in rocketfuel had their parents set to something that PQM accepted...
[07:34] <mpt> I'm using cp -a from my copy of rocketfuel to create new branches
[07:34] <mpt> so I need to write in the .bzr/branch/parent manually
[07:35] <mpt> and I'll put that in the script without a trailing slash
[07:36] <mpt> then it should work :-)
[09:13] <jamesh> spiv: did you manage to get the pqm-submit plugin working?
[09:13] <spiv> jamesh: Haven't tried yet...
[09:33] <SteveA> lifeless: hello
[09:45] <carlos> morning
[09:45] <sivang> morning
[09:57] <spiv> SteveA: you wanted a conference call at about this time?
[09:57] <SteveA> yep
[09:57] <SteveA> jamesh, stub: around?
[09:57] <jamesh> yeah
[09:57] <stub> yup
[09:58] <SteveA> stub: what's your internet connection like?
[09:58] <stub> Fine
[09:58] <SteveA> is it fat?
[09:59] <SteveA> i'm thinking that as you're geographically in the middle, it might work better for you to be the conference convener on skype
[09:59] <fabbione> SteveA: if you need i have spare bw
[10:00] <SteveA> thanks fabbione.  not sure how we'd use it though
[10:00] <fabbione> SteveA: no problem
[10:00] <SteveA> what a shame you can't send bandwidth as an email attachment
[10:00] <fabbione> ehehe
[10:00] <stub> SteveA: Geographically maybe, but I suspect I'm going via Europe or the US to get to AU
[10:01] <SteveA> can you do an mtr to see?
[10:01] <stub> So how do I setup a skype conference call?
[10:01] <spiv> I see a "Tools -> Create conference" option.
[10:01] <SteveA> everyone must be running skype
[10:01] <SteveA> then select all their names
[10:01] <SteveA> then right click or something to create hte conference
[10:01] <SteveA> or do what spiv said
[10:03] <stub> Thailands international bandwidth isn't great, but then again neither is Lithuania's I guess
[10:03] <SteveA> using asterisk in the DC would be better
[10:03] <jamesh> I take it that that's not an option yet?
[10:04] <stub> Yay - workiing without killing esd
[10:05] <stub> jamesh, spiv: I don't have your skype numbers
[10:05] <spiv> stub: "spivvo"
[10:05] <jamesh> stub: jamesh-42
[10:06] <SteveA> everyone should run the echo test first too
[10:06] <jordi> hiya
[10:06] <SteveA> call echo123
[10:06] <stub> Have you changed your number steve? Your icon says you are offline
[10:06] <stub> Oops... green now
[10:07] <spiv> echo test fine here.
[10:09] <stub> Everyone here except da Steve
[10:09] <SteveA> my wired headset is broken
[10:09] <SteveA> i need to get the BT one going...
[10:10] <spiv> SteveA: we'll just talk about you behind your back then ;)
[10:15] <stub> Bored now!
[10:18] <stub> SteveA: Should I courier you a headset over?
[10:18] <SteveA> yes please
[10:21] <SteveA> yay, works
[10:21] <SteveA> how do i join the conference now?
[10:22] <jamesh> did you just kill the conference?
[10:22] <SteveA> now i need to restart skype...
[10:22] <stub> Nope - you dropped
[10:22] <spiv> jamesh: I'm still here.
[10:22] <SteveA> cos it got confused about the sound device
[10:22] <stub> You killed James! You bastard!
[10:25] <fabbione> what's going on with LP???
[10:25] <fabbione> i keep getting 502 Proxy Error
[10:26] <spiv> fabbione: stub's looking at it now...
[10:27] <SteveA> Znarl: pingping
[10:28] <Znarl> SteveA : Pong?
[10:28] <SteveA> hi.  so, it seems that all 4 launchpad app servers have failed
[10:28] <SteveA> probably
[10:28] <SteveA> plan is to kick the ones on gangotri in the arse
[10:28] <SteveA> but leave the other 2 dead for diagnosis
[10:28] <SteveA> that requires some pound config
[10:29] <SteveA> and stu says that needs you to do it
[10:29] <Znarl> SteveA : Understand.
[10:30] <Znarl> same for XMLRPC too?
[10:30] <seb128> hi
[10:30] <seb128> is launchpad known to be broken? ("Proxy Error")?
[10:30] <spiv> seb128: yep, fabbione reported it 5 min ago, we're looking atm
[10:30] <seb128> ok, thank you
[10:31] <SteveA> Znarl: yes please
[10:31] <Znarl> Done.
[10:41] <stub> SteveA: I've diagnosed the problem. The good news is that my planned session updates should fix it. The bad news is I write crappy code in the first place.
[10:42] <stub> SteveA: And you have dropped from the conference again
[10:42] <SteveA> hi
[10:42] <SteveA> yeah, skype dropped
[10:42] <SteveA> but launchpad is still not really working
[10:43] <SteveA> yay launchpad working
[10:44] <stub> SteveA: Sorry - I didn't realize that was an international number and hung up
[10:50] <seb128> grraa
[10:50] <seb128> "OperationalError
[10:50] <seb128> A server error occurred."
[10:50] <seb128> and there is no "previous page" possible
[10:51] <seb128> ah, it applied the change anyway, good
[10:52] <SteveA> are things okay now seb128 ?
[10:53] <seb128> yep, works again, thank you
[10:53] <seb128> and my change got applied when it displayed that OperationalError
[10:53] <SteveA> stub: "blahblahblah welcome to callback service"
[10:53] <seb128> weird but nicer than having to do the change again ;)
[10:53] <stub> SteveA: I'm trying to have a conference call!
[10:54] <SteveA> actually, let me extemporize on #c-m while i call karl
[11:02] <Znarl> gangotri : Launchpad Apps Server [1/2]  down.
[11:03] <Znarl> Oh, ignore that.  Just went clear.
[11:09] <seb128> I get OperationalError pages again
[11:17] <mdke> no worky!
[11:17] <lifeless> SteveA: hi
[11:19] <seb128> k, not point to try working with it, /me goes for some coffee
[11:29] <imbrandon> someone working on the site atm ?
[11:31] <imbrandon> looks like OperationsError every few page loads , and css not loading sometimes ...... etc , i have screen shots and others in #kubuntu-devel experincing same issues
[11:31] <imbrandon> just wondering if someone was aware of the issue
[11:31] <mantiena> Hi all
[11:32] <imbrandon> 'ello
[11:33] <lucasvo> imbrandon: yes they are
[11:34] <imbrandon> ok cool, just wanted to make sure SOMEONE was aware of it ;)
[11:34] <lucasvo> stub: are you still working on fixing LP?
[11:44] <stub> lucasvo: It was fixed last we looked...
[11:44] <lifeless> stub: could it be an out of date appserver?
[11:45] <stub> No code updates for the last few days that I'm aware of
[11:45] <SteveA> maybe a stuck app server with broken db connections
[11:46] <stub> I only have 18 database connections from the appservers and there should be (4*4*2)
[11:46] <stub> 32
[11:47] <stub> Maybe me killing connections and Steve bouncing was done out of sync
[11:47] <lucasvo> stub: atm, the toolbar isn't working
[11:49] <lucasvo> ok, now it's down
[11:50] <stub> Its up again - gangotri restarted cleanly for sure.
[11:50] <SteveA> looks good from here
[11:51] <stub> Znarl, SteveA: Is gandwana being load balanced to at the moment?
[11:51] <stub> I'm going to bounce the launchpads there - nothing more to diagnose as far as I can see (?)
[11:51] <Znarl> No.  gandwana Apps servers are down.  They're removed from pound.
[11:53] <stub> Znarl: You can put gandwana back in the pool now. I've bounced them cleanly and the only reason to leave them out is to slow things down.
[11:54] <Znarl> stub : Done and done for XMLRPC too.
[12:32] <sabdfl> do we measure and report on downtime for LP?
[12:32] <Znarl> sabdfl : Yes, within nagios monitoring system downtime is measured.
[12:33] <`6og> hi all. i have been looking around but haven't found any reference to launchads `xmlrpc` interface. is that open (ie in an ubuntu package) or still closed?
[12:39] <SteveA> kgoetz: we're experimenting with some xmlrpc interfaces, but we haven't released any as a supported service in launchpad yet
[12:40] <kgoetz> SteveA: thanks, i was just curious after seeing some comment referring to it. thanks for that :)
[12:40] <mdke> can anyone merge teams?
[12:41] <SteveA> mdke: interesting question.  stub, what do you think?
[12:41] <mdke> SteveA: it would be nice to get bug #29177 fixed
[12:41] <Ubugtu> Malone bug 29177 in launchpad "Allow merging of teams (and specifically merge ubuntu-doc and ubuntu-doc-lists)" [Major,Confirmed]  http://launchpad.net/bugs/29177
[12:41] <stub> I'm not sure if the admin screen lets us do it. Technically, there would be nothing wrong with using the existing people merge code to merge teams.
[12:42] <SteveA> stub: would it merge team membership records too?
[12:42] <mantiena> SteveA, labas
[12:42] <SteveA> sveikas mantiena
[12:42] <stub> SteveA: That would be why it isn't enabled. It would need to be a little smarter.
[12:43] <SteveA> mantiena: actually, i have no idea how to say that in lithuanian properly.  you have a female irc nick
[12:43] <mantiena> SteveA, ;)
[12:43] <SteveA> sveika mantiena :-p
[12:44] <mdke> SteveA: for that particular bug team membership records don't matter, ubuntu-doc-lists was just created when bugs were imported from bugzilla, we don't need it
[12:44] <mantiena> SteveA, you also have a female nick, if looking from Lithuanian side ;)
[12:44] <SteveA> it's just a poorly spelled vocative: styvai
[12:46] <mantiena> so, styvai, could you tell me, if we (Lithuanian GNOME/KDE translation teams) could use rosetta as main translation/colaboration tool for translating upstream (not ubuntu's) KDE/GNOME ?
[12:47] <SteveA> i don't see why not.  the main issue is if you have someone who will regularly take the upstream translations from rosetta, and put them whereever gnome and kde store them.
[12:48] <SteveA> if you don't do that, then we get problems of duplicated work upstream and in rosetta
[12:48] <SteveA> so the connection has to be regularly made
[12:48] <SteveA> jordi can give you more detailed advice
[12:49] <SteveA> i think KDE is more of a challenge
[12:49] <SteveA> but i think we deal with KDE-style translations now
[12:49] <mdke> mantiena: you only need to do it in one direction: rosetta -> cvs/svn
[12:49] <mdke> if everyone works in rosetta, and one person is in charge of doing that move, it will work, assuming rosetta has the infrastructure
[12:50] <SteveA> right now, translating ubuntu gets the translations out to the widest audience, because we're just coming up to a release
[12:50] <mantiena> mdke, why ? there are no GNOME 2.16 translations in rosetta now
[12:50] <mdke> mantiena: right, as I said, "assuming rosetta has the infrastructure"
[12:50] <mantiena> mdke, ;)
[12:50] <SteveA> mantiena: are you on the rosetta-users mailing list?
[12:50] <mdke> working at the same time in gnome cvs and in rosetta would be really difficult
[12:51] <mdke> nay, impossible
[12:51] <SteveA> that's a good place for a discussion of these issues, as it lets jordi and carlos contribute even if the discussion happens at a time when they're not on irc
[12:51] <mantiena> SteveA, no, I didn't have free time for mailing list :(
[12:51] <SteveA> it has quite low traffic
[12:51] <SteveA> but otherwise, try and catch up with jordi or carlos here
[12:52] <jordi> heeella
[12:52] <mantiena> mdke, we don't want to work on translations in gnome cvs if there are the posibillity to use rosetta as main translation/colaboration tool for upstream GNOME/KDE translations
[12:52] <mantiena> SteveA, thanks
[12:52] <mantiena> jordi, sorry for disturbing ;)
[12:53] <carlos> mantiena: hi
[12:53] <mdke> mantiena: yeah. that would work well, if rosetta can set up the infrastructure for translating all the gnome/kde modules on an upstream basis, and ensuring that it is done on a specific language basis
[12:53] <jordi> so, we currently have no setup to merge GNOME upstream (cvs) to rosetta and let "GNOME translation teams" do this via rosetta
[12:53] <carlos> mdke: we can do it
[12:53] <jordi> but carlos does have plans to do this in the future. I don't know how hard would that be
[12:53] <carlos> mdke: the missing bits is the sync path from GNOME to launchpad
[12:53] <mantiena> hi carlos, my translations were accepted this morning, it seems launchpad is faster, than you think ;)
[12:53] <mdke> carlos: you'd envisage teams committing to both?
[12:53] <carlos> it should be done automatically and it's 100% doable, the upload to GNOME's CVS should be done by translators
[12:54] <carlos> mantiena: ;-)
[12:54] <jordi> mantiena: ther'es a number of features planned but not yet there which would help: ie, allowing to translate both on Ubuntu's GNOME and upstream's at the same time, and making the export to upstream's svn/bzr repos easy
[12:54] <carlos> mdke: to cvs and Rosetta?
[12:54] <mdke> yeah
[12:55] <carlos> mdke: yes, it should work too, perhaps we should do small changes to improve that use case
[12:55] <jordi> mdke: per language would be easy as the GNOME Translators group exists.
[12:55] <carlos> but it's doable
[12:55] <jordi> We just need to have the GNOME translations imported into the relevant products.
[12:56] <carlos> right
[12:56] <carlos> zyga did some work on that task
[12:57] <mdke> jordi: but you have to make sure languages that don't use rosetta are totally closed
[12:57] <carlos> but I still need to get some time to expend on it to be integrated into launchpad
[12:57] <mdke> otherwise people will start making suggestions
[12:57] <carlos> mdke: we have that already done
[12:57] <mdke> oh, nice
[12:57] <jordi> mdke: yes, translation permissions are closed, of course
[12:57] <mantiena> jordi, carlos: I think our (Lithuanian GNOME translations) case would be easier, because we could use only launchpad/rosetta for translating, so from GNOME CVS we should get only newly appeared (untranslated) and fuzzy strings in .po files, also new .pot files, we don't need to merge translated strings :)
[12:57] <carlos> mdke: we have OPEN, CLOSE and STRUCTURED modes
[12:57] <carlos> mdke: Ubuntu uses STRUCTURED, GNOME would use CLOSE
[12:57] <mdke> right
[12:58] <mdke> i would say that working contemporaneously in gnome cvs and in rosetta, would be really difficult. Better if a team works in rosetta, then one member commits to cvs to get the translations in the tarballs
[12:58] <mdke> and new translations aren't added to cvs unless they come from rosetta
[12:58] <carlos> mantiena: I guess you will upload your translations into GNOME's CVS from Rosetta, right?
[12:59] <mantiena> carlos, yes, I think this would be best decision
[12:59] <carlos> mdke: that's a team choice, we cannot force that
[12:59] <carlos> mantiena: yeah
[12:59] <mdke> carlos: ah. well, you'll have fun synching from upstream then ;p
[12:59] <jordi> mdke: the teams problem
[01:00] <jordi> we would only allow GNOME teams if it's the same peopple as the official GTP teams, I hope
[01:00] <jordi> carlos can correct me, but this is my idea
[01:00] <carlos> mdke: we do it already for Ubuntu
[01:00] <mdke> well, if you want to give them the possibility of uploading non-rosetta translations to cvs, you'll need to have robust synching from cvs
[01:00] <mantiena> carlos, but main problem with rosetta now is, that rosetta don't gets unstable GNOME .po/pot's from GNOME CVS automatically
[01:00] <mdke> carlos: true
[01:00] <carlos> jordi: right
[01:00] <jordi> if not, it'll be a disaster for sure
[01:00] <carlos> jordi: the gnome coordinator will be the one allowed to add more people to the launchpad team
[01:01] <jordi> ok, so: the Spanish team doesn't want to use rosetta? No GNOME will be translated to Spanish in rosetta, only via CVS
[01:01] <carlos> mantiena: yeah, we have some code developed for that, but nothing finished yet
[01:01] <carlos> jordi: right
[01:01] <carlos> we will have it imported anyway
[01:01] <jordi> the LT team wants to use Rosetta? They will do via rosetta, and if someone uploads a lt file to cvs outside the rosetta sutff, it'll be their problem
[01:01] <carlos> but no one will be able to translate into it
[01:01] <mantiena> carlos, are there any plans, when this could be finished ?
[01:01] <carlos> jordi: well, we will import that file from cvs anyway
[01:02] <jordi> right
[01:02] <mdke> jordi: as long as it gets synched
[01:02] <carlos> mantiena: no dates set
[01:02] <jordi> mdke: we would take it from cvs in the next pull of course
[01:02] <carlos> mantiena: but I think it starts being high priority
[01:02] <jordi> but that's a problem of messy teams
[01:03] <mantiena> jordi, Now there is only one person, who can upload translations to GNOME CVS - Lithuanian GNOME translations project leader ;)
[01:03] <carlos> mantiena: I think I will get some extra help with Rosetta development soon, that will allow us to plan this feature better and give a date for it
[01:03] <mdke> spiv: do you know if there is any infrastructure for controlling moin acls by reference to a LP team?
[01:26] <SteveA> mdke: there isn't, but i'd like to add such sometime.
[01:32] <mdke> SteveA: the acl thing? It would be a very nice feature. We could use it on so many wikis :)
[01:32] <mdke> SteveA: please lemme know if there is a spec I can watch
[01:33] <SteveA> not on the radar for a while i'm afraid
[01:33] <mdke> ok
[01:33] <mdke> maybe some kind of "mass upgrade to moin 1.5" would come higher up ;)
[01:51] <jordi> woot
[01:52] <jordi> major deadline over her at lliurex
[01:57] <carlos> jordi: congratulations
[01:58] <jordi> carlos: do you know why adept has more priority than gnome-panel or kdebase?
[01:59] <jordi> does that make sense at all?
[01:59] <jordi> carlos: yeah, things will be easier at work now
[01:59] <carlos> jordi: mark set it that way
[01:59] <carlos> jordi: I guess gnome-panel and kdebase should have higher priority
[02:02] <jordi> yes
[02:02] <jordi> I'm going thrtough
[02:35] <sabdf1> carlos: https://launchpad.net/bugs/46730
[02:35] <Ubugtu> Malone bug 46730 in ubuntu-artwork "The ubuntu-artwork translation template is not installed" [Normal,Unconfirmed]
[02:35] <sabdf1> any idea?
[02:36] <carlos> sabdf1 I think we don't support it as part of the language packs
[02:36] <carlos> sabdf1:  the package needs to be rebuilt with the .po files from rosetta
[02:37] <carlos> sabdf1: those translations are integrated inside an XML file on build time and are not using gettext at all
[02:39] <carlos> bug updated
[02:39] <sabdf1> ok
[02:39] <looksaus> in which channel should I bug you good ubuntu people about dapper bugs? #ubuntu+1
[02:39] <looksaus> ?
[02:40] <looksaus> I reported a showstopper bug in firefox on ppc about six weeks ago and might not have made enough noise around it
[02:41] <lifeless> #ubuntu-bugs
[02:41] <looksaus> ok, thx
[02:57] <salgado> great. one more 30-mergepeople.txt failure. :-(
[02:59] <kiko> SteveA, it is still there. :-/
[03:20] <kiko> bradb, 30-mergepeople or something?
[03:21] <bradb> no. eight others.
[03:22] <bradb> it's nice they're listed at the bottom of the email though. no more ctrl-f'ing the email required.
[03:22] <matsubara> bradb: is there any failure on soyuz/26-queue-pages.txt ?
[03:23] <bradb> matsubara: nope, it's all goot.
[03:25] <kiko> bradb, they are?
[03:26] <bradb> Tests with failures:
[03:26] <bradb>    /home/pqm/arch/queue/workdir/home/---devel/launchpad/lib/canonical/launchpad/doc/bug.txt
[03:26] <bradb>    /home/pqm/arch/queue/workdir/home/---devel/launchpad/lib/canonical/launchpad/doc/bugzilla-import.txt
[03:26] <bradb> ...
[03:28] <kiko> sounds like they are all your fault. :)
[03:28] <bradb> yep
[03:33] <spiv> mdke: the team membership info gets passed to moin, but currently moin just discards that information.  It would be interesting, and probably not too hard, to hook that up to Moin's ACL stuff, but I haven't looked at the ACL code at all.
[03:36] <Kinnison> spiv: has thom contacted you about the brokenness of dapper's sqlobject?
[03:36] <spiv> Kinnison: I have a ping from him from three hours ago, but I only just got back to my keyboard to pong...
[03:37] <mdke> spiv: that would be _so_ cool
[03:37] <Kinnison> spiv: aah
[03:37] <spiv> Kinnison: he says he's figured it out
[03:38] <carlos> see you later
[03:39] <Kinnison> spiv: cool
[03:41] <sivang> spiv: oh, nice, then we could have certain pages that belong to certain team, and only approved team members could edit those?
[03:41] <spiv> sivang: Right.
[03:43] <kiko> matsubara, can you file an RT request for bug 42125? otherwise we can run her from async.
[03:43] <Ubugtu> Malone bug 42125 in dilys "Dilys should be run from one of the Canonical servers" [Normal,Unconfirmed]  http://launchpad.net/bugs/42125
[03:44] <matsubara> kiko: ok, I'll do that.
[03:46] <kiko> salgado, can you pull in mpt's branch?
[03:46] <kiko> I'll be happy to review it
[03:47] <salgado> kiko, I tried to merge rocketfuel into my branch first, but got 4 spurious conflicts
[03:47] <kiko> try star-merge. :)
[03:49] <mdke> sivang: well, you can do that now, just not with launchpad groups
[03:50] <sivang> mdke: you mean through moin's current ACL mechanism ?
[03:53] <mdke> sivang: quite
[03:53] <Yannig> Hello :)
[03:54] <sivang> hey Yannig
[03:54] <Yannig> Do you know if there are problems with the upload queue? I uploaded about 10 po files yesterday and no news from them :(
[03:54] <sivang> carlos: ^^
[03:56] <kiko> Yannig, we were importing OOO yesterday which is known to take time to process
[03:56] <kiko> I'm not sure
[03:56] <Yannig> OK :)
[03:56] <Yannig> But we are still supposed to be notified when our file is uploaded, right? Just have to wait then :)
[03:58] <kiko> yep
[03:58] <kiko> Yannig, you can check /rosetta/imports
[03:59] <Yannig> Yes but there are so many files and I don't know how to find mines :D
[03:59] <kiko> hmmm
[03:59] <kiko> there's a search feature now but it isn't in production yet
[04:00] <Yannig> Don't worry, I can wait :)
[04:01] <Yannig> I'm the only one on my language, not so difficult to agree with myself not to translate the files to be uploaded :)
[04:01] <salgado> cprov, carlos, any of you guys using mawson now?
[04:01] <cprov> salgado: yes, I am
[04:02] <salgado> cprov, do you depend on the running launchpad or just the database? (I'm wondering if I could kill and restart it using a more recent branch)
[04:04] <cprov> salgado: I depend on librarian
[04:04] <salgado> I see
[04:04] <cprov> salgado: wait some minutes until the current publisher run finish
[04:05] <cprov> salgado:  I'll start my own librarian and you can use the UI (w/o starting librarian, tweak the lp.conf)
[04:06] <salgado> cprov, cool, thanks.
[04:06] <salgado> but even so, I think I need to wait for carlos. he has a script running there
[04:07] <cprov> salgado: he doens't use lp_dogfood, he uses staging or prod, don't know
[04:07] <cprov> salgado: you only depend on me
[04:16] <peza> hi all, i'd like to log a bug in dapper - just a typo in the example content files. Is launchpad the place to do this (very small) bug?
[04:18] <mdke> peza: yes
[04:19] <peza> mdke, cheers
[04:33] <sivang> oh, joy, my branch is already mirroed at bazaar.lp.net , last time I checked it wasn't so
[04:43] <carlos> salgado: hi, my script uses asuka so don't worry about it
[04:43] <carlos> kiko: do we?
[04:44] <kiko> carlos, guess not, but we're supposed to move it to production soon
[04:52] <aa_> does the mirroring facility ever work?
[04:53] <spiv> aa_: it doesn't yet support knit branches, but will next week if that's what you're wondering.
[04:54] <aa_> oh I see, yes, I think all my branches are knit
[04:54] <spiv> Yeah, sorry about that :(
[04:54] <aa_> not at all :)
[04:54] <aa_> just wondering
[04:54] <spiv> But it'll be fixed with the next rollout.
[04:54] <aa_> one of my users read it to mean "the branch is not available from the supermirror"
[05:34] <cprov> salgado: you can restart dogfood UI, just don't rename the 'current' neither starts a new librarian
[06:00] <salgado> cprov, cool. thank you!
[06:16] <kiko-fud> hello hello
[06:46] <salgado> so, if I send an email to<EMAIL_ADDRESS>containing only commands, should the commands show up as comments on that bug?
[06:47] <bradb> BjornT: ping
[06:52] <bradb> salgado: I believe so, but BjornT would have to confirm.
[06:55] <BjornT> salgado: yeah, that's right. you can send a mail to edit@bugs in order to edit a bug without adding a comment (indicating the bug with ' bug 42').
[06:55] <Ubugtu> Malone bug 42 in malone "Bug description listed in task is not the correct description" [Normal,Fix released]  http://launchpad.net/bugs/42
[06:55] <BjornT> bradb: pong
[06:56] <bradb> BjornT: I'm getting this error from bugnotification-sending.txt:
[06:56] <bradb> ...
[06:56] <bradb> ProgrammingError: ERROR:  permission denied for relation packagebugcontact
[06:56] <bradb> ...
[06:57] <bradb> My guess is that something in this test is being run as a different database user, and is now tripping up on the implicit sub lookups.
[06:57] <bradb> BjornT: Does that sound like the problem?
[06:58] <salgado> BjornT, ahh, good to know that. thanks!
[06:58] <BjornT> bradb: exactly. you need to give the 'bugnotification' user SELECT permissions on the packagebugcontact table in database/schema/security.cfg
[07:00] <cprov> salgado: are you going to start the dogfood UI soon or not ?
[07:03] <salgado> cprov, simply changing "launch yes" to "launch no" on dogfood's launchpad.conf should prevent a librarian to be started, right?
[07:06] <bradb> BjornT: that worked, thanks!
[07:07] <cprov> salgado: right
[07:10] <salgado> cprov, running, and without librarian. :)
[07:20] <cprov> salgado: good, thank you
[07:24] <salgado> kiko, yay!! https://dogfood.ubuntu.com/distros/ubuntu/+mirror/crap/
[07:24] <kiko> k-rad!!
[07:24] <kiko> awesome!
[07:25] <kiko> salgado, I'm not going to comment that the releases are not ordered <wink>
[07:25] <kiko> salgado, why didn't we just use the strings to index into DistroRelease, btw?
[07:25] <kiko> flavors aren't in our DB, but the releases are
[07:25] <salgado> don't worry, it's still time to fix all you want
[07:25] <kiko> yeah, true
[07:26] <kiko> that'd be ideal
[07:26] <salgado> pqm is not willing to merge this branch anyway
[07:26] <kiko> lol
[07:27] <salgado> anyway, there's another pqm failure I need to deal with first
[07:45] <salgado> kiko, I didn't understand your question about using strings to index into DistroRelease
[07:52] <kiko> salgado, okay.
[07:52] <kiko> well
[07:52] <kiko> answer me first:
[07:52] <kiko> is it possible to order that page by the distribution release release date?
[07:53] <salgado> not easily, but yes, it is
[07:54] <kiko> why not easily?
[07:54] <salgado> not so easily
[07:55] <salgado> I was right
[07:55] <salgado> not easily
[07:58] <salgado> it'll either require some python: usage on templates, or a class to store the rows of the table temporarily
[07:59] <salgado> it's easy, actually
[08:00] <kiko> that's better.
[08:00] <kiko> show me the diff!
[08:01] <salgado> I'd love if there was a better way of handling lists of lits using TAL
[08:01] <salgado> and lists of lists too
[08:01] <kiko> yeah lists of lits are not so bad
[08:02] <kiko> lists of lists are really annoying thoughh
[08:36] <salgado> kiko, https://chinstrap.ubuntu.com/~dsilvers/paste/fileAvh0Dp.html
[08:37] <kiko> salgado, what a hack. I think we should change the DB schema instead.
[08:38] <kiko> instead of constructing on the fly
[08:38] <kiko> are you radically opposed to that?
[08:38] <salgado> at this point, yes
[08:38] <kiko> but the DB patch hasn't even landed yet
[08:39] <salgado> this change is going to be anything but trivial
[08:39] <kiko> well, let's think about it.
[08:39] <kiko> the /only/ differences I can see are:
[08:39] <kiko> - when adding content rows you look up the distro release by name
[08:39] <kiko> - when displaying them you display release/name
[08:40] <kiko> - the DB schema has a different column
[08:40] <kiko> what else is complicated, salgado?
[08:40] <salgado> I didn't understand your suggestion
[08:40] <kiko> I'll hop up.
[08:55] <salgado> kiko, there's no datecreated on distrorelease. :/
[08:56] <sigurdga> sorry if I am not the first one to say, but is launchpad.net having problems?
[09:01] <Kinnison> s'being a touch broken right now no?
[09:01] <salgado> sigurdga, it seems to be down
[09:01] <sigurdga> ok
[09:01] <seb128> re
[09:02] <seb128> is launchpad known to be broken atm? :)
[09:02] <SteveA> yes
[09:02] <seb128> k
[09:02] <kiko> salgado, IT SUCKS. it's a bug
[09:02] <Kinnison> :-)
[09:03] <SteveA> stu will be around in 10 mins
[09:03] <SteveA> meanwhile, i'm going to do what i can
[09:04] <salgado> kiko, https://dogfood.ubuntu.com/distros/ubuntu/+mirror/crap/
[09:05] <salgado> kiko, warty and hoary ids are swapped. :)
[09:06] <salgado> IOW, you just sandbagged my by asking this damn feature. we can't reliably sort distroreleases in order of release
[09:07] <kiko> @#!@!#$
[09:07] <SteveA> launchpad appears to be alive again
[09:08] <sigurdga> thanks!
[09:18] <bradb> salgado: why can't you use datereleased?
[09:26] <salgado> bradb, because it's None for non-released
[09:29] <bradb> I'd imagine as much. :) I just wondered if a datecreated would be of much practical use for sorting anyway. More important seems to be knowing when a distrorelease was put into a certain state, but maybe not.
[10:08] <salgado> we have distrorelease.version, obviously. :)
[10:26] <kiko> salgado, yeah. do you know how to order them? use apt_pkg
[10:26] <salgado> apt_pkg? they use sourcerer.deb.version.Version() in other places
[10:28] <kiko> hmmm
[10:28] <kiko> maybe it's safe for distorelease versions
[03:33] <sigurdga> Anyone knowing if or how I as an administrator of a translator team can accept a suggested translation?
[03:35] <mdke> sigurdga: you copy and paste it
[03:36] <sigurdga> i will not copy and paste 1000 single string translations, if that is what you meant
[03:36] <mdke> sigurdga: I don't mind
[03:36] <mdke> I'm just saying, that is how you can do it
[03:37] <sigurdga> ... there must be another way, so that I can accept the whole translation of the package
[03:37] <mdke> fraid not.
[03:37] <mdke> but that might have advantages: you might be tempted to approve translations without reading them
[03:37] <mdke> this way, you don't have that problem
[03:38] <sigurdga> yes, i know
[03:39] <sigurdga> our problem, that I am up to fight, is that until now, we are accepting all new members, and by that allowing the translation of ubuntu to be really crappy
[03:40] <mdke> sigurdga: yeah, that's a very common problem, unfortunately. Recently lots of translation teams have been tightening up in order to avoid that
[03:40] <sigurdga> I _could_ maybe have clicked in 601 checkboxes for this particular translation, but copy paste is too much work...
[03:41] <sigurdga> And I think it is useless to discard some of the newest translations
[03:41] <mdke> but you have to read them, right? so copy/paste isn't much extra time over that
[03:42] <mdke> well, it is, but it's not _too_ bad
[03:43] <mdke> ok... so you have stopped accepting new members now?
[03:43] <mdke> or you have removed people?
[03:43] <sigurdga> I have to do both
[03:43] <sigurdga> and I do not like it
[03:44] <mdke> why not?
[03:44] <sigurdga> but going over retranslating is frustrating
[03:44] <mdke> they get upset?
[03:45] <mdke> if you remove a team member, you shouldn't lose their translations that they did before they were removed...
[03:45] <sigurdga> I am in the process of tidying up right now, they have not had the time to get upset yet...
[03:45] <sigurdga> I knwo
[03:46] <sigurdga> I wish I could comment on the users translations in general (I can by sending a mail) and get them to correct their errors themselves
[03:47] <mdke> so you are reviewing the existing translations?
[03:47] <sigurdga> I do not want do be a schoolteacher doing almost the same amount of work as doing it myself
[03:47] <sigurdga> yes, from the latest days
[03:48] <mdke> I'm not quite sure what your technical problem is. Are you reviewing suggestions for translations which are empty, or existing translations from old team members?
[03:48] <sigurdga> the activiti kind of exploded, in contrast to the usual lazyness
[03:48] <sigurdga> I am trying to (reactively) fight our problem of crappy translations done by helpful users...