[12:19] spiv: reviews for you please [12:19] spiv: they are sqlobeject which I know you know [12:21] lifeless: Ok. [12:25] thanks! === ilmari [i=ilmari@ritchie.ping.uio.no] has joined #launchpad === ilmari [i=ilmari@ritchie.ping.uio.no] has left #launchpad [] [12:43] spiv: reviewed your branch === poningru [n=poningru@pool-71-243-228-54.tampfl.fios.verizon.net] has joined #launchpad [12:45] Thanks [12:45] I admire your time travel machine === doko_ [n=doko@dslb-084-059-064-159.pools.arcor-ip.net] has joined #launchpad === mpt [n=mpt@210-55-36-159.dialup.xtra.co.nz] has joined #launchpad [01:26] Goooooooooooooooood afternoon Launchpadders! [01:28] mpt: hey [01:28] mpt: back in .nz ? [01:28] mpt: so the branch I was asking about is still listed in 'baz' format. You need to convert its entry in pending reviews [01:29] lifeless, I realize that, which is why I was asking if pqm was off chinstrap yet [01:30] I suppose I could convert just that branch and not my others [01:30] mpt: yes, pqm is off chinstrap [01:30] okie [01:32] and yes, I'm back in NZ, and partly recovered from jetlag === salgado [n=salgado@201-27-6-196.dsl.telesp.net.br] has joined #launchpad === stub yawns [01:54] hi salgado [01:55] morning stub [01:56] yo mpt [01:57] hi lifeless [01:57] lifeless: I replied to your email a few minutes ago [01:59] thanks [02:05] mpt@chinstrap:/home/warthogs/archives/mpt $ /home/warthogs/source/bzr.integration/bzr baz-import ./launchpad/2005-09-menus ../mpt\@canonical.com/launchpad--menus--0509 ../rocketfuel [02:05] bzr: ERROR: pybaz.errors.NamespaceError: invalid archive name: ../mpt@canonical.com/launchpad--menus--0509 [02:05] at /home/pqm/source/pybaz/pybaz/_builtin.py line 744 [02:05] in __init__ === mdke_ is now known as mdke [02:08] mpt: no ../ [02:08] mpt: baz archive names are not paths per se [02:09] except when they are [02:09] and they're not here :[ [02:20] lifeless, I get the same error removing either or both of the ../s === mpt clearly needs more sleep [02:22] mpt: you probably want "bzr baz-import-branch ../launchpad/2005-09-menus mpt@canonical.com/launchpad--menus--0509 ../rocketfuel" [02:22] to import a single branch [02:22] oh, I got it now I think [02:23] hmm, no === tambaqui [n=patricia@200-208-63-72-mns.cpe.vivax.com.br] has joined #launchpad [02:23] actually, remove that first "../" bit [02:24] well done jamesh :-) [02:24] I missed the -branch bit [02:24] lifeless: would you like to talk about that refactoring now? [02:25] bzr: ERROR: bzrlib.plugins.bzrtools.baz_import.NotPreviousImport: /home/warthogs/archives/mpt/launchpad/2005-09-menus is not the location of a previous import. [02:25] arn't you on holidays yet salgado? [02:26] stub: not yet. it starts on the 26th === stub thought 22nd [02:27] hmmm. maybe the note I added to the PendingReviews is wrong? [02:29] no - I just can't read [02:29] stub: if you've got a bit of time, could you do a quick review on https://chinstrap.ubuntu.com/~jamesh/pending-reviews/jamesh/launchpad/ErrorReportManagement/full-diff? [02:29] or am confused [02:29] Sure [02:30] it's mostly deletes :) [02:35] If ErrorData.count was a property, you could have used the new sort() form avoiding a lambda. But I wouldn't bother changing it. [02:40] salgado: in 5 minutes if thats ok [02:40] mpt: is it a new dir, an empty dir, or something else ? [02:41] jblack: daf: LaunchpadHackingFAQ - can one of you update the bazaar instructions there to bzr ? [02:41] (but let me finish my stuff first !) [02:45] jamesh: It will need a command line argument limiting the number of days in the past the report is generated for. I can imagine we will acumulate months or years worth of exceptions on chinstrap for histerical reasons, but we really are only interested in reporting on the last week. [02:45] jamesh: Otherwise r=stub [02:49] stub: you pass the yyyy-mm-dd directories as arguments to the script [02:50] stub: so if I only pass the last week of dates, it will generate a report on the last week's errors [02:50] 2005-12-* will give a december report [02:50] salgado: ok [02:50] We can't really cron that [02:51] that's a point. [02:51] I think the reports have been done manually up til now [02:52] lifeless: after all the changes I've done, what we have left are DistributionMirrorEditView.doSchemaValidation() and DistributionMirrorAddView.doSchemaValidation() which are exactly the same code [02:52] but one is in distribution.py and the other is in distributionmirror.py [02:52] but both are DistributionMirror*.doSchemaValidation [02:53] because the contexts of each view are not the same --one is a DistributionMirror and the other is a Distribution [02:53] why are not both forms in distributionmirror.py ? [02:53] I usually place all views that share the same context in the same file [02:53] I can tell you what my instinct says to do here [02:54] but I suspect we need stevea to weigh in [02:54] they are both called 'Di..Mirror?View' [02:55] so I would expect both to have a DistributionMirror as a context. the Add would get a NullDistributionMirror which it would only use to grab the Distribution object from, the other would have a real DistributionMirror [02:55] I think that Mark did something like that for new objects [02:55] create-on-the-fly. [02:55] hmmm. I never heard of it [02:55] but if we dont have that facility handy, then I would still put them both in distributionmirror.py [02:56] and the schema validation does not look at context, so its fine. [02:56] if however that goes against current layout requirements (it may) [02:56] then I would extract the schema validation logic to a new object - a 'schema' [02:57] and in both forms call 'DistributionMirrorSchema.validate(form_fields)' [02:57] in doSchemaValidation [02:57] BjornT: around? does z3 have something like this built-in ? [02:58] that could even live in interfaces/distributionmirror.py, I guess [02:59] could do. I don't know the z3 idioms well enough to really comment there. [02:59] or maybe interfaces/validators.py. [02:59] yes, that seems to be the right place [02:59] that sounds more like it to me [03:00] I can even move it there and keep the two view classes into different files, in case I'm right and we should actually place views that share the same context in the same file [03:00] maybe spiv can help us here? [03:00] spiv: ^^ [03:04] There is a schema validation example in lib/zope/schema/README [03:04] .txt [03:06] Stuff under interface is just interface, and schemas are extensions of interfaces. Interface validation (IFoo.providedBy(obj) ) doesn't do enough === stub wonders wtf they want to validate the object's __dict__ rather than the object, which screws properties [03:08] eh? [03:09] Ignore all that - the README.txt is broken and science fiction (at least in our Z3 release) [03:11] Oh... lifeless was using 'schema' in a different sense, which is naughty because it is a loaded term in Z3 development [03:15] stub: sorry [03:17] lifeless: what about https://chinstrap.ubuntu.com/~dsilvers/paste/file8YXEAN.html in interfaces/validation.py? [03:17] for now, yes [03:18] it can land like that,but I really want to get stevea to eyeball the approach [03:18] I don't plan to land it now, so I can talk to steve this morning [03:18] ok [03:18] personally I'd have done a class [03:18] with a validate method [03:19] but thats because I am allergic to context-free-contextual-methods === gneuman [n=agboa@200-158-86-38.dsl.telesp.net.br] has joined #launchpad [03:20] lifeless, salgado: Hmm, what can I do for you? [03:20] spiv: first question: should we always try to keep view classes that share the same context in the same file or this is not important? [03:21] Merge to devel/launchpad: more ErrorReportManagement updates, r=stub (r2937: James Henstridge) [03:21] Well, the important thing is that it should be easy to find code. [03:22] Grouping view classes by context object is a good way to do that, but I'm not sure that it's an absolute rule. [03:22] What's the alternative you're thinking of? [03:24] spiv: the view name. for instance, I have DistributionMirrorAddView and DistributionMirrorEditView [03:24] they don't have the same context --one has a Distribution as context while the other has a DistributionMirror [03:25] The existing convention for FooAddView is that they are kept in browser/foo.py [03:26] E.g. BugAttachmentAddView's context is a Bug, but it's in bugattachment.py [03:26] Which is where I first thought to look, without really thinking about it very hard :) [03:26] ahha! [03:26] my instinct was right :) [03:27] So I think both DistributionMirrorAddView and DistributionMirrorEditView would belong in browser/distributionmirror.py [03:28] spiv: the same is valid for the zcml of the page that uses the view? (in our case the zcml for the page that uses FooBarAddView would be in bar.zcml although the context is a Foo) [03:31] salgado: The existing convention for zcml is a bit different, it seems. [03:31] So e.g. BugAttachmentAddView is in bug.zcml, not bugattachment.zcml. The ZCML seems to be strictly grouped by context object. [03:32] I'm not sure if this was a conscious decision or not, but I'd be consistent with what we have, and talk to Steve and/or mail the list if you think it's worth changing the groupings of things in browser/ and zcml/ to be consistent. [03:33] I don't think it's worth changing, but I'll talk to Steve and try to get this formalized somewhere. I think this is something important to have [03:33] agreed [03:33] anyway, for now, I agree with you, we should be consistent with what we have === salgado needs to sleep now. see you guys in a while === salgado is now known as salgado-zzz [03:41] salgado-zzz: FWIW, I agree, I think it's fine as-is too. It would be good to have this formalised, possibly in the README.txts in the relevant directories. === mpt [n=mpt@210-55-36-130.dialup.xtra.co.nz] has joined #launchpad === mdke [n=matt@ubuntu/member/mdke] has joined #launchpad === bradb [n=bradb@S01060014bf4ac6aa.wp.shawcable.net] has joined #launchpad === Mez [n=Mez@ubuntu/member/mez] has joined #launchpad === Wolever [n=wolever@HSE-Montreal-ppp133816.qc.sympatico.ca] has joined #launchpad [04:58] Would this be the right place to come for help with Launchpad problems? [04:59] yes [05:00] Allright, well, I had an account with the old Ubu ShipIt, then they switched over to Launchpad and my account did not work anymore. I just tried to create a new account (with the same e-mail address) and I still can't login (if I click the forgot password link, it tells me that my account details have not been found) [05:10] Wolever: What email address did you try to register on Launchpad with? [05:20] wolever@ftml.net [05:23] Wolever: No record of that in the system. I suspect you didn't successfully complete the registration form or something got lost in transmission. [05:24] stub: Hrm, stange. I'll try registering again and see if that fixes anything. [05:24] There are several other @ftml.net addresses in there, but none resemble yours [05:24] Ah, ok... [05:26] This is looking better... The first time I registered it didn't log me in afterwards =\ [05:26] Horra! It works [05:28] Thanks for the help. [05:44] http://www.bitpress.com/atari/prog.mov [05:44] err [05:44] wrong window =\ === mpt [n=mpt@210-54-127-78.dialup.xtra.co.nz] has joined #launchpad === stub [n=stub@costello.z3u.com] has joined #launchpad === marcolu [n=marcolu@61.151.243.154] has joined #launchpad === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad === stub [n=stub@costello.z3u.com] has joined #launchpad [07:21] Merge to devel/launchpad: [trivial] Update pgrestore.py to restore PostgreSQL 7.4 dumps under PostgreSQL 8.0 (r2938) [08:01] hi [08:06] hi SteveA [08:08] hello jamesh [08:08] i just replied to your review of mpt's capitalization branch [08:08] i want to keep all source code files in launchpad in ascii [08:09] that should be part of the coding standards [08:10] SteveA: how about page tests? [08:11] some of his changes were to switch from straight to curly quotes in the page test output [08:11] I'm not sure how you'd handle that differently though [08:22] these cause some problems [08:22] comparing non-ascii in the pagetest output has caused problems for kiko before [08:22] SteveA: what prevents us using utf8? (I presume that ascii is a means to an end not an end itself) [08:23] i think we ended up doing output = http(....) ; '\{curlyquote} blah blach {curlyquote}' in output; True [08:24] lifeless: if we start using utf-8 in source files, then we get various problems. characters start appearing in source files that aren't what they appear to be at first glance. [08:24] such as quotes that aren't the quote character [08:25] output of things like diffs that pass through various systems gets mangled [08:26] it's not like this is a new thing. the coding standard for launchpad has always been ascii-only source files. [08:26] I was just curious [08:26] if we want to change this, we should do so in a well-considered way, and not just because mpt wants it for curly quotes [08:26] or scott wants it for the copyright-c-circle symbol [08:26] as, AFAIK, our entire toolchain these days is utf8 safe [08:27] i remain sceptical, but i'd like to be proved wrong. [08:27] I don't particularly care myself ;). [08:27] but, even so, my point about having characters that don't look as they appear to be stands [08:27] once i redid some tests that daniel had written [08:27] if we have time at some point, get can look into testing the toolchain we care about [08:28] they were testing that something took appropriate unicode input and did the right thing with it [08:28] these tests were in utf-8 encoded source files [08:28] using, in the source file, various different unicode features such as combining diacritics [08:28] do you want an ascii lint enforced on commit to pqm ? [08:29] so that when reading the tests, even in a utf-8 capable editor, it wasn't clear what the input was [08:29] nor how to maintain it, unless you're a utf-editor-jockey [08:29] i don't think we need an ascii lint. having it in the coding standards is enough [08:30] and there may be exceptional cases were we want to use it [08:30] an example would be a module written externally that we want in the 'contrib' package [08:30] I think its the sort of thing that people forget [08:31] and doing what we have done before, with a list of exceptions, and a check, would provide a small safety net with documentation. [08:31] do you think ascii lint would be a good thing? [08:31] yes. It lowers the things people can get wrong by mistake. [08:31] then sure, go ahead [08:32] I'll open a bug [08:32] I think its a low-priority thing [08:34] ok [08:34] bug 6065 [08:34] Malone bug #6065: non-ascii files should be checked for before pqm commits In: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/6065 === xester good morning === tomatox [n=tomatox1@a84-231-196-83.elisa-laajakaista.fi] has joined #launchpad [08:58] spiv: ping? [08:58] jamesh: pong [08:59] spiv: was the selectOne() usage really that weird? It seemed pretty natural to me [09:00] jamesh: Well, it seemed weird to me. :) But, I'm not sure it really is that weird. [09:00] jamesh: Which is why I suggested asking a few other people and seeing what they think. [09:00] I'm happy to readjust my brain if it makes sense to other people. [09:09] I believe Unicode aware editors are free to change the normalization if they feel like it, which will break tests doing byte comparisons. === mpt [n=mpt@210-55-161-137.dialup.xtra.co.nz] has joined #launchpad [09:13] Bug 5156 [09:13] Malone bug #5156: baz-import fails with AttributeError In: bzr (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5156 [09:14] lifeless: If baz-import bzr or bzrtools? [09:17] bzrtools, iirc [09:19] Bah - no bzrtools product in Launchpad anyway [09:20] create one then :) [09:23] Probably better in bzr anyway - most likely it is a bzr version thing. Just thinking of reasons it might now have been triaged for three weeks (I could, but that would be rude). [09:28] stub: what's your opinion on using selectOne() with a query that would return multiple results but you've used limit=1? [09:28] Fine [09:29] Actually I'll qualify that. Fine if you have used an ORDER BY clause guaranteeing what result will be retrieved. Or tests will blow up. [09:31] sure. [09:58] i think that a limit of 1 or no limit is all that makes sense [09:59] the case where there's a limit of 1 and an orderby clause is really saying selectFirst [09:59] so maybe it is confusing to use selectOne for this [09:59] selectFirst would have a limit of 1 hardcoded, and would require an orderby [10:00] and selectOne can remain simpler === SteveA wonders what stub and jamesh and spiv think === stub shrugs [10:02] I don't see much gain having selectFirst around - may be more precise, but adds another method to remember when to use. [10:04] i'm reading spiv's original code review of jamesh's changes. spiv said that it took him a while to see what was going on with using selectOne to get the first result. [10:04] selectOne we introduced because select(...)[0] was a common idiom and hid bugs [10:04] i think selectOne's specific semantics should be for cases where the application says there should only ever be one or zero results [10:05] selecting the first only doesn't fall into this usecase, except in one edge-case [10:05] which is exactly what is happening when you have LIMIT 1 in your query, which is a common idiom [10:05] (eg. "SELECT foo FROM bar ORDER BY foo LIMIT 1" is a common way of retreieving the smallest foo) [10:06] i think application code reads more clearly using selectFirst than selectOne with a limit. [10:06] i'm interested to hear other opinions. [10:06] I'm -0 anyway. Not particularly fussed [10:07] i guess selectOneOnly is what i mean [10:08] daf: hello, around? [10:08] SteveA: the cases I used selectOne with limit were cases of "get the smallest" or "get the newest" or similar [10:08] (well, the code was already doing that [10:08] I think selectFirst would be correct, which simply does assert orderBy is not None and returns selectOne (limit=1) if you want something like this. [10:09] spiv: does selectFirst() with stub's semantics sound good? [10:09] I agree that the only values of limit that make sense for a select-with-single-result function are None and 1 [10:09] i'd expect selectOne to have the options of limit=2 or limit=1, but no others. [10:10] because, if you get 2, then it's an error [10:10] limit 2? [10:10] ah. [10:10] so, rather than putting 'limit' into selectOne [10:10] Hmm... that actually could be a good optimization on the PostgreSQL end... [10:10] the semantic is "error_on_multiple_results=True" as the default we're using [10:11] i'm surprised we're not using limit=2 already for selectOne [10:11] so, i suppose my concern is this: [10:11] right now, we use selectOne in a way where we expect it to give an error if we get 2 or more results [10:11] (or maybe not - it is a rare case where PostgreSQL doesn't already know only one result will be returned due to UNIQUE indexes) [10:12] (but it wouldn't hurt) [10:12] and passing in limit=1 is changing that "error on multiple results" behaviour by telling postgres to only sent a maximum of one result [10:12] i feel uncomfortable about that because it is mixing up the layers [10:12] although it does get the job done [10:13] and that unfomfortableness is what led me to suggest selectFirst [10:13] which would never give that "more than one result" error [10:13] It is all perfectly clear if you look at it from the SQL end ;) [10:17] SteveA: hi [10:17] so, selectFirst() then? [10:20] daf: want to do more rosetta bug stuff on voip today? [10:20] jamesh: i'd like to get spiv's opinion, as he originally brought it up === koke [n=koke@ubuntu/member/koke] has joined #launchpad [10:21] SteveA: I do want to, but I've left my headset in Cambridge [10:22] darn. we can use irc in any case [10:22] or even one-way skype ;-) [10:22] :) [10:24] I'm going to grab some breakfast quickly [10:24] how about now + 15? [10:24] I've got a failure in xx-shipit-login.txt. Looks like login is succeeding, but the Z3 principals are not being changed causing launchbag.user to still be None [10:25] Hmm... probably my fault === stub steps through further [10:28] daf: ok [10:33] What listens for CookieAuthLoggedInEvent ? [10:36] found it === beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === mpt [n=mpt@210-55-43-236.dialup.xtra.co.nz] has joined #launchpad [10:45] SteveA: ready when you are === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === Nafallo_away is now known as Nafallo [11:07] jordi: hi, are you around? [11:13] SteveA: What should be handling CookieAuthPrincipalIdentifiedEvent? [11:15] daf: pong [11:16] jordi: hi, I've just assigned a bug to you about iso-codes for breezy being unavailable in Rosetta [11:16] stub: can't remember. i'd need to look through the code... [11:17] jordi: I'm hoping you'll know what to do with it [11:17] let me have a look [11:17] I think we should encourage people to use the support tracker for this stuff, but I'm not sure how to do that [11:17] daf: but that's probably carlos' court [11:18] A CookieAuthPrincipalIdentifiedEvent is being published, and seems to be handled by authentication.py's handle method. This method happily ignores event.principal, tries to autheticate, and fails. [11:18] I suspect there is another handler that should be being invoked [11:19] stub: staging.ubuntu.com is giving a Bad Gateway error. Is that a known problem? [11:20] jamesh: As I mentioned in the meeting yesterday, expect staging to be down for the next few days. Postgres7.4-8 migration stuff [11:20] okay [11:21] jamesh: Sorry, I was at dinner. [11:21] jamesh: Yes, selectFirst sounds good to me. [11:23] stub: what is emiting the event? [11:24] stub: can we not have a nice page saying "staging is down because..." ? [11:26] SteveA: I havn't even got the rt job for that done on production and you want it on staging? [11:27] i want the moon on a string [11:28] ShipitLoginView is a subclass of LoginOrRegister. LoginOrRegister.process_form is not logging in, causing this for fail. [11:29] It happily authenticates the user, and calls logInPerson() in login.py, giving a valid principal [11:30] when we have a request where we have a cookie login form [11:30] when we have a request where we have the cookie login form POST, rather [11:30] then we have what is initially an anonymous request [11:30] it is handled by the view, which interprets the form, checks the details, and sets session data [11:31] from that point on, we also want the user to be logged in [11:31] Yup. All that is working. [11:31] But they arn't logged in [11:31] so, that's when the CAPIEvent is sent [11:31] i think that's meant to log them in... the handler for that [11:31] It isn't senting a PrincipalIdentified event, it is sending a CookieAuthLoggedInEvent [11:32] Which is handled by authentication.py's handle() function [11:32] but just in shipit? [11:33] The page test that is failing is a shipit one [11:33] xx-shipit-login.txt [11:34] But logInPerson() always sends a CookkieAuthLoggedInEvent [11:37] Which is odd, because logInPerson has been passed a principal to log in, but doesn't propogate it making me think that the wrong event is being published? [11:38] I see... then the authenticate method is invokved, basic auth fails, falls through to cookie auth, which first tries to pull the auth data out of the session that we just shoved in there. [11:40] Which is where my code changes might start causing problems [11:40] aha [11:47] Looks like a bug in the new session machinery === stub tries to write a test case to reproduce the loss of stickyness === jinty [n=jinty@205.134.224.215] has joined #launchpad [11:49] If you construct your session data storage area, set stuff, and then construct it again in the same request you won't see your changes. [11:54] Ahh... but maybe only when you don't have a session cookie set. [11:57] it would be nice to somewhere somehow detect refusal of the session cookie [11:57] so we can say "screw you hippie" [11:57] and later on, offer basic auth instead [11:59] mpt: yo [12:03] BjornT: hi [12:03] https://launchpad.net/products/rosetta/+bug/2497 [12:03] Error: I cannot access this bug [12:04] hi SteveA [12:04] can we do better at stripping GPG stuff? [12:05] the "This is an OpenPGP/MIME..." thing gets in the way of reading the bug description [12:05] there's also the signature .asc [12:05] which isn't all that important [12:06] yes we can. [12:06] the "This is an OpenPGP/MIME" stuff shouldn't appear in new comments [12:06] cool [12:07] the signature.asc is easy to get rid off. currently IMessage.contents include all the message's parts, when it should only include text/plain parts [12:10] i'm not sure if we have a use case for the current IMessage.contents, but we could add an IMessage.text_contents, that would contain only the text parts of the message. [12:10] sounds good [12:10] that should get rid of most GPG stuff. inline signatures will still appear in comments, though. we could get rid of those as well, but it's a little bit trickier. [12:11] there should be a bug open for this [12:12] bug 2653, i'll see if i will have time to fix it today [12:12] Malone bug #2653: Strip signature.asc attachments from e-mailed comments and bug reports In: malone (upstream), Severity: Normal, Assigned to: Bjrn Tillenius, Status: Accepted https://launchpad.net/bugs/2653 === mpt [n=mpt@210-55-161-149.dialup.xtra.co.nz] has joined #launchpad [12:18] BjornT: https://launchpad.net/products/rosetta/+bug/2934 [12:18] Error: I cannot access this bug [12:18] i just assigned it to stub [12:18] but, the original email from stub attempted to set him as the assignee [12:19] so, maybe there's a bug somewhere/ [12:19] ? [12:20] sort of. the 'assignee' command is a part of the 'affects' command, and have to appear right after it. this will be fixed in the next rollout, though. === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === niemeyer [n=niemeyer@201.23.160.12] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:30] good morning! [12:34] mpt: Hey ho! how was your trip? === beyond is now known as beyon-out [12:46] lifeless: perhaps the baz stuff in the hacking faq should go to a saeparate page === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:47] and be converted to bzr stuff [12:49] hmm: https://launchpad.net/products/husna === niemeyer [n=niemeyer@201.23.160.13] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:09] matsubara, tiring [01:15] mpt: You forgot/left over one of your packs here. A green one. [01:16] mpt: and 2 white blankets [01:17] SteveA, around? [01:17] lifeless, have you seen the whole diff of the mirror-management branch? === daf notes that https://launchpad.net/products/malone/+filebug has floated to the top of Epiphany's frequently-used URLs list [01:27] salgado: yes, although having lunch somewhat [01:28] mpt: i've been talking with daf about improving certain rosetta UI [01:31] matsubara, I left behind the green bag deliberately, because the vicious So Carlos footpaths broke one of its wheels [01:32] matsubara, I left behind the sheets deliberately too -- they're no use to me [01:33] SteveA, which? === mpt really should be asleep [01:33] https://wiki.launchpad.canonical.com/FindProgramsToTranslate [01:33] although, the launchpad entry needs updating in that spec [01:34] this will make things more focused, and also remove a bunch of timeout errors [01:37] lifleess: sure [01:37] lifeless: i'll d that with the rocketful stuff I want to finish today === daf wonders what "vinculate" means [01:38] it sounds like a perfectly plausible word [01:38] but I think it may be cromulent [01:38] (https://launchpad.net/products/malone/+bug/5251) [01:38] Malone bug #5251: Bugs not vinculated In: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/5251 [01:39] I noticed that earlier === thierry [n=thierry@modemcable084.72-131-66.mc.videotron.ca] has joined #launchpad [01:42] google matches 609 vincluateds [01:45] aha, I think it means "to link" in Spanish [01:46] SteveA, I like the focus on workflow, but probably it could do with some simplification [01:46] Most importantly, I doubt that translators are going to start by going from launchpad.net/ to launchpad.net/distros/ubuntu [01:46] mm, that bit is a bit dodgy [01:47] but Ubuntu is a pretty big link on the front page [01:47] s/big/prominent/ [01:47] At least if I was wanting to translate, I would click the link that says "Translations" [01:47] true [01:47] i think many people want to translate a particular favourite program [01:47] especially if I didn't realize that Launchpad hosted distributions other than Ubuntu [01:48] so I didn't realize I *could* even go into the Ubuntu context, let alone that it was a good idea to do so [01:49] the "Translateble APplications" table: the "application" column seems redundant [01:49] (https://launchpad.net/rosetta) [01:49] yes [01:50] they're url-names [01:51] source package names, perhaps? [01:51] or bianries === gneuman [n=gneuman@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:06] Merge to devel/launchpad: [r=Bjornt] fixing bug # 6040, bug # 4810, bug # 3530 and bug # 3531. Fixing minor on buildd infrastructure (bad zipped tempfile name), Soyuz/Buildd UI improvements (build state selector, common templates and widgets, etc). (r2939: Celso Providelo) === bradb [n=bradb@S01060014bf4ac6aa.wp.shawcable.net] has joined #launchpad === heyko [n=heyko@tor/session/x-da76544f3f148247] has joined #launchpad [02:37] SteveA, on of lifeless' emails for the review of my mirror-management branch asks for your thoughts. have you seen that email? [02:37] SteveA, Subject: Re: Urgent review request attn: stevea [02:37] i have it flagged, but not properly read [02:38] another thing I'd like to talk to you is about defining a policy for where we should place view classes === cprov cprov-away [02:38] I thought we should always keep view classes that share the same context in the same file, but this is not always true [02:40] for instance, things like BugAttachmentAddView are defined in bugattachment.py, although it's context is a Bug [02:40] on the other hand, the zcml for the page that uses BugAttachmentAddView is in bug.zcml [02:41] SteveA, do you think it's worth having a policy for this, and have it formalized on the wiki? [02:41] salgado: i'm working with daf on bug triage at the moment. i'd like to talk about this with you later, when i can give my attention to it [02:42] SteveA, sure === thierry is now known as thierry_eating [02:47] stevea: ping [02:47] hello jblack [02:48] Mind if I bother you privately for a moment? [02:49] daf: can i take 5 for a chat with jblack? [02:49] certainly [02:57] SteveA: Can you add me to your queue too please? :) Questions about Bugzilla => Malone transition and implementing keywords. === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [03:01] bradb: can we talk later on, after daf has finished work? [03:02] SteveA: Sure. What time is that, UTC? [03:04] it's 2 UTC now [03:04] daf: how much longer are you working today? [03:05] good question [03:06]