[12:20] <Ubugtu> New bug: #65577 in malone "Report a bug in current distro release context oopses" [Undecided,Confirmed]  http://launchpad.net/bugs/65577
[01:14] <kiko> jordi?
[01:35] <Ubugtu> New bug: #65588 in malone "When reporting via email, ignore package specified in "affects" if the package is not found - keep the distro though, and don't reject the submission" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65588
[01:40] <Ubugtu> New bug: #65589 in soyuz "Deathrow processing has dryrun vs. commit backwards" [Critical,In progress]  http://launchpad.net/bugs/65589
[01:45] <malcc> Anyone up for a quick review?
[01:45] <kiko> malcc, sure.
[01:45] <malcc> kiko: https://devpad.canonical.com/~andrew/paste/file6tTyOl.html
[01:52] <kiko> malcc, no way -- that bug really existed?!!
[01:53] <kiko> coisa horrvel
[01:53] <kiko> malcc, that needs a test
[01:53] <malcc> kiko: Yeah, you're probably right. What do you think is the best location for a script-launching test?
[01:54] <malcc> kiko: It's a nice thin script, so I'd like to keep the "actually run the script" test nice and small, away from the tests of the module in deathrow.txt
[01:54] <kiko> scripts/ftests
[01:54] <malcc> Cool
[01:54] <kiko> r=kiko if it's tested
[01:54] <kiko> gross error
[01:58] <kiko> and mine too :-(
[01:58] <malcc> kiko: Well I tested it :(
[01:58] <malcc> I guess I just never looked at the db after a functional test, just the deleted files
[01:59] <kiko> yeah
[01:59] <kiko> crackhead developers of doom
[01:59] <kiko> good that you caught it though :)
[01:59] <kiko> anyway, outta here
[01:59] <malcc> Goodnight
[01:59] <kiko> zzz
[02:29] <mpt> Gooooooooooooooooooood afternoon Launchpadders!
[05:51] <indu> kiko: hi, good morning
[06:17] <indu> hi, is there any irc channel for the soyuz product
[06:18] <indu> lifeless: hi  is there any irc channel for the soyuz product
[06:19] <Burgundavia> indu: no, just here
[06:20] <indu> Burgundavia: then who is the correct person to talk about it
[06:21] <Burgundavia> hmm, no idea
[07:30] <mpt> indu, either cprov or malcc
[07:31] <mpt> indu, neither of them are here at the moment, but malcc should be here in 5.5 hours or less.
[07:47] <jamesh> indu: if you ask your question, we might be able to answer it
[07:47] <jamesh> (then again, we might not and you'll have to wait for malcc or cprov)
[08:00] <jamesh> mpt: you'll be happy to know that cascading section support in ~/.bazaar/locations.conf landed -- so "bzr push" won't break your "bzr pqm-submit" configuration
[08:10] <indu> jamesh: sorry, just out of my seat
[08:11] <indu> jamesh: I want to experiment with soyuz, so that I can decide whether I can proceed with this further 
[08:11] <indu> jamesh: so can any of u please tell me, where can i try this soyuz product 
[08:12] <jamesh> indu: Soyuz is the distribution management portion of https://launchpad.net
[08:12] <jamesh> what aspect are you wanting to test?
[08:13] <indu> jamesh: I am working for a distribution, its debian based
[08:13] <indu> jamesh: and now we want to create our own repository with our packages
[08:13] <indu> jamesh: as ubuntu has recompiled all debian packages into ubuntu packages and renamed them from debian to ubuntu
[08:14] <indu> and I got the info that ubuntu is using this soyuz product 
[08:14] <indu> jamesh: so i want to know, how far will this be helpfull in our distribution
[08:14] <jamesh> iirc the packages with release numbers like *ubuntu* are unes that have been modified by the Ubuntu developers
[08:15] <jamesh> rather than being a mechanical rename + recompile
[08:16] <indu> jamesh: yes I heard that renaming and recompilnig is done using this soyuz product
[08:16] <jamesh> I don't think the build daemon code is public yet.  We do plan to provide a way for other people to manage small repositories of packages in the future (personal package archives)
[08:16] <jamesh> but that is not ready yet
[08:17] <crimsun> indu: for clarification, soyuz doesn't rename and upload source packages; individual Ubuntu developers do that.
[08:18] <indu> crimsun: then what does this soyuz do
[08:19] <crimsun> indu: jamesh is explaining that
[08:19] <indu> jamesh: can i know what this soyuz doea actually
[08:20] <indu> *does
[08:20] <jamesh> indu: it manages the package archive (you can browse it at https://launchpad.net/distros/ubuntu), manages a queue of uploaded source packages, feeding those source packages to build daemons and then adding the resulting binary packages to the archive
[08:49] <SteveA> mpt: ping
[08:54] <mpt> SteveA, pong
[09:21] <SteveA> mpt: I'm about to leave for mossop st.  will you be around in 35 mins ?
[09:21] <SteveA> and congrats on getting the DSL sorted!
[09:22] <SteveA> if you won't, please send me a fresh email saying about the TraversalError problem on the UI branch.  I'll look into it this morning.
[09:22] <mpt> SteveA, I will
[09:53] <SteveA> mpt: ping
[09:54] <mpt> pingity pong
[10:22] <jamesh> mpt: bzr push will still be doing the same thing
[10:24] <mpt> Is that what the smart server will fix?
[10:26] <stub> jamesh: https://devpad.canonical.com/~jamesh/oops.cgi/2006-07-12/S21
[10:26] <stub> mpt: It is quicker to rsync your entire repository
[10:27] <stub> push: .FORCE
[10:27] <stub>         rsync -avPze ssh --delete-after \
[10:27] <stub>             ~/.canonical-bzr/ \
[10:27] <stub>             devpad:/home/warthogs/archives/stub/
[10:27] <jamesh> mpt: the smart server has the potential to reduce the number of round trips needed to push the branch, so yes.
[10:27] <mpt> nifty
[10:27] <jamesh> for now rsync is generally faster.
[10:28] <mpt> ok, I'll start using rsync once I've finished importing all my branches
[10:28] <jamesh> stub: you can use devpad.canonical.com:/code/stub now
[10:28] <mpt> otherwise some of them will get nuked
[10:29] <jamesh> mpt: I have a bzr plugin that can push all the branches in a repository in a single go.  It is faster than multiple sftp pushes, but slower than rsync
[10:30] <jamesh> mpt: if you have multiple branches to push
[10:31] <_thumper_> morning all
[10:33] <_thumper_> jamesh: I've been talking with steve and ddaa about a problem with timeouts, and stub commented on the review and brought up the main issue that had been bothering me
[10:33] <stub> jamesh: That error is an invalid oops, so looks like it is just breaking rather than returning a 404
[10:33] <_thumper_> and that is executing the actual query twice
[10:34] <_thumper_> One suggestion is the possibility of pushing the functionality down into sql object and how it processes the queries
[10:34] <_thumper_> add the ability to set a low and high water mark for the query
[10:34] <_thumper_> if the rowcount hits the low mark, a warning is emmitted
[10:34] <_thumper_> at the high mark, an exception is raised
[10:35] <_thumper_> jamesh: any comments on how easy this would be to implement?
[10:35] <jamesh> _thumper_: so something like the selectOne() routine but more generic?
[10:35] <_thumper_> jamesh: not sure on what selectOne does, 
[10:36] <_thumper_> the idea is that these values are checked before iteration begins
[10:36] <jamesh> stub: fixed.
[10:36] <stub> _thumper_: Best you can do is specify a LIMIT clause in the SQL query. You still either need to retrieve the results to see if the limit has been met, or do a count().
[10:37] <_thumper_> stub: the actual problem is not the actual query timing out
[10:37] <jamesh> _thumper_: it is a variant of the sqlobject select() method that you can use for queries that should return 0 or 1 rows
[10:37] <_thumper_> but in the processing of the objects, other queries are executed
[10:37] <_thumper_> and it is the repeated other queries that are causing the timeouts
[10:38] <stub> Kiko wrote the prejoin stuff for SQLObject to help with this problem, but it doesn't solve all of the cases
[10:38] <jamesh> _thumper_: it issues a "limit 2" query, and raises an exception if it gets two rows back
[10:38] <_thumper_> jamesh: ok
[10:38] <_thumper_> once the query has been executed, is the rowcount available?
[10:38] <stub> _thumper_: Only after the rows have been retrieved. 
[10:39] <stub> _thumper_: (because the database might not even know if it is streaming the data as the query executes rather than materializing everything in RAM and sending it after)
[10:39] <_thumper_> stub: ok, I get that
[10:40] <jamesh> stub: the DB API provides a cursor.rowcount attribute
[10:40] <jamesh> does that get set to something meaningful?
[10:40] <stub> jamesh: Which is undefined until you have selected all the results fom the cursor
[10:41] <jamesh> stub: that's now how it is defined to act in the API
[10:41] <stub> (just like JDBC, PerlDBI and everything else that needs an ODBC backend)
[10:41] <_thumper_> so the cursor is moved during the creation of the objects using the iteration functions?
[10:41] <jamesh> actually, maybe it does.
[10:41] <jamesh> "This read-only attribute specifies the number of rows that the last executeXXX() produced ... or affected"
[10:42] <stub>             The attribute is -1 in case no executeXXX() has been             performed on the cursor or the rowcount of the last             operation is not determinable by the interface. [7] 
[10:42] <jamesh> and it says that it can be -1
[10:42] <jamesh> yeah
[10:42] <stub> Which in practice, unless you are using a toy database, it will be -1 until you have selected all the rows.
[10:43] <stub> _thumper_: Yes
[10:43] <_thumper_> stub: thanks
[10:43] <_thumper_> I've got an idea, and will push it to devpad this morning for review
[10:43] <jamesh> still not quite sure why batching isn't an option for this
[10:44] <stub> _thumper_: Unless you hit some code that converts the resultset into a list, which is generally a bug needing to be fixed.
[10:44] <spiv> mpt: FWIW, the smart server today already speeds up pushing a bit: http://bazaar-vcs.org/Performance/0.11 (it's still just file-level operations, but it cuts down on round-trips for certain operations).
[10:44] <_thumper_> jamesh: ideally it is, but that is not being persued just now
[10:45] <_thumper_> jamesh: what I'd prefer would be a filtered list
[10:46] <_thumper_> so instead of batching the results you enter something to produces a reduced result set
[10:46] <stub> I think the idea of hardcoding limits and raising an exception if there are too many results is just an interim fix when people believe that it will not actually happen on any pages, and if we see OOPS reports for that exception then batching needs to be added to that page.
[10:46] <spiv> mpt: If you have bzr 0.11 locally, you could try "BZR_REMOTE_PATH=/code/rocketfuel-built/launchpad/sourcecode/bzr/bzr bzr push bzr+ssh://devpad/code/..."
[10:46] <_thumper_> stub: that's the intention
[10:46] <spiv> mpt: (the BZR_REMOTE_PATH is a hack to workaround bzr 0.11 not being installed system-wide on devpad yet)
[10:47] <stub> _thumper_: You still need to be able to display the full, unfiltered list though (batched over multiple pages of course), or search engines will not be able to find the information.
[10:48] <_thumper_> stub: yes I think that the primary page will be batched
[10:48] <_thumper_> and the details page (which is the one causing the problems at the moment) will use a filter
[10:48] <_thumper_> the primary listing page at the moment just shows all
[10:50] <mpt> spiv, is there any reason not to upgrade to 0.11, and if not, how do I do so?
[10:50] <spiv> mpt: are you using edgy or dapper?
[10:51] <spiv> bzr 0.11 seems very solid, and it's faster.  I can't think of any reason not to use it.
[10:51] <spiv> http://bazaar-vcs.org/DistroDownloads gives a like to a repo with dapper debs.
[10:51] <spiv> a link, rather.
[10:54] <jamesh> spiv: should an RT request be filed to get bzr-0.11 installed as default?
[10:55] <spiv> jamesh: Wasn't there already a request for that?
[10:55] <jamesh> dunno
[10:56] <spiv> I think I'm thinking of something related, getting bzr 0.11 into a more official repo or something.
[10:56] <spiv> Probably worth filing the RT request anyway.
[11:00] <Spads> I have a request here mentioning "launchpad-dependencies".  Is there an official list of dependencies for launchpad somewhere?
[11:01] <Spads> I believe the request is for build-deps, really.
[11:01] <malcc> Spads: There's a package of that name, to make launchpad dependency installation easier
[11:02] <Spads> hmmm, I'm not seeing it in dapper
[11:02] <Spads> Where can I find it?
[11:03] <malcc> Spads: It's in dapper
[11:03] <jamesh> Spads: it is in multiverse
[11:03] <Spads> ahhhh
[11:04] <mpt> spiv, is there any reason not to upgrade to Edgy, and if not ... I can work that much out :-)
[11:04] <jamesh> Spads: it isn't in edgy at all though.
[11:04] <mpt> i.e. do all the Launchpad dependencies Just Work in Edgy?
[11:04] <spiv> mpt: I'm running edgy, and aside from some X+suspend/resume woes, it seems fine.
[11:05] <mpt> such woes I already have, so I'll do that this weekend then
[12:03] <philroche> Hi Guys, I am having trouble importing my rpoject into Lanuchpad (from SVN) I get -  Invalid source package name - any ideas?
[12:30] <indu> hi, kiko, r u there
[01:23] <glatzor> ping jordi: is the po file import of Rosetta currently stalled?
[01:26] <malcc> Anyone fancy reviewing a test? I got r=kiko last night on my main change, on condition I added a test, and the test ended up a lot bigger than the change
[01:29] <jamesh> philroche: you can safely ignore that message
[01:40] <stub> Ahh sod. Launchpad meeting in 20 mins :-P
[01:41] <_thumper_> stub: SteveA said to bug you about LayerInvariantError when running tests
[01:41] <_thumper_> I merged from devpad devel branch yesterday
[01:42] <stub> When running some particular test or subset? Or the entire suite?
[01:42] <_thumper_> I was running a subset canonical.launchpad.webapp
[01:42] <stub> We have a bug open on it happening in some cases where you run a subset of tests, but it would become more critical if the 'run all tests' started blowing up.
[01:43] <_thumper_> ok
[01:43] <jamesh> it usually means that some test is doing some setup it shouldn't for its layer, or forgetting to tear something down
[01:43] <_thumper_> hmm... ok
[01:43] <jamesh> (which might get masked with other tests running after it in the layer)
[01:43] <stub> jamesh: There is a real bug where the test runner loads the layers in an unexpected order. I think it is our fault.
[01:43] <jamesh> ah.
[01:44] <stub> jamesh: Possibly just too many paranoid checks, or maybe something more nefarious.
[01:44] <jamesh> stub: If we stop using initZopeless, I wonder how the layers should be configured/stacked?
[01:45] <stub> It will need to be the same, as the scripts still load a different .zcml file.
[01:45] <stub> So unless that changes...
[01:46] <jamesh> it would be good to get different db users factored into the layers
[01:46] <jamesh> perhaps a LaunchpadZopelessLayer(dbuser) function that would auto-create layers as needed
[01:48] <stub> There are already some (sucky) APIs for changing the user a test connects as. I can't remember if it is both for Zopeless and Zopeful. It would be easier if I nuke the old FooTestSetup classes. The layer per user could be a good idea, but probably better to implement using standard inheritance (class names leak out into the command line remember)
[01:49] <stub> And other test runner magic might break - don't know.
[01:49] <stub> class FooLayer(LaunchpadZopelessLayer): dbuser='bar'  is easy enough
[01:54] <SteveA> hmm
[01:54] <SteveA> wish these were called TestLayer not just Layer
[01:54] <SteveA> as we've been already using "Layer" for UI layers
[01:55] <mpt> like an onion
[01:55] <SteveA> stub: want to do the honours for this meeting?
[01:55] <SteveA> ah, wait, mpt has internet!
[01:55] <stub> I want a beer
[01:55] <SteveA> mpt: in celebration of your internet connection
[01:55] <SteveA> would you like to chair today's meeting?
[01:55] <malcc> I vote that stub gets a beer
[01:56] <stub> Seconded. I'm outa here!
[01:56] <SteveA> I here there are great bars in thailand
[01:56] <SteveA> very friendly bars
[01:56] <stub> Beer tastes better with naked women
[01:57] <kiko-zzz> me
[01:57] <SteveA> fa so la
[01:57] <stub> me
[01:57] <mpt> SteveA, ok
[01:57] <SteveA> thanks mpt
[01:57] <stub> ./execute fake_meeting_attendance
[01:58] <mpt> just as soon as I remember how to spell "agenda"
[01:59] <spiv> agenduh.
[01:59] <stub> haha
[02:00] <spiv> (the singular form is agendumb)
[02:00] <mpt> MEETING TIME!
[02:00] <mpt> Welcome to the weekly Launchpad development meeting
[02:00] <mpt> Who's here?
[02:00] <malcc> me
[02:00] <cprov> me
[02:00] <matsubara> me
[02:00] <_thumper_> me
[02:00] <spiv> me
[02:00] <flacoste> me
[02:00] <bradb> me
[02:00] <kiko> me
[02:01] <SteveA> me
[02:01] <stub> m
[02:01] <stub> e
[02:01] <jamesh> me
[02:01] <BjornT> me
[02:01] <ddaa> hello
[02:01] <mpt> Is that everyone?
[02:02] <mpt> == Agenda ==
[02:02] <mpt>  * Activity reports
[02:02] <mpt>  * Actions from last meeting
[02:02] <mpt>  * Oops report (Matsubara)
[02:02] <mpt>  * Bug report report (mpt)
[02:02] <mpt>  * Production and staging (Stuart)
[02:02] <mpt>  * Launchpad 1.0 status reports + updating spec status
[02:02] <mpt>  * Sysadmin requests
[02:02] <mpt>  * Storing date_created and other dates and people related to state transitions.
[02:02] <mpt>  * Keep, Bag, Change
[02:02] <mpt>  * Three sentences
[02:02] <mpt> 
[02:02] <mpt> If you have things not mentioned there, please /msg me
[02:02] <mpt> == Activity reports ==
[02:02] <kiko> mpt, you cleared out my extra items
[02:02] <SteveA> kiko: they're in there
[02:02] <SteveA> kiko: I added them, I think
[02:03] <mpt> Who's up to date?
[02:03] <malcc> Not me
[02:03] <SteveA> not me
[02:03] <kiko> ok
[02:03] <matsubara> up to date
[02:03] <flacoste> up to date
[02:03] <kiko> not me
[02:03] <jamesh> not me
[02:03] <BjornT> up to date
[02:03] <_thumper_> I've been slightly lax during the sprint
[02:03] <mpt> up to date
[02:03] <stub> me
[02:03] <spiv> up to date
[02:03] <ddaa> Not uptodate but excused because on sprint. Up to date otherwise.
[02:03] <bradb> up to date
[02:03] <mpt> kiko, the only thing I cleared was the template "(other items)" line
[02:03] <cprov> not me
[02:03] <SteveA> I want to point out that although we have special guest chairs each week, in general I still set the agenda before the meeting.
[02:04] <mpt> ok
[02:04] <mpt> == Actions from last meeting ==
[02:04] <mpt>  * SteveA to put up a wiki page for the launchpad project to note disaster scenarios on, and mail the list about it
[02:04] <mpt> I did that. SteveA, want to talk about it? :-)
[02:04] <SteveA> mpt: thank you for doing that.
[02:04] <SteveA> https://launchpad.canonical.com/DisasterScenarios
[02:05] <SteveA> there are some scenarios of a disasterous nature on here
[02:05] <mpt> from my own feeble imagination
[02:05] <SteveA> please take a moment to read through them, and think about particular disasters that may befall the area of launchpad you're personally involved in
[02:05] <SteveA> and add them to the page using a similar format to the ones mpt started
[02:05] <malcc> I suspect Soyuz will be able to provide some truly disasterous possibilities
[02:05] <SteveA> we'll review and refine them later
[02:06] <mpt> thanks SteveA 
[02:06] <mpt> aaaaaand secondly
[02:06] <mpt>  * SteveA to write up what needs doing to implement __eq__, __ne__, and __hash__ for database objects
[02:06] <SteveA> try to describe specific risks and threats
[02:06] <SteveA> I'm looking for quality and interesting interactions between use and things
[02:06] <SteveA> rather than sheer quantity.
[02:06] <SteveA> 
[02:06] <SteveA> mpt: I still need to put my notes online on that
[02:07] <mpt> ok. We'll nag you again next meeting.
[02:07] <SteveA> ta
[02:07] <mpt> == Oops report (Matsubara) ==
[02:07] <matsubara> Today's oops report is about bugs 65577, 30602 and 2497
[02:07] <Ubugtu> Malone bug 65577 in malone "Report a bug in current distro release context oopses" [Undecided,Confirmed]  http://launchpad.net/bugs/65577
[02:07] <Ubugtu> Malone bug 30602 in rosetta "Timeout errors in +translate" [Critical,Confirmed]  http://launchpad.net/bugs/30602
[02:07] <Ubugtu> Malone bug 2497 in rosetta "/people/*/+translations times out for prolific translators" [Critical,In progress]  http://launchpad.net/bugs/2497
[02:07] <matsubara> bradb, your work on release management will address bug 65577? If not, can you
[02:07] <matsubara> fix that one?
[02:07] <matsubara> kiko, bugs 30602 and 2497 are up for review for awhile. Any news on it?
[02:07] <kiko> matsubara, 2497 I have a review to reply to, but 30602 still pending jamesh' review
[02:08] <bradb> matsubara: sure, i'll keep an eye out for it.
[02:08] <matsubara> well, I'm done then. thanks mpt and congrats to everyone. 0 exceptions today.
[02:09] <SteveA> that's great news
[02:09] <SteveA> soon, I think we'll be hitting 0 exceptions per day consistently
[02:09] <mpt> ok
[02:09] <mpt> == Bug report report ==
[02:09] <mpt> There are 17 known Critical bugs in Launchpad without released fixes. The oldest 8 not already mentioned by matsubara are:
[02:09] <mpt>  * Bug 929
[02:09] <Ubugtu> Malone bug 929 in launchpad "Long words (such as URLs) overflow columns" [Critical,Confirmed]  http://launchpad.net/bugs/929
[02:09] <ddaa> Except for _thumper_'s branch that will turn some existing timeouts into exceptions...
[02:09] <lucasvo> how comes that it says Revision control system: None given but I use bzr for my project? (https://launchpad.net/products/harmony/trunk)
[02:10] <mpt> Is that really critical? jamesh, what say you?
[02:10] <mpt>  * bug 4594
[02:10] <Ubugtu> Malone bug 4594 in malone "Shouldn't be able to add duplicate bug watches" [Critical,Confirmed]  http://launchpad.net/bugs/4594
[02:10] <jamesh> mpt: dunno if it is critical, but it can make pages look ugly
[02:10] <ddaa> lucasvo: link to the main branch for your project in https://launchpad.net/products/harmony/trunk/+edit
[02:10] <SteveA> it's critical for the ui-one-zero
[02:11] <mpt> BjornT, have you looked at that yet?
[02:11] <BjornT> mpt: no, haven't had time yet. i'm planning to fix it next week.
[02:11] <mpt>  * Bug 38598
[02:11] <Ubugtu> Malone bug 38598 in launchpad-bazaar "Branch has no datecreated" [Critical,In progress]  http://launchpad.net/bugs/38598
[02:11] <mpt> BjornT, ok
[02:11] <lucasvo> ddaa: I already did that
[02:11] <jamesh> lucasvo: I've overhalled that form recently, so it will be a bit less confusing on next rollout.  See https://staging.launchpad.net/products/harmony/trunk/+source for an idea
[02:12] <mpt> ddaa, you don't want to hear the words that sabdfl hurled down my phone line when he discovered that bug this week. Or maybe you already have. Anyway, ETA? :-)
[02:12] <ddaa> mpt: I think stub landed a patch to fix 38598 and others
[02:12] <mpt> ah yes, I saw that
[02:12] <mpt> but is it shown in the UI?
[02:12] <ddaa> stub: can you confirm that it's fixed
[02:12] <mpt> I suppose it doesn't matter that much if it's not, I can add it
[02:12] <stub> The DB is fixed
[02:12] <mpt> thanks stub
[02:12] <ddaa> mpt: it's not shown in the UI, no plan to add that
[02:12] <mpt>  * Bug 44214
[02:12] <Ubugtu> Malone bug 44214 in rosetta "We need to add code to prevent POFiles being in the same path" [Critical,In progress]  http://launchpad.net/bugs/44214
[02:12] <ddaa> stub: is that fixreleased then?
[02:12] <stub> So any critical component is done (well... in rocketfuel)
[02:13] <stub> fixcommitted
[02:13] <mpt> carlos, progress?
[02:13] <lucasvo> jamesh, ddaa: I am talking about the little box Revision control details in the lower right corner
[02:13] <lucasvo> jamesh: it's the same on staging
[02:13] <mpt>  * bug 44808
[02:13] <Ubugtu> Malone bug 44808 in rosetta "Some translation templates in dapper don't contain any items" [Critical,Confirmed]  http://launchpad.net/bugs/44808
[02:13] <jamesh> lucasvo: please file a bug, we can talk about it after the meeting
[02:13] <mpt>  * bug 46982
[02:13] <Ubugtu> Malone bug 46982 in rosetta "Rosetta does not accept correct KDE plural forms when there are more than 2" [Critical,Confirmed]  http://launchpad.net/bugs/46982
[02:13] <mpt> oh, carlos isn't here
[02:14] <mpt> never mind
[02:14] <mpt> ok, so one more
[02:14] <mpt>  * bug 54241
[02:14] <ddaa> lucasvo: wow, you actually look at the portlets!
[02:14] <Ubugtu> Malone bug 54241 in launchpad "We need a script or tool that prunes OOPS logs from sodium" [Critical,In progress]  http://launchpad.net/bugs/54241
[02:14] <mpt> stub, do I remember you saying that wasn't Critical any more? or was that my imagination?
[02:14] <lucasvo> ddaa: I am quite a perfectionis. :) let's discuss itafter the meeting. didn't want to interrupt
[02:15] <stub> mpt: It isn't critical
[02:15] <stub> Erm... which bug are you talking about?
[02:15] <ddaa> lucasvo: there's indeed a display bug
[02:15] <mpt> stub, bug 54241
[02:15] <Ubugtu> Malone bug 54241 in launchpad "We need a script or tool that prunes OOPS logs from sodium" [Critical,In progress]  http://launchpad.net/bugs/54241
[02:15] <stub> Fixed committed, still critical. I'll update the bug now.
[02:15] <mpt> ok.
[02:16] <mpt> Sorry that took a bit longer than usual. My dirty little secret is that I usually prepare the bug report report during the first part of the meeting.
[02:16] <mpt> == Production and staging (stub) ==
[02:16] <mpt> thanks stub
[02:16] <mpt> and now, here's stub!
[02:16] <stub> Production cherry picks will happen tomorrow
[02:17] <stub> now that the oops pruner is running fine on staging
[02:17] <stub> So please add any outstanding ones to ProductionLaunchpadStatus now
[02:17] <stub> Nothing particularly thrilling happening otherwise.
[02:18] <stub> For those interested, a freshly restored Launchpad database now takes over 30 gig of disk space
[02:18] <stub> Up from 10 gig a few months ago
[02:18] <kiko> all carlos' fault
[02:18] <cprov> stub: too bad for mawson 
[02:18] <stub> thats pretty much it except for questions
[02:18] <mpt> ok, any questions?
[02:18] <mpt> 5
[02:18] <mpt> 4
[02:18] <mpt> 3
[02:19] <mpt> 2
[02:19] <stub> cprov: I know. I will need to start generating subsets of the production data for testing use
[02:19] <mpt> 1.41
[02:19] <mpt> 1
[02:19] <mpt> 0
[02:19] <mpt> thanks stub
[02:19] <jamesh> maybe we could drop the non-english langauges from rosetta
[02:19] <ddaa> stub: would it possible to cherrypick your datecreated patch in production?
[02:19] <elmo> stub: you'll not be running out of memory soon... :(
[02:19] <SteveA> Danilo txted me to say his router has broken, so he's offline.  He's working on fixing this.
[02:19] <cprov> stub: that's a good idea, spliting translation would be good 
[02:19] <stub> ddaa: Not without downtime
[02:19] <mpt> == Launchpad 1.0 status reports ==
[02:19] <flacoste> Support Tracker 1.0 Report
[02:19] <flacoste> --------------------------
[02:19] <flacoste> - SupportTrackerWorfklow: still in review
[02:19] <flacoste> - SupportTrackerViews: in review, one view is still unimplemented requiring SupportTrackerWorkflow
[02:19] <flacoste> - SupportTrackerHelp: started
[02:19] <mpt> go spammers
[02:19] <flacoste> - LocalizedSupportRequests: started, good progress.
[02:19] <flacoste> Other 1.0 Item
[02:20] <flacoste> --------------
[02:20] <flacoste> - DirectPersonRegistration: started
[02:20] <indu> cprov: hi, 
[02:20] <bradb> Malone 1.0
[02:20] <bradb> ----------
[02:20] <bradb> upstream-forwarding-workflow: Last part up for review since Monday.
[02:20] <bradb> series-and-distrorelease-mgmt: Discussed ConjoinedBugTasks with jamesh. Agreed on a solution.
[02:20] <bradb> guided-filebug-form: Handed off to kiko for general UI review.
[02:20] <bradb> removing-duplicate-comments: Status changed to implemented (but no new code written).
[02:20] <bradb> malone-essential-docs: No news.
[02:20] <bradb> simple-bug-keywords: No news.
[02:20] <ddaa> importd-bzr-native: done. More cleanups planned, but the scope of the spec has been exceeded already.
[02:20] <ddaa> supermirror-smart-server: Late, but good progress. Missed the bazaar meeting monday, so did not have spiv's status update. Dunno what's new since last week.
[02:20] <cprov> = Soyuz-1.0 Report =
[02:20] <cprov>  * PPA: blocked on ArchiveRework (still).
[02:20] <cprov>  * Archive Rework: slow progress, malcc
[02:20] <cprov>  * Code quality: slow progress, r=spiv on ftest for queue tool library
[02:20] <cprov>  * Openning Feisty in mawson, performance tests
[02:20] <cprov>  * Contents generation tests
[02:20] <cprov>  * Upgrade of apt-ftparchive in production, cache regeneration
[02:20] <cprov>  * General Fixing: #65052, #65589, #64840
[02:20] <cprov> indu: hey
[02:21] <ddaa> interesting exit message...
[02:21] <indu> cprov: did u understand my requirement clearly yesterday
[02:21] <mpt> So if danilos successfully returns, he can give us a Rosetta 1.0 report
[02:21] <mpt> in the meantime
[02:21] <mpt> == updating spec status ==
[02:22] <mpt> kiko, SteveA, was this supposed to be a separate item?
[02:22] <SteveA> yes
[02:22] <kiko> yes
[02:22] <SteveA> this is a note to everyone to say...
[02:22] <cprov> indu: yes, I think so ... can we talk after the meeting (in 20 minutes or so) ?
[02:22] <SteveA> update the status metadata of the specs you just posted about
[02:22] <mpt> (kiko, that's your cue)
[02:22] <SteveA> in launchpad
[02:22] <indu> cprov: ok
[02:23] <SteveA> and keep the status of specs up to date when you do some work on it, or reach a milestone with it
[02:23] <SteveA> that way, kiko and I have a good overview of how 1.0 work is going
[02:23] <kiko> mark Steve and I use the specs in our discussion of 1.0 progress
[02:23] <SteveA> and that makes it possible to discuss the progress well with mark
[02:23] <SteveA> anything to add kiko?
[02:23] <kiko> (and having up-to-date statuses will give much a better impression of our progress)
[02:23] <kiko> no, that's all -- as long as people do it :)
[02:24] <mpt> ok. Thanks SteveA, thanks kiko
[02:24] <niru> indu:hi
[02:24] <mpt> == Sysadmin requests ==
[02:24] <mpt> any important ones outstanding?
[02:24] <mpt> 5
[02:24] <mpt> 4
[02:24] <mpt> 3
[02:24] <stub> beta.launchpad.net
[02:24] <mpt> 2
[02:24] <indu> kiko: hi, after ur meeting is over, please ping me, i have something to talk with u
[02:24] <mpt> 1
[02:24] <SteveA> we now have /code/ on devpad
[02:24] <mpt> 0
[02:24] <SteveA> I mailed te launchpad list about that
[02:24] <mpt> stub, what number is that?
[02:25] <stub> Steve has it
[02:25] <mpt> ok.
[02:25] <stub> rt 17038
[02:25] <mpt> == Storing date_created and other dates and people related to state transitions ==
[02:25] <mpt> Whose is this? It has no name
[02:25] <SteveA> it had no  name on the MeetingAgenda page
[02:25] <SteveA> so, -ve karma to whoever added it
[02:26] <kiko> I can do it
[02:26] <SteveA> go for it kiko
[02:26] <mpt> that's what I meant, sorry
[02:26] <kiko> so mark was concerned when he noticed that branch lacked a date created
[02:26] <stub> Not me. But most things that should have date_created now do in the db, as do somethings that probably shouldn't
[02:26] <SteveA> stub: but, is it updated automatically when a thing is created?
[02:26] <stub> SteveA: yes
[02:27] <kiko> and would like to underline the point that keeping track of these dates lets us provide a history for our objects
[02:27] <jamesh> that's a simple default value for the column
[02:27] <SteveA> stub: nice
[02:27] <stub> Branch.date_created isn't really terribly useful, as it is the timestamp when the branch was added to Launchpad rather than when the branch was actually created (which is stored in the branch itself if anywhere)
[02:27] <_thumper_> what about a last_updated column too also kept up to date with triggers?
[02:27] <_thumper_> feasible? worthwhile?
[02:27] <kiko> so it's worth analyzing "your" part of the data model to see if there are other dates that are worth capturing
[02:28] <jamesh> stub: it allows us to get some feeling of how many branches get added over time
[02:28] <ddaa> worthwile, not a matter of triggers
[02:28] <jamesh> (but I suppose the cricket stats also help there)
[02:28] <kiko> bradb for instance more or less recently added a number of dates to the bugtask object
[02:28] <stub> _thumper_: Not unless people have use cases. Wider tables means more load on the db.
[02:28] <_thumper_> stub: fair enough
[02:28] <mpt> kiko, is that all?
[02:29] <kiko> yes
[02:29] <mpt> ok, thanks
[02:29] <stub> (Although the use case for date_created was Mark asked for it...)
[02:29] <ddaa> there's a use for that in the branch table though
[02:29] <mpt> == Approval for the new bounty-system tag to group bugs related to the bounty system (matsubara) ==
[02:29] <_thumper_> ddaa, later
[02:29] <ddaa> I was answering to this rather narrower question
[02:29] <matsubara> https://help.launchpad.net/TaggingLaunchpadBugs
[02:29] <stub> ddaa: If you want it, please file a bug so I don't forget. It is easy enough to do.
[02:30] <matsubara> I added the bounty-system tag a couple of weeks ago but forgot to mention it on previous meetings.
[02:30] <stub> ddaa: (add the trigger I mean. Although filing the bug is easy too ;) )
[02:30] <mpt> (Why not just "bounty"?)
[02:30] <SteveA> +1
[02:30] <kiko> bounty
[02:30] <ddaa> stub: nevermind, I think I just confused the issue
[02:30] <SteveA> mpt: because that could easily be confused with "this bug has a bounty on it"
[02:30] <matsubara> mpt: SteveA didn't like it.
[02:30] <SteveA> so, I am -1 on "bounty"
[02:30] <spiv> mpt: that could be confused with saying "there's a bounty for fixing this bug"
[02:30] <mpt> only if used outside of Launchpad!
[02:31] <SteveA> not only
[02:31] <mpt> outside of the launchpad project, I mean
[02:31] <stub> I  don't think it is confusing, as the tags are for us
[02:31] <mpt> Oh Well
[02:31] <jamesh> bounty-tracker then?
[02:32] <SteveA> fine
[02:32] <stub> It makes no difference whatsoever even if someone does mistake 'bounty' for 'there is a bounty on this bug' in the case of launchpad
[02:32] <mpt> ok, let's move on
[02:32] <SteveA> and, if in the absence of a bounty tracker, people use "bounty" for that elsewhere in launchpad
[02:32] <SteveA> then we'll have two distinct, but confusing, uses of the "bounty" tag
[02:32] <SteveA> so, as there are
[02:33] <SteveA> 1. very few bugs related to our bounty tracker
[02:33] <SteveA> and
[02:33] <SteveA> 2. a good reason to avoid confusion
[02:33] <mpt> There will always be distinct uses of various tags in different products
[02:33] <SteveA> I think "bounty-tracker" is the best suggestion
[02:33] <stub> There are 0 bugs in the Launchpad product with bounties, and that will remain the case for ever.
[02:33] <SteveA> mpt: yes, but not confusingly different like this.
[02:33] <SteveA> tags and their definitions are global
[02:33] <stub> Well... for some time
[02:33] <mpt> yet :-)
[02:33] <SteveA> and I thik we're getting into bikeshedding here
[02:33] <stub> tags don't have definitions
[02:34] <mpt> true, I plead guilty
[02:34] <jamesh> stub: yes
[02:34] <SteveA> they are meant to soon
[02:34] <jamesh> yet
[02:34] <mpt> ok, next
[02:34] <stub> Then tags cannot be global!
[02:34] <kiko> let's just use bounty-tracker
[02:34] <SteveA> global definitions
[02:34] <SteveA> thank you
[02:34] <mpt> == Keep, Bag, Change ==
[02:34] <kiko> and solve the deeper issue later
[02:34] <stub> BAG: global tags with definitions.
[02:34] <mpt> BAG: something else we don't have yet
[02:34] <mpt> 5
[02:34] <spiv> KEEP: 0 exceptions per day!
[02:34] <mpt> 4
[02:34] <mpt> 3
[02:34] <mpt> 2.78
[02:35] <mpt> 2
[02:35] <mpt> 1
[02:35] <mpt> 0
[02:35] <mpt> == Three sentences ==
[02:35] <ddaa> DONE: new svn changeset logic, thumper sprint, pyrex experiments
[02:35] <ddaa> TODO: thumper sprint, python import, svn rename support, hct removal
[02:35] <ddaa> BLOCKED: no
[02:35] <malcc> DONE: Little ArchiveRework. Fixed override publishing. Coded fix to death row db updates.
[02:35] <malcc> TODO: Land death row db update fix, ArchiveRework, sprint in Brazil
[02:35] <malcc> BLOCKED: No
[02:35] <mpt> More spam, please
[02:35] <flacoste> DONE: completed most of support-tracker-views
[02:35] <flacoste> TODO: land tt-workflow, tt-views branches, write support tracker help
[02:35] <flacoste> BLOCKED: waiting for review
[02:35] <bradb> DONE: Guided filebug. ConjoinedBugTasks. Pair-programming on the support tracker.
[02:35] <bradb> TODO: Put guided filebug up for review. Release management.
[02:35] <bradb> BLOCKED: kiko to review guided filebug UI.
[02:35] <matsubara> DONE: fixed #50816, fixed permission on +settopics page, finished #1558, oops report analysis.
[02:35] <BjornT> DONE: put up the last bits of upstream forwarding workflow for review.  code reviews...
[02:35] <spiv> DONE: reviews, WSGI backend for bzr smart server, fixing last critical issues in bzr HTTP smart server
[02:35] <jamesh> DONE: code review for stub, almost finished kikos.  ProductSeries refactoring landed.  Pagetest setup refactoring.  Other bug fixing
[02:35] <matsubara> TODO: more of the same, fix more oops bugs and finish #62423, land #1558
[02:35] <matsubara> BLOCKED: no
[02:35] <jamesh> TODO: code reviews.  FormLayout stuff.  Bugs 929 (wrapping), 2649 (displaying CVS branch entry on +source), 4557 (productrelease release date field).
[02:35] <jamesh> BLOCKED: no
[02:35] <Ubugtu> Malone bug 929 in launchpad "Long words (such as URLs) overflow columns" [Critical,Confirmed]  http://launchpad.net/bugs/929
[02:35] <mpt> DONE: mockups, calls, mockups, calls, mockups, calls, fixing bug 64080
[02:35] <_thumper_> DONE: reading, sprinting
[02:35] <_thumper_> TODO: more sprinting, looking at brances for specs
[02:35] <_thumper_> BLOCKED: nothing
[02:35] <mpt> TODO: actually implement stuff
[02:35] <mpt> BLOCKED: bug 65629
[02:35] <Ubugtu> Malone bug 64080 in launchpad "Highlighting of active application in facets menu has broken" [High,In progress]  http://launchpad.net/bugs/64080
[02:35] <spiv> TODO: reviews, bzr smart server hacking, smart server/supermirror integration
[02:35] <BjornT> TODO: more code reviews. prevent duplicate bug watches being added.
[02:35] <spiv> BLOCKED: no
[02:35] <BjornT> BLOCKED: no
[02:36] <kiko> DONE: some leave, get back on top of email, random management, heat up some old branches
[02:36] <kiko> TODO: more of the same, interviews
[02:36] <kiko> BLOCKED: jamesh to review rosetta patch
[02:36] <stub> TODO: PillarName traversal and url changes
[02:36] <stub> DONE: Blacklist, oops pruner
[02:36] <stub> BLOCKED: review of blacklist (needs to be in production so I can blacklist stuff I need to complete PillarName XXX's)
[02:37] <mpt> flacoste, who are you waiting for review from?
[02:37] <mpt> stub, who are *you* waiting for review from?
[02:37] <mpt> and jamesh, when will you review kiko's patch? (nag nag)
[02:37] <SteveA> DONE: relocate to NL, bzr launchpad sprints
[02:37] <SteveA> TODO: bzr launchpad sprint, ui work
[02:37] <SteveA> BLOCKED: no
[02:37] <flacoste> mpt: BjornT (but to his defense it's a huge patch) the other is unallocated
[02:38] <cprov> DONE: new a-f in production, open feisty test, dealing with bugs for feisty
[02:38] <cprov> TODO: finish fixes for feisty and soyuz BR sprint (ArchiveRework, NascenUpload \redesign)
[02:38] <cprov> BLOCKED: no
[02:38] <stub> mpt: James (who seems to be getting all of mine recently)
[02:38] <BjornT> mpt: i'm currently reviewing flacoste's patch, but it's taking quite a while to finish...
[02:38] <mpt> flacoste, has the unallocated one been in the queue for less than a day?
[02:38] <flacoste> mpt: yep
[02:38] <flacoste> mpt: it was put out yesterday
[02:39] <mpt> cprov, shush with those company secrets ;-)
[02:39] <mpt> flacoste, ok, so nothing out of the ordinary
[02:39] <flacoste> mpt: nope
[02:39] <SteveA> oh, one more note
[02:39] <SteveA> NO MORE HUGE PATCHES
[02:39] <mpt> jamesh, do you need to reallocate anything, or can you unblock stub and kiko shortly?
[02:39] <SteveA> when you're working on something, if you thinnk you'll have a diff of over 1000 lines to review
[02:39] <_thumper_> SteveA, what's a sensible limit?
[02:40] <SteveA> look at ways to make it in two landings
[02:40] <SteveA> or more
[02:40] <jamesh> mpt: I am most of the way through kiko's.  I'll get to stubs tomorrow.
[02:40] <mpt> jamesh, cool, thanks
[02:40] <cprov> mpt: ohh, I'm sorry ..
[02:40] <SteveA> so that the work can be reviewed in reasonably small chunks, so a reviewer can keep the diff in their minds, so that they can offer better review advice
[02:40] <SteveA> than just PEP-8 conformance etc.
[02:40] <SteveA> now, splitting up work like this is a *skill* -- it needs practice, it needs to be learned and studied
[02:40] <mpt> and more easily see whether each change has a matching test, etc
[02:41] <SteveA> so, talk to your reviewer as you embark on some work
[02:41] <ddaa> well, I can split my patch just about anywhere in the history
[02:41] <SteveA> and ask for advice on how to split it up into cohesive unites
[02:41] <ddaa> if reviewing it is a problem
[02:41] <kiko> jamesh, is it that bad? :-(
[02:41] <SteveA> ddaa: COHESIVE UNITS
[02:41] <ddaa> SteveA: they are cohesive
[02:41] <ddaa> all tdd and refactoring
[02:41] <kiko> refactorings are hard
[02:41] <kiko> I agree with ddaa there
[02:42] <SteveA> ddaa: then that is good
[02:42] <kiko> but new features can almost always be factored into separate parts
[02:42] <mpt> danilos, welcome back
[02:42] <SteveA> kiko:  you agree with ddaa on what?
[02:42] <malcc> ArchiveRework is a bitch to split up, and it's 5000+ lines at the moment; but I'm aiming to review it with celso and kiko in person next week in Brazil
[02:42] <kiko> sometimes refactorings can be done in parts
[02:42] <mpt> ok, three minutes left, and two things left to do, so please discuss refactorings after the meeting
[02:42] <danilos> mpt: yeah, thanks, though I am on backup right now
[02:42] <malcc> Hopefully in-person interactive review will help make it not just a vast meaningless diff for a random reviewer to stare at while they cry onto their keyboard
[02:42] <mpt> == Next meeting ==
[02:43] <mpt> (which I somehow forgot earlier)
[02:43] <malcc> Next week
[02:43] <malcc> ?
[02:43] <mpt> Anyone who can't make same time, same channel, next week?
[02:43] <mpt> 5
[02:43] <mpt> 4
[02:43] <mpt> 3
[02:43] <mpt> 2
[02:43] <mpt> 1
[02:43] <danilos> DONE: Firefox tests, OOo started, stuff for visa, new contract
[02:43] <danilos> TODO: Put ff and ooo up for review, search, USA visa
[02:43] <danilos> BLOCKED: no
[02:43] <danilos> (my late 3 sentences)
[02:43] <mpt> thanks danilos
[02:43] <mpt> And finally
[02:44] <SteveA> malcc: I recall that there was a proposal to use interfaces or something to ease the ArchiveRework refactoring
[02:44] <mpt> danilos, do you have a Rosetta 1.0 progress report handy?
[02:44] <danilos> and rosetta 1.0 report
[02:44] <lucasvo> ddaa: about that bug, should I file a report?
[02:44] <danilos> sure, just coming mpt :)
[02:44] <danilos> Rosetta 1.0 weekly report:
[02:44] <danilos> - opening edgy for translation: DONE
[02:44] <danilos> - firefox import/export: to put up for review after more tests (will ask for cherry pick)
[02:44] <danilos> - oo import/export: started
[02:44] <danilos> - translation review: like last week
[02:44] <danilos> - essential docs: no progress this week
[02:44] <danilos> - search: not started
[02:44] <danilos> - checks not to upload wrong language PO file using "too many changes" check: not started
[02:44] <danilos> - ui fixes: mpt on those
[02:44] <danilos> - outstanding issues: none
[02:44] <danilos> (for translation review: carlos is vacationing)
[02:44] <ddaa> lucasvo: yeah, that would be good
[02:44] <SteveA> malcc: in any case, there are ways to plan a refactoring into small parts.  lifeless is an expert on this, so schedule a call with him sometime to discuss the principles behind it.
[02:44] <lucasvo> and also I wanted to know what this screenshot url is about.... One can enter one but it doesn't seem to show up anywhere
[02:44] <mpt> Thank you danilos.
[02:44] <mpt> and on that note
[02:44] <ddaa> lucasvo: looks  like a simple oversight, easy to fix
[02:44] <mpt> MEETING ENDS
[02:44] <mpt> thank you everybody
[02:45] <ddaa> I've got a new minion on my left to handle it
[02:45] <SteveA> thanks for running the meeting efficiently and to time, mpt
[02:45] <danilos> thanks mpt, guys, sorry about me missing most of it
[02:45] <_thumper_> minion, pah!
[02:45] <malcc> Bang on time, nice
[02:45] <mpt> danilos, I'll try to get the notes up later today so you can read them
[02:45] <danilos> mpt: sure, thanks
[02:46] <flacoste> matsubara: we had an edit conflict on PendingReviews yesterday: https://launchpad.canonical.com/PendingReviews?action=diff&rev2=2986&rev1=2985
[02:46] <mpt> stub, by "Production cherry picks will happen tomorrow", did you mean there won't be a full rollout?
[02:47] <mpt> (in the coming week)
[02:47] <lucasvo> bug 65585
[02:47] <Ubugtu> Malone bug 65585 in gaim "gaim doesn't stop flashing in taskbar." [Unknown,Unknown]  http://launchpad.net/bugs/65585
[02:47] <lucasvo> bug 65584
[02:47] <stub> mpt: I don't know about next week yet. Do we need one?
[02:48] <lucasvo> the database of staging and normal are synced?
[02:48] <mpt> stub, no, I just wanted to know whether I needed to request a cherrypick or not
[02:48] <stub> mpt: If there are two many cherry picks, there might be a full rollout tomorrow. I like to remain flexible ;)
[02:48] <lucasvo> anyone know http://usefulinc.com/doap ?
[02:48] <mpt> stub, also, s/ProductionLaunchpadStatus/LaunchpadProductionStatus/ :-)
[02:48] <stub> (or is that indecisive?)
[02:49] <stub> lucasvo: The staging database is normally synced with the production database each day.
[02:49] <lucasvo> oh, damn, I reported an LP bug accidentally on staging
[02:50] <lucasvo> ddaa: https://staging.launchpad.net/products/launchpad/+bug/65584
[02:50] <jamesh> lucasvo: please file it again on the main server -- the staging db gets wiped each day and no bug mail gets generated
[02:51] <matsubara> flacoste: sorry about that. I use editmoin to edit the wiki pages and didn't get (or didn't notice) any warnings.
[02:51] <flacoste> matsubara: no harm done
[02:51] <jamesh> BjornT: got time for a zope related question?
[02:52] <lucasvo> bug 65584
[02:52] <lucasvo> bug 65661
[02:52] <Ubugtu> Malone bug 65661 in launchpad "Revision control details box does not work correctly" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65661
[02:55] <kiko> stub, have a moment?
[02:55] <stub> kiko: Sure
[02:55] <Ubugtu> New bug: #65660 in malone "Activity log does not show targetting for releases" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65660
[02:58] <BjornT> jamesh: sure
[02:58] <ddaa> jamesh: is that you that added the bazaar branch in the productseries portlet?
[02:59] <jamesh> BjornT: was looking at the proposed implementation of the FormLayout spec
[02:59] <jamesh> ddaa: I added the registered Bazaar branch to the details portlet -- I didn't update the revision control details portlet
[03:00] <ddaa> I think the branch needs not be advertised in the details portlet
[03:00] <Ubugtu> New bug: #65661 in launchpad-bazaar "Revision control details portlet does show bzr branch" [Medium,Confirmed]  http://launchpad.net/bugs/65661
[03:00] <jamesh> BjornT: it proposes using views on the widgets to handle the layout.  I was wondering if there is a standard way to get access to the "main" view class from a subview like this
[03:01] <jamesh> BjornT: given that we are currently managing per-field errors in LaunchpadFormView.
[03:01] <ddaa> it's much less important than the other bits of information there. And it needs not be duplicated in the revision control details portlet
[03:01] <jamesh> ddaa: it would be good to move it over then.
[03:02] <ddaa> okay, I think I could whip up a small fix for that this afternoon
[03:02] <ddaa> unless _thumper_ wants to beat me to it
[03:02] <ddaa> _thumper_: ?
[03:04] <BjornT> jamesh: no, i can't think of some standard way of doing it. using views will probably be hard while doing per-field errors in LaunchpadFormView.
[03:05] <_thumper_> ddaa: yeah I want to beat you
[03:05] <_thumper_> ddaa: oh, you mean fix the bug?
[03:05] <ddaa> great
[03:05] <Ubugtu> New bug: #65663 in launchpad "LP asks for screenshot url but doesn't use it (yet)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65663
[03:05] <jamesh> BjornT: I suppose storing the custom errors in a "launchpadformview_error" attribute (or similar) on the widget would be bad
[03:05] <ddaa> I suggest we have a game of barbarian tomorrow to help your release your aggresivity
[03:06] <ddaa> but first you can put it to good use by sublimating it into a bugfix
[03:06] <jamesh> BjornT: I see the widget instances don't get security wrapped so it would work, but it seems pretty ugly
[03:07] <BjornT> jamesh: yeah. i think keep using macros would be better until we can come up with a better solution.
[03:08] <jamesh> BjornT: okay.  I guess a few helper methods on LaunchpadFormView that check for the marker interfaces would be appropriate.
[03:09] <jamesh> I guess this is the point where we'd be forking the widget macros for new style vs. old style forms
[03:10] <kiko> bradb, what was the spec about new bug statuses that simon and you discussed?
[03:12] <bradb> kiko: https://launchpad.canonical.com/BugWorkflow
[03:12] <kiko> thanks
[03:13] <indu> kiko: hi, can i talk to u now?
[03:13] <kiko> indu, sure, one moment.
[03:14] <_thumper_> stub: is there a read only db user for production database for queries?
[03:14] <ddaa> wow
[03:14] <ddaa> you mean complete read-only access?
[03:14] <stub> _thumper_: Yes, but you don't have access to it and won't unless you have a good use case for needing that access to the live production system
[03:14] <_thumper_> ddaa: yeah I get nervous sometimes
[03:15] <ddaa> that's very high level of privilege
[03:15] <_thumper_> stub: there a copy that I can get access to?
[03:15] <_thumper_> don't really need production
[03:15] <ddaa> gives you access to hashed passwords, private bugs, etc...
[03:15] <_thumper_> just similar data
[03:15] <indu> kiko: ok
[03:15] <stub> The staging database is generally used for that.
[03:16] <danilos> hahaha, the Big Brother video stream is what has fucked up my ISP
[03:19] <indu> ok kiko, i think u r busy today, i have to leave, i mailed u about my doubt. please reply me for that
[03:20] <kiko> indu, okay, I'll do that. thanks
[03:20] <kiko>  65290 Bugs
[03:20] <kiko> wow
[03:21] <stub> kiko: I think there are about 200 products using Malone as their official bug tracker now (although the bulk of the bugs are of course the distro)
[03:22] <kiko> yeah, quite remarkable
[03:23] <stub> Not much choice for people who don't want to or can't maintain their own bug tracker, and Launchpad is already better than most.
[03:25] <kiko> bradb, you know the "From duplicates" section in the subscribers portlet?
[03:26] <bradb> kiko: i do
[03:26] <kiko> bradb, why does it not show up in https://staging.launchpad.net/distros/ubuntu/+source/xserver-xorg-video-ati/+bug/47775 ?
[03:26] <Ubugtu> Malone bug 47775 in xserver-xorg-driver-ati "[dapper]  xrandr freezes the system (radeon, MergedFB)" [Undecided,Unconfirmed]  
[03:28] <kiko> bradb, is it because goodyheadedpunk directly subscribed to that bug?
[03:28] <kiko> what about ubuntu bugs?
[03:29] <bradb> kiko: yeah, direct subs take preference
[03:29] <kiko> thanks.
[03:34] <ddaa> BjornT: did you start reviewing my partial-copy branch?
[03:34] <ddaa> BjornT: I can split it in two pretty easily, there's a very natural splitting point just after the improved replace support
[03:37] <BjornT> ddaa: no, i haven't started yet. i've been busy with another big branch.
[03:37] <ddaa> BjornT: okay, I'll split it up then
[03:38] <BjornT> that's good.
[03:38] <ddaa> BjornT: if you want I can make the first part landable independently, but it would need a bit more doing
[03:38] <ddaa> since there is a couple of new acceptance tests at the beginning that only pass very close to the end
[03:39] <ddaa> BjornT: is that okay if I just split them for review, or do you prefer if I make the first one landable alone?
[03:40] <BjornT> ddaa: i'm happy as long as it makes it easier to review.
[05:03] <flacoste> can a team be authenticated?
[05:04] <flacoste> consider the following use case: I register a team as support contact for my product, the team address is a mailing list
[05:05] <flacoste> hmm, no, that would be too complicated to work... nevermind
[05:27] <ddaa> BjornT: done, partial-copy-part-one is still > 1k lines, I can break it further if you wish, but then there is a big block of test code and plumbing at the beginning that accounts for a lot of the new lines and that's not really meaningful to break.
[05:28] <ddaa> to clarify, I can break it further, but it will not put it below 1k lines
[05:29] <ddaa> besides, I assume it more pleasant to see a patch that deletes a bunch of old shit using the new code
[05:31] <ddaa> mh
[05:31] <ddaa> nevermitd
[05:31] <ddaa> nevermind
[05:35] <_thumper_> ddaa: a question 
[05:35] <ddaa> A question...
[05:35] <_thumper_> irl
[05:35] <ddaa> since before your sun burnt hot in space
[05:35] <ddaa> and before your race was born
[05:35] <ddaa> I have been waiting
[05:36] <ddaa> A question!
[07:02] <malcc> So I've got this bug: https://launchpad.net/products/soyuz/+bug/65712 and this fix: https://devpad.canonical.com/~andrew/paste/filesu0WxL.html
[07:02] <Ubugtu> Malone bug 65712 in soyuz "Queuebuilder does the wrong thing when PAS changes" [Undecided,Unconfirmed]  
[07:02] <malcc> I've tested the fix by hand, but I'm not sure how to write a proper test for it, does anyone have any wisdom to offer?
[07:06] <SteveA> BjornT: ping
[07:15] <Ubugtu> New bug: #65712 in soyuz "Queuebuilder does the wrong thing when PAS changes" [High,In progress]  http://launchpad.net/bugs/65712
[07:34] <BjornT> SteveA: pong
[08:10] <pygi> hello, would someone enlighten me and tell me can we do trac --> LP migration?
[08:18] <matsubara> bradb: ping
[08:18] <bradb> matsubara: pong
[08:18] <matsubara> bradb: is there any reason for SecurityContactEditView to inherit from LaunchpadFormView instead of LaunchpadEditFormView?
[08:20] <bradb> matsubara: not that i can think of
[08:22] <matsubara> bradb: ok, cool thanks.
[08:22] <bradb> np
[10:01] <Ubugtu> New bug: #65736 in malone "Also notified makes difficult to find the bugs I am subscribed to" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65736
[10:11] <Ubugtu> New bug: #65741 in malone "Double email to inform of duplicate bug" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65741
[10:37] <claude> hmmm, hi all
[10:37] <claude> i cannot upload anymore a .po file for help-eog :(
[10:38] <claude> i even don't see the file in the import queue 
[10:39] <claude> maybe could i send the file to some admin here ?
[10:41] <claude> i tried either as user or published upload (it's a published one), no luck :-(
[10:44] <matsubara> hi claude, could you file a support request fully describing your problem here: http://launchpad.net/products/rosetta/+addticket and assigne it to me. I'll look for a Rosetta admin tomorrow to check what's going on. Is that ok?
[10:44] <claude> great, thanks matsubara
[10:45] <matsubara> claude: no problem
[10:49] <claude> https://launchpad.net/products/rosetta/+ticket/2058
[10:52] <claude> fyi, i cannot assign the ticket to you
[10:54] <flacoste> claude: you have to use 'Edit Request' for that
[10:54] <claude> the edit form don't let me do this
[10:54] <claude> just edit the message
[10:54] <flacoste> claude: you're right! it's on the administer menu which you probably don't have permission to access
[10:55] <claude> right :-)
[10:55] <flacoste> claude: i'll take care of the assignment
[10:55] <claude> merci
[11:04] <flacoste> claude: de rien