| === robertbb [n=robertbb@d154-20-189-90.bchsia.telus.net] has joined #launchpad | ||
| === jinty [n=jinty@205.134.224.215] has joined #launchpad | ||
| === Kinnison sighs and starts his test run again | ||
| === netjoined: irc.freenode.net -> kornbluth.freenode.net | ||
| === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad | ||
| === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has left #launchpad ["Fui] | ||
| === robertbb_ [n=robertbb@d154-20-150-5.bchsia.telus.net] has joined #launchpad | ||
| Kinnison | night dudes | 01:08 |
|---|---|---|
| === SnakeBite [n=SnakeBit@84.242.143.64] has joined #launchpad | ||
| === carlos -> bed | ||
| kiko-zzz | lifeless? | 02:06 |
| === Alinux [n=Ubuntu@p54A38043.dip0.t-ipconnect.de] has joined #launchpad | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Added Occitan plural forms. (patch-2353: carlos.perello@canonical.com) | 02:21 |
| === stub [n=stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad | ||
| === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad | ||
| stub | Can someone send me the current password for the Canonical wiki? | 07:09 |
| stub | ta | 07:10 |
| === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad | ||
| === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad | ||
| === Alinux [n=Ubuntu@p54A38043.dip0.t-ipconnect.de] has joined #launchpad | ||
| === Alinux [n=Ubuntu@p54A38043.dip0.t-ipconnect.de] has joined #launchpad | ||
| === niran [n=niran@cpe-67-10-213-51.houston.res.rr.com] has joined #launchpad | ||
| === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad | ||
| === robertbb_ [n=robertbb@d154-20-150-5.bchsia.telus.net] has joined #launchpad | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] documentation tweaks. (patch-2354: bjorn.tillenius@canonical.com) | 09:38 |
| sabdfl | moin moin | 09:40 |
| === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad | ||
| lifeless | kiko-zzz: ? | 09:50 |
| === dand [n=dand@gw.datagroup.ro] has joined #launchpad | ||
| sabdfl | so guys, what's the verdict on language packs? stub? carlos? | 10:03 |
| sabdfl | SteveA: can we automagically discover the closest parent url component which is accessible to zope.Public? | 10:09 |
| sabdfl | so, if we are at /products/gnomebaker/+edit then it would be /products/gnomebaker/ | 10:09 |
| === carlos [n=carlos@243.Red-83-47-24.pooles.rima-tde.net] has joined #launchpad | ||
| carlos | morning | 10:22 |
| === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad | ||
| sivang | morning carlos | 10:48 |
| carlos | sivang, hi | 10:49 |
| carlos | hmmm | 10:51 |
| carlos | jamesh, https://launchpad.net/products/rosetta | 10:51 |
| carlos | jamesh, the calendar is a bit... big | 10:51 |
| carlos | or is the bug list?... | 10:52 |
| jamesh | carlos: yes. I blame malone | 10:52 |
| jamesh | :) | 10:52 |
| carlos | ok | 10:52 |
| carlos | :-P | 10:52 |
| jamesh | bug 2036's title has a long URL in it which can't be word-broken | 10:52 |
| BjornT | i blame the browser, looks perfectly fine in mine :) | 10:54 |
| jamesh | BjornT: does Opera word-break on slashes or something? | 10:55 |
| BjornT | jamesh: yeah | 10:56 |
| jamesh | we should probably be adding <wbr>'s or ‌'s to URLs | 10:56 |
| jamesh | as hints | 10:56 |
| === cprov [n=cprov@haddenham.pepperfish.net] has joined #launchpad | ||
| jamesh | actually, I'm not sure if mozilla handles ZWNJ (zero-width non-joiner) characters | 10:58 |
| jamesh | it does handle <wbr> though | 10:58 |
| lifeless | jamesh: i think I'm done for now on pending revirews, just doing a real run to see how it looks | 11:02 |
| lifeless | jamesh: how do you want it back - ? | 11:02 |
| jamesh | lifeless: I'll take a look over them and merge, I guess. | 11:05 |
| lifeless | ok, I'll put it up on needs review page then :0 | 11:05 |
| === ubuntulog [n=warthylo@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad | ||
| === Topic for #launchpad: Discussion with Launchpad users and developers. || https://launchpad.net/ || Includes Rosetta and Malone. || Developers' meeting, Thursday 8 Sep, 12:00 UTC | ||
| === Topic (#launchpad): set by SteveA at Thu Sep 1 14:05:24 2005 | ||
| (lifeless/#launchpad) kiko-zzz: so what would you like me to review today ? | 11:28 | |
| SteveA | sabdfl: are you working on the logout link at the moment? | 11:32 |
| sabdfl | SteveA: no | 11:32 |
| sabdfl | BjornT: thanks for the conflicts around bugsubscription ;-) | 11:33 |
| SteveA | okay. i like to do some small self-contained tasks each day. i'll improve the logout link as my warmup today. | 11:33 |
| sabdfl | SteveA: rockin. thanks. | 11:34 |
| BjornT | sabdfl: sorry :) but it wasn't that bad, was it? | 11:35 |
| SteveA | gustavo rocks: http://labix.org/editmoin | 11:39 |
| lifeless | sweet | 11:40 |
| === BjornT has already edited some pages using it :) | ||
| sabdfl | BjornT: the only thing that worries me is that i'd moved to returning None from unsubscribe() if the person is not subscribed | 11:41 |
| sabdfl | you changed to ValueError | 11:41 |
| sabdfl | i reverted that, but i'm not sure where you are looking for valueerror | 11:42 |
| jordi | sabdfl: hey! did you have time to work on that feature we talked about? | 11:42 |
| Kinnison | is there a way to tell SQLObject not to defer updates? | 11:42 |
| SteveA | <interjection>we shouldn't use ValueError for such exceptions, but a more specific exception, such as SubscriptionError</interjection> | 11:42 |
| SteveA | Kinnison: there's a flush_updates call. you can do it for individual objects, or for the whole transaction. | 11:43 |
| Kinnison | ergh | 11:43 |
| SteveA | canonical.database.sqlbase.flush_database_updates() | 11:43 |
| Kinnison | I just want something like SQLBase.disable_deferred() | 11:43 |
| Kinnison | I want to see the exception the *moment* an error occurs | 11:43 |
| Kinnison | so I know what line caused it | 11:43 |
| SteveA | i'm sure that's possible, but i'd need to look into exactly how to do it | 11:44 |
| BjornT | sabdfl: you can change it to None if you want. i didn't really change anything, i implemented it as described in the interface. i check if the user is subscribed before i try to unsubscribe him, though. | 11:44 |
| sabdfl | ok. that's in mail commands? in the web ui i've just ignored an attempt to unsubscribe someone who is not subscribed | 11:45 |
| sabdfl | it's a noop | 11:45 |
| spiv | Kinnison: SQLBase._lazyUpdates = False | 11:45 |
| spiv | Kinnison: (off the top of my head) | 11:45 |
| === Kinnison tries | ||
| BjornT | sabdfl: yeah, i do the same in the email ui. if the user isn't subscribed, it's a noop | 11:46 |
| spiv | Kinnison: certainly, grepping for lazy will find the relevant thing :) | 11:46 |
| sabdfl | cool. in that case i think it's more elegant to keep that decision in the lower layer | 11:47 |
| sabdfl | spiv: were you ill when stevea and i were discussing a general way to pass messages to the user? | 11:47 |
| SteveA | there's a spec on this now | 11:47 |
| SteveA | stu wrote the spec in brazil | 11:47 |
| sabdfl | ok | 11:48 |
| SteveA | it just needs implementing iirc | 11:48 |
| spiv | SteveA: http://mozex.mozdev.org/ is another solution to that problem. | 11:48 |
| SteveA | spiv: i'm a commandline junkie | 11:48 |
| Kinnison | spiv: seems to be _lazyUpdate rather than _lazyUpdates | 11:48 |
| === Kinnison runs a test | ||
| spiv | SteveA: So am I, but wikis are sufficiently webby that I find the context-switch to command lines annoying. I realise this is very much a matter of personal preference, though :) | 11:49 |
| spiv | sabdfl: I don't recall the specific discussion, no. But I do recall that there is a spec about it :) | 11:49 |
| sabdfl | ok. who's assigned to implement that? | 11:50 |
| Kinnison | How can I determine what user I've managed to connect to the db as? | 11:56 |
| spiv | config.launchpad.dbuser should tell you. | 11:57 |
| Kinnison | ta | 11:58 |
| stub | production rollout happening... | 12:00 |
| carlos | stub, what's the patchset you are rolling out? | 12:00 |
| stub | launchpad--production--1.31 | 12:01 |
| === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad | ||
| carlos | stub, ok | 12:01 |
| sivang | launchpad.net is donw? | 12:07 |
| SteveA | it's being updated | 12:07 |
| SteveA | stub: the "down for maintenance" page isn't working. | 12:07 |
| sivang | SteveA: ok. do you know if the lpi pages should back sometime soon? | 12:07 |
| SteveA | i get a 503 error from apache | 12:08 |
| sivang | same here | 12:08 |
| stub | SteveA: Yup. It still hasn't been installed. | 12:08 |
| SteveA | is it in RT? | 12:08 |
| stub | SteveA: Yes, although you can't see it at the moment (there is another ticket about missing tickets) | 12:11 |
| SteveA | gaah | 12:11 |
| === spiv -> dinner | ||
| SteveA | sabdfl: stub will be implementing the notification messages spec | 12:13 |
| stub | All back up | 12:24 |
| stub | carlos: Did a fix for the rosetta karma land, or is that still todo? | 12:25 |
| carlos | stub, still todo, but I will do it this week | 12:25 |
| stub | carlos: No worries - just wondering if I should clear out the dud entries yet | 12:26 |
| elmo | stub: librarian's down still? | 12:26 |
| stub | ta ) | 12:26 |
| SteveA | elmo: 503 status page? | 12:26 |
| stub | Librarian restarted too | 12:27 |
| carlos | stub, the patch will include a db patch to "migrate" that data | 12:28 |
| stub | carlos: If it is just 'delete from karma where action in (16,27)', then I need to run it manually rather than it being in the dbpatch | 12:29 |
| vinsci | hi carlos - time for the daily reminder | 12:30 |
| carlos | stub, yeah, it's that | 12:31 |
| carlos | stub, I know I was planning to do a "migration script" more than a db patch | 12:31 |
| carlos | vinsci, hi | 12:31 |
| vinsci | carlos, if it is delayed much longer, I won't have any time on my hands. I do have some time now. | 12:33 |
| carlos | vinsci, count with that today, sorry :-( | 12:33 |
| elmo | SteveA: yeah, I know | 12:34 |
| SteveA | stub: nice sane response about sources on zope3-dev | 12:34 |
| === carlos [n=carlos@243.Red-83-47-24.pooles.rima-tde.net] has joined #launchpad | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Some missing (trivial) SQLObjects and a quick fix to a broken join in a publishing class (patch-2355: daniel.silverstone@canonical.com) | 01:03 |
| sabdfl | spiv: i've got a ticketing system in your review queue | 01:05 |
| sabdfl | it's a big patch | 01:05 |
| sabdfl | but mostly straightforward | 01:05 |
| sabdfl | and i'm adding the page tests now | 01:06 |
| sabdfl | could i ask you to send me comments tomorrow, so i can land this for the next production update? | 01:06 |
| sabdfl | we need some end user feedback asap | 01:06 |
| spiv | sabdfl: I'm about 2/3rds of the way through the review, judging from my scrollbar. | 01:07 |
| spiv | You should have plenty of comments by tomorrow ;) | 01:07 |
| === ddaa [n=ddaa@217.205.109.249] has joined #launchpad | ||
| ddaa | sabdfl | 01:12 |
| ddaa | disappointing | 01:12 |
| sabdfl | spiv: perfect, thanks! | 01:12 |
| ddaa | Keybuk: ping | 01:12 |
| Keybuk | ddaa: hey | 01:14 |
| ddaa | We have a problem. | 01:14 |
| ddaa | Management has decided to get rid of the arch-namespace related tables. | 01:14 |
| ddaa | I'm right now working on the new database and interface classes for Branch and Revision. | 01:15 |
| Keybuk | right | 01:15 |
| ddaa | To try and stay focused I reckelessly removed all the old arch namespace cruft. | 01:15 |
| ddaa | archarchive | 01:15 |
| ddaa | archbranch | 01:15 |
| ddaa | archchangeset | 01:15 |
| ddaa | yadda yadda yadd | 01:15 |
| Keybuk | yup | 01:15 |
| lifeless | including database.Archive | 01:15 |
| lifeless | ^^ | 01:16 |
| ddaa | Which break hctapi pretty throughly | 01:16 |
| Keybuk | they would | 01:16 |
| ddaa | How difficult do you think it would be to update that code to work with the new model? | 01:16 |
| Keybuk | alter the get_branch_from(), get_changeset_from() and put_manifest() functions | 01:16 |
| Keybuk | should be trivial | 01:16 |
| lifeless | Keybuk, ddaa - cool | 01:17 |
| lifeless | Keybuk: we'll probably defer that until after the sprint | 01:17 |
| Keybuk | they just use the database to build up an arch name | 01:17 |
| lifeless | Keybuk: and possibly ask you to do it while ddaa fixes taxi, but we'll see how tough it will be. the problem is that there are no arch names anymore, so knowing how to fix this may require hct internal knowledge | 01:18 |
| Keybuk | hct uses arch names | 01:18 |
| lifeless | is it ready to move to urls ? | 01:19 |
| Keybuk | no | 01:19 |
| Keybuk | I'll make the move to urls when I make the move to baz-ng | 01:19 |
| lifeless | Keybuk: what are the blockers to moving sooner ? We had planned in sao carlos to move lp to urls asap across the board. | 01:20 |
| === Kinnison preps to wander off for lunch | ||
| Keybuk | I'm more concerned with getting people using hct | 01:20 |
| lifeless | Keybuk: ok. let me rephrase - how big is the job of moving the lp side hct code to urls ? | 01:21 |
| Keybuk | it's not just the lp-side code | 01:21 |
| Keybuk | you'd have to move all of hct and sourcerer to using urls throughout | 01:21 |
| Keybuk | and invent a new way of naming archives and branches accordingly | 01:22 |
| Keybuk | probably a few weeks work | 01:22 |
| Keybuk | the arch namespace is quite fundamental to it | 01:22 |
| lifeless | why would you need to name the archives? I thought that hct was essentially bzr-ng ready? If you are worried about being able ot give baz names, I can give you a uuid-based archive and branch naming scheme easily, which is all that is needed if you use urls for everything | 01:23 |
| Keybuk | because the names are intended to be meaningful | 01:23 |
| SteveA | carlos: ping | 01:24 |
| lifeless | ok, so its a big job. ddaa and I will talk about a contingency plan, and you and I and Mark can talk monday, onk ? | 01:24 |
| Keybuk | right | 01:24 |
| carlos | SteveA, pong | 01:24 |
| lifeless | I'd like you to think , in prep for monday, about what could be done to make it not-a-big-job. I.e. 'names dont matter because bzr doesnt have them' | 01:24 |
| Keybuk | my opinion remains that it's a sufficiently big job that the cost of doing that at the expense of actually having people using hct is too high | 01:24 |
| Keybuk | so the right time to do it is when we shift to bzr | 01:24 |
| SteveA | carlos: i run launchpad, pretty close to what is in rocketfuel, and go to the url http://localhost:8086/products/netapplet/+series/releases/+pots/netapplet/af/ | 01:24 |
| lifeless | Keybuk: we do not want to make shifting to bzr a watershed event, that makes the shift very very hard to do. | 01:25 |
| SteveA | carlos: i get an error about not being able to traverse to 'browsername' when rendering the page template | 01:25 |
| lifeless | Keybuk: so, have a think, and we'll talk monday. | 01:25 |
| Keybuk | there's nothing that can be done to make it not-a-big-job I'm afraid | 01:25 |
| SteveA | carlos: can you reproduce this error? is this page tested? | 01:25 |
| Keybuk | even the shift to bzr is going to be a big-job | 01:25 |
| Keybuk | it's a possible job, and even quite a boring and tedious one | 01:25 |
| Keybuk | but it's a lot of code change | 01:26 |
| carlos | SteveA, let me check... | 01:26 |
| Keybuk | (infer "easy" from "boring and tedious") | 01:26 |
| carlos | SteveA, same error here | 01:28 |
| carlos | SteveA, I suppose we don't have a pagetest or that should not happen | 01:28 |
| SteveA | indeed | 01:28 |
| carlos | SteveA, thanks for the warning | 01:28 |
| === Seveas [n=seveas@ksl403-uva-132.wireless.uva.nl] has joined #launchpad | ||
| === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad | ||
| sabdfl | does anybody know what the password is for "Sample Person" (name12)? | 01:39 |
| carlos | sabdfl, test | 01:49 |
| === carlos -> lunch | ||
| === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| === niemeyer [n=niemeyer@200.138.36.81] has joined #launchpad | ||
| niemeyer | Morning! | 02:25 |
| === ChanServ [ChanServ@services.] has joined #launchpad | ||
| === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| === niemeyer [n=niemeyer@200.138.36.81] has joined #launchpad | ||
| === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad | ||
| === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad | ||
| === ddaa [n=ddaa@217.205.109.249] has joined #launchpad | ||
| === cprov [n=cprov@haddenham.pepperfish.net] has joined #launchpad | ||
| === dand [n=dand@gw.datagroup.ro] has joined #launchpad | ||
| === niran [n=niran@cpe-67-10-213-51.houston.res.rr.com] has joined #launchpad | ||
| === _Rappy_ [n=hunt-pre@dsl-253-122.monet.no] has joined #launchpad | ||
| === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad | ||
| === segfault [i=carlos@prognus.com.br] has joined #launchpad | ||
| === interalia [n=interali@adsl-60-232.swiftdsl.com.au] has joined #launchpad | ||
| === jamesh [n=james@203-59-251-126.dyn.iinet.net.au] has joined #launchpad | ||
| === Virtuall [n=virtuall@off.lv] has joined #launchpad | ||
| === SteveA [n=steve@office.pov.lt] has joined #launchpad | ||
| === mdz [n=mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #launchpad | ||
| === lifeless [n=robertc@dsl-240.26.240.220.dsl.comindico.com.au] has joined #launchpad | ||
| === spiv [n=andrew@adsl-66-203.swiftdsl.com.au] has joined #launchpad | ||
| === lamont [n=lamont@mix.mmjgroup.com] has joined #launchpad | ||
| === dilys [i=daf@muse.19inch.net] has joined #launchpad | ||
| === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad | ||
| === jordi [n=jordi@115.Red-213-96-69.pooles.rima-tde.net] has joined #launchpad | ||
| === superted [n=superted@213.167.101.222] has joined #launchpad | ||
| === Kinnison [n=dsilvers@haddenham.pepperfish.net] has joined #launchpad | ||
| === \sh_away [n=nnnnnnnn@server3.servereyes.de] has joined #launchpad | ||
| === Znarl [i=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad | ||
| niemeyer | lifeless: That's more like "Is everything ok?" | 02:33 |
| elmo | who created the ticket in RT via the warthogs user? | 02:35 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Fixed the pofile index page to work when we don't have such pofile in our database (so POFile.owner is None) + test (patch-2356: carlos.perello@canonical.com) | 02:35 |
| salgado | SteveA, around? | 02:35 |
| stub | elmo: That would be me | 02:37 |
| lifeless | niemeyer: ah, roughly 'how are you?' ? | 02:37 |
| elmo | stub: please use the mail interface; if you use the generic user and web interface I have no idea who opened it | 02:38 |
| elmo | stub: also, the reason your requests didn't come across is this is a brand new RT | 02:39 |
| elmo | for various long uninteresting reasons | 02:39 |
| stub | elmo: ok ;) | 02:39 |
| stub | elmo: So I should refile them? | 02:39 |
| elmo | if you don't mind, that'd rock | 02:39 |
| elmo | otherwise, I'll get to them in a bit | 02:39 |
| niemeyer | lifeless: Yes! :) | 02:41 |
| stub | elmo: resen | 02:47 |
| stub | t | 02:47 |
| elmo | stub: danke schoen | 02:55 |
| === sabdfl [n=mark@217.205.109.249] has joined #launchpad | ||
| \sh | gentlemen, is there any possible way to receive personal data from launchpad via xmlrpc call or soap call after authentication? | 03:04 |
| === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad | ||
| spiv | \sh: There's no public xmlrpc or soap interfaces yet, but what do you mean by "personal data"? | 03:07 |
| \sh | spiv: i'm thinking about hacking a call to LP user page which should receive all data from there, and push it into a jabber user directory while u r registering a new jabber account... | 03:08 |
| lifeless | \sh: person/+rdf | 03:08 |
| \sh | lifeless: ok thats a good start | 03:10 |
| spiv | \sh: No fancy rpc required :) | 03:11 |
| \sh | will you integrate other data items like email etc. into the foaf record as well? ,-) | 03:11 |
| \sh | spiv: well..updating the record via rpc would be a good idea as well...creating a new jabber account (if you don't have one) and updating your personal record :) | 03:11 |
| \sh | spiv: and later also your sip address etc. | 03:12 |
| lifeless | \sh: we are interested in such xml rpc facilities, but right now none are live | 03:12 |
| spiv | \sh: I believee emails aren't published in that rdf intentionally, to avoid making launchpad an easy target for email address harvesters. | 03:14 |
| \sh | spiv: that's why I asked, if this would be possible after authentication with lp in an automatic manner | 03:15 |
| \sh | the other idea is to use the database as jabber user directory...*hmmm* | 03:15 |
| \sh | or sip phonebook as well | 03:15 |
| spiv | \sh: In theory we could do that. The best person to talk to about our rdf is morgs. | 03:16 |
| lifeless | spiv: email addresses are on the person page in plain text | 03:16 |
| lifeless | spiv: dont think rdf makes buckleys difference | 03:16 |
| spiv | (who is on leave until the 21st, unfortunately) | 03:16 |
| \sh | spiv: well..I'm working on a concept how to integrate SIP + Jabber + Launchpad for a easy to use single sign on | 03:17 |
| lifeless | cool | 03:17 |
| mpt | agh | 03:18 |
| spiv | lifeless: Yeah. We should at least do foo.replace('@', '(') or whatever it is, to foil the basic harvesters. | 03:18 |
| === mpt still doesn't have permission to see the bugs he's assigned to | ||
| spiv | \sh: We do have an internal XML-RPC api to the launchpad db for authentication. | 03:19 |
| mpt | bradb? | 03:19 |
| \sh | at the end it will work like this: you login into your first installation of ubuntu, register with launchpad, create a jabber account, create a sip account automatically on serverside, kicked by launchpad, and the user has a fully communication office at hand after installation :) that's the plan for ShtoomVoip | 03:19 |
| spiv | \sh: We should definitely talk at UBZ. | 03:20 |
| stub | \sh: Feel like describing your project on wiki.launchpad.canonical.com (ideally as a specification?) If it looks like a good and non-evil idea we might come to the party and meet you half way. | 03:20 |
| \sh | spiv: when all goes well..sure :) | 03:21 |
| bradb | mpt: https://launchpad.net/people/mpt/+assignedbugs | 03:21 |
| spiv | \sh: https://wiki.launchpad.canonical.com/AuthServer may be of interest | 03:21 |
| \sh | stub: I'm drawing right now some things via dia...to get a correct workflow | 03:21 |
| stub | We have two XML-RPC servers that could be extended to your needs | 03:21 |
| sabdfl | spiv: that review wrapped? | 03:21 |
| sabdfl | tests are added and mirrored | 03:21 |
| sabdfl | SteveA: to all the standalone tests run in the same "story"? | 03:22 |
| mpt | bradb: Yes, but the link to "the whole list of bugs assigned to him(her)[me] " is beyond my puny permissions | 03:22 |
| sabdfl | stub: any idea what generates IntegrityError's ? under breezy they have become ProgrammingErrors | 03:22 |
| \sh | spiv: is it a canonical internal wiki? | 03:22 |
| mpt | bradb: Anyway, that's not what I wanted to ask you. What I wanted to ask you was, What is the lock icon for in https://launchpad.net/malone/bugs/1966 ? | 03:23 |
| stub | urgh ;-( | 03:23 |
| spiv | \sh: Hmm, you can't see/edit it? | 03:23 |
| stub | \sh: It is publicly readable, but I don't think there is public edit access | 03:23 |
| bradb | mpt: Confusion. :P It's meant to indicate a task/watch linkage. | 03:24 |
| \sh | spiv: I see nothing..can't even access it .... | 03:24 |
| \sh | hmm | 03:24 |
| bradb | mpt: I want to demolish /malone/assigned RIGHT NOW. Would it make sense to show all a persons assigned, open bugs on the +assignedbugs page instead? | 03:24 |
| \sh | last hop i can get through is 11: 82.211.81.76 (82.211.81.76) asymm 12 68.996ms | 03:24 |
| spiv | sabdfl: Not yet, it won't be finished before I go to bed. | 03:24 |
| mpt | bradb: Absolutely. | 03:25 |
| sabdfl | could you send what you have when you crash? | 03:25 |
| spiv | \sh: http*s*? | 03:25 |
| stub | sabdfl: Generally violating a database constraint. If psycopg has been upgraded, some of the exceptions might have changed. | 03:25 |
| \sh | spiv: nothing.. | 03:25 |
| bradb | mpt: Right, branching now. | 03:26 |
| sabdfl | i could make those page tests catch ...Error | 03:26 |
| spiv | \sh: Hmm :( | 03:26 |
| \sh | no connect via https and also no error message ,-) | 03:26 |
| spiv | \sh: It's supposed to be publicly readable. | 03:26 |
| \sh | argl | 03:26 |
| \sh | firefox bug | 03:26 |
| \sh | certificate accepting dialogbox appears on desktop 2 where my main instance of ff is *grrr* | 03:27 |
| spiv | Ah. | 03:27 |
| stub | sabdfl: psycopg.DatabaseError is probably what you want to catch if it has changed | 03:27 |
| SteveA | sabdfl: yes. there is nothing special in the testrunning code that makes standalone different from, say, foaf | 03:27 |
| stub | sabdfl: The exception hierarchy is in http://www.python.org/peps/pep-0249.html | 03:28 |
| sabdfl | stub: this is a page test | 03:28 |
| sabdfl | not code | 03:28 |
| sabdfl | it's currently looking for IntegrityError: ERROR etc | 03:28 |
| sabdfl | and that needs to become ...Error | 03:28 |
| sabdfl | to work with boath hoary and breezy | 03:28 |
| bradb | mpt: What should we make that strange lock icon into? A pair of binoculars? An eye? An icon that represents the specific external tracker linked to? Something else? | 03:28 |
| SteveA | so, IntegrityError and ProgrammingError are siblings | 03:28 |
| SteveA | both derive from DatabaseError | 03:28 |
| sabdfl | the page test machinery ain't that smart :-) | 03:29 |
| stub | Are you writing a spider or something? I'm curious as to why expected output should contain a database exception? | 03:29 |
| === spiv -> bed | ||
| salgado | spiv, do you have 2s before you go? | 03:30 |
| mpt | bradb: So in the list of "Remote bug watches" way down yonder in the bottom right corner of the page, a watch applies to only one task? | 03:31 |
| SteveA | stub: look at the end of doc/bugtask.txt | 03:31 |
| SteveA | looks like an IntegrityError can leak out of the bugtask API | 03:31 |
| SteveA | which seems to me to be a bug in the API | 03:32 |
| SteveA | and in its implementation | 03:32 |
| stub | ahh... doctest... not a page test ;) | 03:32 |
| === stub context switches | ||
| SteveA | bradb: ping | 03:32 |
| sabdfl | right, sorry | 03:32 |
| SteveA | so, no stories for system doctests | 03:32 |
| === Kinnison returns from lunch | ||
| sabdfl | SteveA: for the record, <BLANKLINE> handling has taken months off my life | 03:33 |
| SteveA | i'm pretty sure that each runs independently. | 03:33 |
| sabdfl | SteveA: that was a separate question | 03:33 |
| bradb | mpt: I'm not sure if there's actual database constraints enforcing that, but in practice, yes, I think a watch would be assigned to one task per bug. | 03:33 |
| sabdfl | regarding the tests in pagetest/standalone/ | 03:33 |
| SteveA | okay | 03:33 |
| bradb | SteveA: hi | 03:33 |
| SteveA | bradb: why does the bugtask API let an IntegrityError through? | 03:33 |
| SteveA | i think the API should guard against letting IntegrityErrors occur at all | 03:34 |
| stub | SteveA: It leaks it if you invoke the create method improperly. The doctest is just demonstrating it. | 03:34 |
| bradb | SteveA: what should it raise instead? | 03:34 |
| sabdfl | the create method should be on the target | 03:34 |
| stub | Although I'd rather there was just an assert | 03:34 |
| sabdfl | that's the way i've done it with milestones, tickets, specs, etc | 03:34 |
| SteveA | i still don't get it. we have python code that can check things, and avoid sending the database invalid data. | 03:34 |
| sabdfl | that way, you *can't* pass it bogus data | 03:35 |
| sabdfl | so rather than having IBugTaskSet.create() | 03:35 |
| sabdfl | have an IBugTarget.fileBug() | 03:35 |
| sabdfl | or newBugTask() | 03:35 |
| bradb | SteveA: Is it always that simple though? What if the validation logic is sort of complex and you don't want to maintain it in two places? | 03:35 |
| SteveA | bradb: there is no excuse for writing an API that can let a database integrity error through. | 03:36 |
| sabdfl | SteveA: what will it take to fix <BLANKLINE> handling properly? | 03:36 |
| bradb | SteveA: what should it raise instead? | 03:36 |
| SteveA | sabdfl: depends. to fix it in python upstream, it needs someone to scrutinize the code and fix it. to fix it for launchpad, i or someone else can improve the fancydiffer, and plug that in for checking as well as diffing. | 03:37 |
| SteveA | the fancydiffer at least has decent test coverage. | 03:38 |
| SteveA | bradb: AssertionError is good. | 03:38 |
| stub | bradb: You can't recover from database exceptions because the connection needs to be reset. They are a safety net. Raise a ValueError or derivative if user input might trigger it, or just stick an assert statement in if it is purey to guard against programmers screwing up | 03:38 |
| SteveA | stub: i prefer AssertionError, because no code should expect to receive this. it shouldn't be particularly recoverable from. | 03:38 |
| bradb | Does this mean maintaining constraint validation logic in two places? | 03:38 |
| sabdfl | bradb: in this case, it should be a method on IBugTarget | 03:39 |
| sabdfl | that way the constraints are automatically fulfilled | 03:39 |
| bradb | sabdfl: right, kiko-zzz had a patch that implemented that, but he was hesitant about adding it because he wasn't sure if it "felt right" | 03:39 |
| SteveA | bradb: sabdfl is objectorientedly right. | 03:40 |
| bradb | sabdfl: "automatically"? perhaps simpler to validate, but i don't see how they're "automatically fulfilled" :) | 03:40 |
| SteveA | bradb: and on maintaining constraint validation logic in two places, which two places are you talking about? | 03:40 |
| bradb | e.g. you could still try to create a task on the same bug/context twice | 03:40 |
| sabdfl | - ...duplicate key violates unique constraint "person_name_key" | 03:40 |
| sabdfl | ? ^^^ | 03:40 |
| sabdfl | + ProgrammingError: ERROR: duplicate key violates unique constraint "person_name_key" | 03:40 |
| sabdfl | ? ^^^^^^^^^^^^^^^^^^^^^^^^^^ | 03:40 |
| sabdfl | <BLANKLINE> | 03:40 |
| sabdfl | UPDATE Person SET name = 'sabdfl' WHERE id = 7 | 03:40 |
| sabdfl | 03:41 | |
| sabdfl | SteveA: help | 03:41 |
| bradb | SteveA: python code and constraints stored in the database | 03:41 |
| sabdfl | stub: any progress on getting linkchecker to pass on lp-with-sampledata? | 03:41 |
| stub | bradb: we do maintain constraint logic in two places. Every UNIQUE constraint in the db has a corresponding unique clause in the column definition in the database class for example. naming constraints are duplicated in the database, and in the form validation. If you don't duplicate the constraints, you can't unittest properly because you don't know the code paths. | 03:41 |
| SteveA | bradb: it is better to write your constraints in python, and have the safety net of the database constraints. You must not make a poor API simply to avoid some duplication. | 03:42 |
| bradb | ok | 03:42 |
| stub | sabdfl: Nope. Linkchecker was giving me the shits again so I've been talking with Kiko and Steve a bit about other spidering options | 03:42 |
| sabdfl | bradb: i've often observed you jumping through hoops to avoid a small amount of duplication | 03:42 |
| sabdfl | only generalise code the third or fourth time you have to write it, and then only if its worth it | 03:43 |
| stub | sabdfl: I suspect we need to knock up a minimal spider to fulfill all our use cases | 03:43 |
| SteveA | we'll have a neat way to check links on pagetests once we get the latest zope3 code. | 03:43 |
| SteveA | sabdfl: is that with fancy diffing on or off? | 03:43 |
| sabdfl | SteveA: the default | 03:44 |
| stub | (although linkchecker might still be the best short term solution so I really should belt it with a hammer for an hour and see what happens) | 03:44 |
| kiko | hey ho | 03:44 |
| sabdfl | morning kiko | 03:44 |
| sabdfl | great monthly report | 03:44 |
| stub | yo | 03:44 |
| SteveA | sabdfl: turn fancy diffing off, and try again. | 03:44 |
| sabdfl | let's generate the next one out of milestones + lp specs | 03:44 |
| sabdfl | SteveA: it will still fail | 03:44 |
| SteveA | but, that won't help much if the problem is with <BLANKLINE> | 03:44 |
| SteveA | but it might give better output | 03:44 |
| kiko | thanks mark | 03:45 |
| kiko | so today I will be doing reviews | 03:45 |
| kiko | I have two largish ones | 03:45 |
| kiko | if you have one you'd like me to look at you can ask but no promises | 03:45 |
| salgado | one is for me, I hope | 03:45 |
| sabdfl | kiko: spiv has the ticket system under review already, thanks | 03:46 |
| kiko | great | 03:46 |
| kiko | salgado, sure, though I suspect it won't be ready for today | 03:47 |
| stub | I've started work on LibrarianGarbageColletion, but the spec as it stands will not actually collect any garbage. The issue is that files will only ever get deleted if they have an expiry date that is not NULL. In almost all of our use cases, setting an expiry date when you create a file would be silly (because we don't want them to expire until they are no longer referenced) | 03:49 |
| carlos | SteveA, http://openwengo.com/index.php | 03:49 |
| carlos | SteveA, perhaps we should start looking into it... | 03:49 |
| stub | So I think the definition of an unnecessary file in the Assumptions section needs tweaking | 03:50 |
| SteveA | carlos: interesting | 03:51 |
| carlos | SteveA, seems like Linux version is working already on their svn server. The "problem" is that they are using QT but if it "just works"... | 03:52 |
| stub | *I* think that we should remove a file if its expiry date is in the past OR it is no longer references by any other database objects. However, and UDU there were calls (sabdfl?) to make it so files should only be removed if its expiry date is in the past | 03:53 |
| SteveA | it's SIP, so it will have the same restrictions on certain NATs and routers etc. as shtoom. The software may be more like a finished product. | 03:53 |
| stub | (full stop). So unexpired files hang around even if nothing references them | 03:54 |
| SteveA | someone finished a commercial zope3 project: http://griddlenoise.blogspot.com/2005/09/major-zope-3-client-project-finished.html | 03:54 |
| bradb | mpt: One thing I haven't quite figured out yet: if you're looking at the /malone page as an anon user, how do you go from that to viewing your assigned bugs page? Also, even if you already are logged in, does it make sense to have an "Assigned Bugs" link on the Malone front page with a dynamically-generated link that jumps you to FOAF? | 03:54 |
| SteveA | surely NULL should mean "i don't care when i'm GCed" | 03:54 |
| SteveA | ? | 03:55 |
| sabdfl | stub: requiring an expiry date then means that we can put all the policy of expiration in one place | 03:55 |
| SteveA | do we have a need to keep certain things forever in the librarian, if they're not referenced inside launchpad? | 03:55 |
| stub | I can't think of a use case for it, hence my enquiry ;) | 03:57 |
| === stub quickly checks the spec to see if the use case is there... | ||
| mpt | bradb: Your first question is a general problem that can also be expressed as "If you're looking at the /rosetta page as an anon user, how do you go from that to viewing the list of things you've been translating?" | 03:58 |
| stub | Heh.... in fact, all the use cases say 'file should be removed when no longer references' | 03:58 |
| bradb | mpt: I think the problem is slightly different here. The main issue that concerns me is having to jump between namespaces. | 03:58 |
| mpt | bradb: Perhaps we could have a magic user that forced you to login and then redirected you to the page for you in particular | 03:59 |
| mpt | e.g. reserve the name "you", then /people/you/+bugs redirects to /people/you/+bugs/+login which, when submitted, redirects to /people/bradb/+bugs | 03:59 |
| bradb | nobody, perhaps? | 04:00 |
| mpt | However, that may be a solution to a problem that doesn't really exist | 04:00 |
| mpt | We could just say "You must _log in_ to see bugs you're involved with in Malone" | 04:00 |
| bradb | I can even give them a /malone/+login link and redirect, i think, but is it bad to redirect to another namespace? | 04:00 |
| bradb | right | 04:01 |
| mpt | As J. Random Person I don't know what a "namespace" is in this context, so I'm going to say "No, I don't mind where you take me to" | 04:01 |
| bradb | ok | 04:02 |
| stub | sabdfl: So we create a file in the librarian for a persons hackergotchi. It has a NULL expiry because it shouldn't expire. The user uploads a new hackergotchi. The old hackergotchi is now unreferenced with a NULL expiry. Should the garbage collector remove it? The current spec says no, it will stay there for ever and ever. | 04:04 |
| stub | This might just be a bad choice of words in the spec, or might be important to some use case I don't get. | 04:05 |
| kiko | stub, yeah, you have a good point | 04:05 |
| kiko | but we have no way of saying that file X obsoletes file Y unless we use the filename, right? | 04:06 |
| sabdfl | it could be part of the EditView | 04:06 |
| sabdfl | "when replacing a previous hackergotchi, be sure to expire the old one | 04:07 |
| stub | kiko: The only way of doing it is at every point where a file is replaced with another, we set an expiry on the old file. And it also then means doing manual updates via SQL becomes a pita | 04:07 |
| stub | Remembering to do that at everypoint will be error prone I suspect... | 04:07 |
| kiko | stub, are the filenames always the same? | 04:08 |
| === Kinnison does a happy dance. Finally got an entire ubuntu published | ||
| stub | Could we use a date in the far future to refer a 'do not expire' file as opposed to a 'do not expire until referenced' file? | 04:08 |
| stub | kiko: No. | 04:08 |
| stub | kiko: Content doesn't have names anyway - it is just a blob. | 04:08 |
| === camilotelles [n=Camilo@200.128.80.250] has joined #launchpad | ||
| stub | erm.... ignore that last comment. | 04:08 |
| salgado | SteveA, I found a bug in our sqlobject that's already fixed upstream. I backported the fix (https://chinstrap.ubuntu.com/~dsilvers/paste/filekXqKBc.html), and this is something I definitely need for ShipItNG. It's only 20lines. can you review it for me? | 04:08 |
| sabdfl | Kinnison: rock | 04:08 |
| sabdfl | well done | 04:09 |
| sabdfl | Kinnison: are we close to bringing up a breezy-clone? upload, build, and publish? | 04:09 |
| SteveA | salgado: so, it is basically saying that bool columns can be Null | 04:10 |
| SteveA | and we want to treat None as Null, not as False in bool columns. | 04:10 |
| salgado | SteveA, exactly | 04:10 |
| SteveA | sounds good to me. do we have bool columns that aren't NOT NULL ? | 04:11 |
| stub | erm.... in english I mean saying 'if expires==NULL, then the file can be removed x hours after it is no longer referenced. If you need the file to remain permanently chewing up disk space, set the expiry to the NEVER_EXPIRE constant (a magic value of 1/1/2038). | 04:11 |
| stub | I still need a use case for a file that should hang around for ever if it is no longer referenced by anything. | 04:11 |
| Kinnison | sabdfl: Getting ever closer | 04:11 |
| salgado | SteveA, yes, we do. ShippingRequest.approved can have NULL values, meaning it's pending approval | 04:11 |
| Kinnison | sabdfl: This was a full publish of warty/hoary/breezy as imported by gina | 04:12 |
| Kinnison | sabdfl: so a *HUGE* job which showed up a few flaws in the publisher I finished in brazil last time :-) | 04:12 |
| === camilotelles_ [n=Camilo@200.128.80.250] has joined #launchpad | ||
| sabdfl | Kinnison: how long did the publish take? | 04:13 |
| vinsci | carlos, wow, the openwengo code repository is big :) | 04:13 |
| SteveA | salgado: i guess... i'm tempted to consider a DBSchema, so that the the "pending approval" state can appear nicely in a UI. but, if that's yagni, then okay. in any case, the patch to sqlobject looks good. i don't think we have anywhere that None is being passed in at present. maybe you can start off conservatively, and test it by asserting is not None, to check we aren't using None as False right now? | 04:13 |
| carlos | vinsci, I hope that's good :-) | 04:13 |
| Kinnison | sabdfl: Well, that run took ca. 30min | 04:14 |
| Kinnison | sabdfl: 10min of which was apt-ftparchive | 04:15 |
| sabdfl | ok | 04:15 |
| sabdfl | and is an update run faster than the first time creation? | 04:15 |
| salgado | SteveA, the pending approval will definitely appear as so in the UI. what you're suggesting is to add the assert and running our tests to check if something breaks? | 04:15 |
| Kinnison | sabdfl: I hope so. A totally initial publish is more like nine hours :-) | 04:15 |
| Kinnison | sabdfl: since we have to shovel about 100 gigs around and then get apt-ftparchive to run over it | 04:16 |
| SteveA | salgado: i was confusingly talking about two different things. | 04:16 |
| Kinnison | sabdfl: plus this is running on mawson which elmo says hasn't got much IO, and it's spewwing debug output at ca. 90kB/s | 04:16 |
| Kinnison | :-) | 04:16 |
| sabdfl | ok | 04:16 |
| SteveA | salgado: to land the patch: 1. add an assert that the value is never None in to_python and from_python in the BoolValidator. run all tests. if that works, apply the patch. | 04:17 |
| SteveA | salgado: the other point was to consider if using a dbschema rather than a tristate bool makes the shipit application any simpler. | 04:17 |
| === lamont__ [n=lamont@15.238.5.156] has joined #launchpad | ||
| Kinnison | sabdfl: It's quite odd debugging stuff which uses a megabit of bandwidth for its trace output :-) | 04:18 |
| salgado | SteveA, yes, that's what I understood about "starting off convervatively". I'll try it | 04:18 |
| salgado | SteveA, about the DBSchema, I don't think it's necessary, because you should use ShippingRequest.is[Approved,Denied,Pending] instead of directly accessing ShippingRequest.approved, anyway | 04:19 |
| kiko | stub, ping? | 04:20 |
| kiko | stub, can you pull marilize's account over to staging? | 04:20 |
| stub | kiko: Yup. It will be Person, EmailAddress, GPGKey and WikiName I guess. | 04:22 |
| stub | carlos: Or can I just reset the staging database to production? | 04:23 |
| kiko | I don't think she'll need GPGKey or WikiName for the test, stub | 04:23 |
| kiko | stub, I don't think carlos is going to like you if you do that :) | 04:23 |
| stub | She needs wikiname or some of our pages are broken ;) | 04:23 |
| kiko | aieee | 04:23 |
| carlos | stub, no, please, don't do that .... | 04:23 |
| carlos | stub, at least not today | 04:23 |
| kiko | heh | 04:23 |
| stub | carlos: ok. Just checking ;0 | 04:23 |
| carlos | stub, I will try to confirm you later today that you can run the script on production | 04:24 |
| carlos | after that, I will not mind at all of any update you do :-) | 04:24 |
| vinsci | carlos, we'll see ;) | 04:24 |
| SteveA | salgado: you might also do a quick scan of the Bool sqlobject fields we have in database classes, to make sure they're all NotNull so far | 04:24 |
| SteveA | salgado: if any are not NotNull, then we might have faulty data in those places. | 04:25 |
| carlos | kiko, Kinnison what's the status of gina run on production? | 04:27 |
| carlos | that would reduce a bit the time to generate language packs because I will be able to filter out any package outside main... | 04:28 |
| salgado | SteveA, good point. I'll do that | 04:28 |
| kiko | last I heard it was pending some diskspace | 04:28 |
| Keybuk | so I clicked on a bug ... did some stuff with it | 04:28 |
| Keybuk | now I can't get back to my product's bug listing | 04:28 |
| Kinnison | what TZ is Montral ? | 04:28 |
| vinsci | carlos, from the softphone-ng README, I like it already. The guys seems to understand software architecture well | 04:28 |
| Keybuk | if I click "Overview" it just goes back to the frontpage of launchpad | 04:29 |
| Keybuk | Kinnison: America/Montreal | 04:29 |
| salgado | carlos, language.py: visible = BoolCol(dbName='visible') | 04:29 |
| carlos | vinsci, I hadn't time to look into that | 04:29 |
| salgado | carlos, do you want NULL values on that column? | 04:29 |
| Kinnison | UTC-4, ta | 04:29 |
| carlos | salgado, no, thanks for the warning. Will fix it now | 04:29 |
| salgado | Kinnison, publishing.py: embargo = BoolCol(dbName='embargo', default=False) | 04:29 |
| salgado | Kinnison, I guess you definitely want NULL values on that column? | 04:30 |
| === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad | ||
| salgado | oops, sorry | 04:30 |
| vinsci | carlos, among other things, the same code base support GUIs for both Qt and GTK or "whatever toolkit you prefer" | 04:30 |
| Kinnison | erm, no, that needs a notNull=True | 04:30 |
| salgado | I misread it as default=None | 04:30 |
| carlos | vinsci, cool | 04:30 |
| salgado | Kinnison, do you want me to add it for you? | 04:30 |
| carlos | vinsci, I like it more now :-) | 04:31 |
| Kinnison | salgado: sure, if you're in the area | 04:31 |
| === vinsci gave up on GTK/Gnome a year or two ago | ||
| salgado | Kinnison, done | 04:32 |
| vinsci | so I wouldn't have minded non-gnome support ;-) It obviously better that it can provide both cleanly, though | 04:32 |
| Kinnison | Anyone know how long a flight from London to Montral will take? | 04:32 |
| salgado | carlos, pofile.py: rawfilepublished = BoolCol(notNull=False, default=None) | 04:32 |
| vinsci | Kinnison, london/la is 12 | 04:32 |
| vinsci | will ruin your whole day, anyway :) | 04:33 |
| salgado | carlos, do you rely on rawfilepublished being None somewhere? | 04:33 |
| Kinnison | vinsci: a 12 hr flight?! | 04:33 |
| vinsci | well, l.a. is quite a bit further away | 04:33 |
| salgado | cprov, codeofconduct.py: active = BoolCol(dbName='active', notNull=False, default=False) | 04:34 |
| salgado | cprov, I guess that line should have a notNull=True, no? | 04:34 |
| Kinnison | sabdfl: a run where nothing has changed is 17 minutes | 04:35 |
| Kinnison | sabdfl: and I think I can reduce that when I have more time to look at optimisations | 04:35 |
| sabdfl | ok super | 04:35 |
| Kinnison | but for now, I'm getting this publisher branch ready for a quick review and moving on | 04:35 |
| sabdfl | we don't need to stress about perf at this stage | 04:35 |
| cprov | salgado: yes, it's one of the many mistakes I did with notNull, are you correcting those ? | 04:35 |
| salgado | cprov, yes, I'm fixing it now | 04:36 |
| === mpt finishes reading BugTaskWatchLinkage and BugTasksAndExternalBugTrackers | ||
| Kinnison | sabdfl: indeed | 04:36 |
| Kinnison | sabdfl: < 30m is the target | 04:36 |
| SteveA | i have a 221 line diff.txt that i'd like a reviewer to look over and give me feedback on | 04:36 |
| Kinnison | sabdfl: so that ubuntu can refresh every half-hour like it does now | 04:36 |
| cprov | salgado: if you can use you regexp-fu to find them, it'll be perfect, because I suspect there are more :( | 04:36 |
| salgado | cprov, but I'm fixing only the ones related to BoolCol()s. might be good if you can have a look and check for other misuses of notNull | 04:37 |
| salgado | cprov, I can't be sure when they're misused or not. I'd have to ask for each one | 04:37 |
| mpt | bradb: Am I right in thinking that bug watches currently don't actually do anything, but they will in the future? | 04:37 |
| stub | kiko: Done, I think ;) | 04:37 |
| stub | kiko: oops.. hang on | 04:37 |
| cprov | SteveA: let me know when have time (~10 min) to talk about an issue I'm having to run tests as a restrict user, ok ? | 04:38 |
| sabdfl | SteveA: mail it to me | 04:38 |
| stub | kiko: ok | 04:38 |
| sabdfl | mpt: yes, they will in future suck in all related data from the remote bug tracker, regularly | 04:38 |
| stub | kiko: Should I email her, or are you dealing with it? | 04:38 |
| cprov | salgado: if you can build a list of all fields would be nice to sort it out easily, what do you think ? | 04:38 |
| bradb | mpt: You'd have to confirm with sabdfl as to whether the code that fetches and updates remote bug statuses is actually running on production. | 04:39 |
| sabdfl | it's not running, afaik | 04:39 |
| bradb | mpt: IOW, they're not really doing much, for the moment. | 04:39 |
| mpt | ok. | 04:39 |
| salgado | carlos, did you see my message about rawfilepublished a few lines above? | 04:40 |
| kiko | stub, I can email her, sure. thanks! | 04:42 |
| SteveA | sabdfl: sent | 04:44 |
| carlos | salgado, sorry, my server's raid controller start beeping and had to leave to see what happens | 04:46 |
| carlos | salgado, no, I think it should never be NULL | 04:46 |
| carlos | salgado, will fix it too | 04:46 |
| === camilotelles [n=Camilo@200.128.80.250] has joined #launchpad | ||
| sabdfl | SteveA: a bit of a hack, innit :-) | 04:47 |
| SteveA | yeah | 04:47 |
| SteveA | i looked at what is involved in checking the permission "internally", and decided it will be much easier when i've done some refactoring of the publisher which is coming up soon. | 04:47 |
| salgado | carlos, if you're sure it should never be NULL then I'll fix it. I need to have these fixes in before I merge my fix in sqlobject | 04:47 |
| carlos | salgado, the only situation where I can think it could be NULL is with old data, but that means that the data migration done when that field was added was a bit... hacky | 04:48 |
| sabdfl | SteveA: any reason not to address this TODO now? | 04:48 |
| sabdfl | + # TODO: Check whether logged in at all. If not logged in, either + # show an error, or fail transparently. | 04:48 |
| carlos | salgado, so go ahead | 04:48 |
| sabdfl | carlos: lang pack status? | 04:49 |
| carlos | salgado, I have the language one fixed already and ready to request a rocketfuel merge should I stop that? | 04:49 |
| === camilotelles__ [n=Camilo@200.128.80.250] has joined #launchpad | ||
| carlos | sabdfl, seems like whitespace issue is gone. I got a couple of errors that I need to check if it's a corner case or not but that is not blocking language packs anymore | 04:50 |
| salgado | carlos, well, if you're going to request a merge, then I'd ask you to fix the rawfilepublished too. ;) | 04:50 |
| salgado | carlos, can you do that? | 04:50 |
| sabdfl | carlos: well done | 04:50 |
| SteveA | sabdfl: good point. what do you think it should do? if not logged in at all, then just redirect as normal. if logged in using basic auth... probably just redirect again. the worst we get is someone continually pressing "logout" and then filing a bug. but this won't occur for normal use of the system. | 04:50 |
| carlos | sabdfl, https://launchpad.net/malone/bugs/1566 is an issue now but we can workaround it easily as it's a matter of remove all obsolete entries. Anyway I'm fixing the code now so that would the plan B | 04:50 |
| carlos | salgado, sure | 04:50 |
| sabdfl | where would they press "logout"? | 04:50 |
| carlos | sabdfl, thanks, but that should be fixed long ago... I'm not too proud of that... | 04:51 |
| mpt | bradb: eh, fmt:icon returns me escaped HTML (full of < and >) rather than real HTML | 04:51 |
| bradb | mpt: did you use structure? | 04:52 |
| bradb | content="structure .../fmt:icon", etc? | 04:52 |
| mpt | bradb: bingo, thanks | 04:52 |
| bradb | np | 04:52 |
| Kinnison | SteveA: Is there any way to run a given test as a particular database user? (This is a potential BLOCKER for soyuz until we know either way) | 04:53 |
| carlos | salgado, hmmm POFile.rawfilepublished does not have the NOT NULL constraint at DB level... | 04:53 |
| salgado | Kinnison, look at the test for the foaf-karma-updater cronscript, it uses the karma dbuser | 04:53 |
| SteveA | Kinnison: basically, yes. but it means you need to take more responsibility for that test's setup | 04:53 |
| Kinnison | okay thanks | 04:54 |
| carlos | so that's not a trivial fix, I cannot fix that now | 04:54 |
| Kinnison | salgado: erm, this is a doctest, not a script :-) | 04:54 |
| Kinnison | are there any doctests which do this? | 04:54 |
| sabdfl | carlos: do we keep the distro po templates around, are they accessible for a later parsing? | 04:55 |
| sabdfl | i'm trying to think how best to avoid this review-breezy-xxx stuff | 04:56 |
| sabdfl | i think we need a table where we store the potemplate details we were not able to match up | 04:56 |
| carlos | sabdfl, http://people.ubunut.com/~lamont/translations/ | 04:56 |
| salgado | Kinnison, oh, sorry. I forgot the user is specified in the script and not in the test | 04:56 |
| carlos | sabdfl, there you have all .po and .pot files that were ever imported into Rosetta | 04:56 |
| sabdfl | then jordi should review that daily, and say which template belongs where | 04:56 |
| carlos | sabdfl, yeah, that system would be really good | 04:57 |
| carlos | I'm a bit overloaded fixing templates from time to time | 04:57 |
| SteveA | thanks for the review, sabdfl | 04:57 |
| carlos | sabdfl, I was thinking on an "easy" fix with the major problem that creates lots of review-* templates | 04:57 |
| sabdfl | carlos: ok, what's that? | 04:57 |
| carlos | checking if the path has the tarball version number | 04:58 |
| carlos | if it's build/gtk+2.8.3/po | 04:58 |
| carlos | instead of create a new potemplate when the 2.8.4 is imported | 04:58 |
| carlos | we could try to guess that it's an update | 04:58 |
| carlos | it's an easy fix | 04:58 |
| carlos | but your solution is the way to go | 04:59 |
| cprov | salgado: doc/karmaupdater.txt is pointless for my issue, it executes another process., did you mean other file ? | 04:59 |
| carlos | as a long term solution | 04:59 |
| lamont__ | carlos: btw, we just made the fixes to get translations back into ~lamont/translations for you... with a large influx as a result (I wasn't sure how far back to go, so I expect I overshot...) | 04:59 |
| carlos | lamont__, yeah, thank you, I saw that, the import queue has now more than 3000 pofiles to import.... | 04:59 |
| carlos | ;-) | 05:00 |
| lamont__ | well, maybe 20 july was a bit overkill... | 05:00 |
| carlos | WaterSevenUb, that means that synaptic should appear soon | 05:00 |
| lamont__ | :-) | 05:00 |
| carlos | lamont__, already imported .po files will be ignored | 05:00 |
| salgado | SteveA, a lot of tests are failing if I add the assert on the validator, all of them in rosetta, aparently | 05:00 |
| carlos | lamont__, so it should not be a problem | 05:00 |
| carlos | salgado, which assert? | 05:00 |
| SteveA | salgado: can you paste up a typical stack trace you get from the assert? | 05:01 |
| lamont__ | carlos: way cool | 05:01 |
| bradb | SteveA: it appears to me that code in a view's constructor gets run even when the current user doesn't have the permissions to view that page. (e.g. I have some view code which grabs the current user and redirects them somewhere else because of a changing URL, but user.name raises an AttributeError on NoneType when the user is shown the login prompt to be auth'd to reach the page.) | 05:01 |
| === jinty [n=jinty@205.134.224.215] has joined #launchpad | ||
| bradb | if what i think is happening really is happening, that would appear to be a security hole | 05:02 |
| salgado | SteveA, https://chinstrap.ubuntu.com/~dsilvers/paste/filenmCN0N.html | 05:03 |
| SteveA | bradb: a view's constructor will be called in a variety of situations. i keep saying that there should be no significant code in a view's constructor. | 05:03 |
| ddaa | mpt: pouet! | 05:04 |
| bradb | SteveA: Is this a security hole? | 05:04 |
| SteveA | bradb: i don't think so. views are not "assets". the content classes are the assets. | 05:04 |
| mpt | ddaa: que? | 05:04 |
| bradb | mpt: "slut" :P | 05:04 |
| stub | Kinnison: At the moment I think you subclass LaunchpadFunctionalTestSetup or LaunchpadZopelessTestSetup and override the dbuser attribute | 05:05 |
| SteveA | so, at worst, having significant actions in a view's constructor can lead to usability issues. | 05:05 |
| salgado | carlos, it's an assert in sqlobject. I added it to make sure we're not inserting NULL values in BoolCol columns, because our sqlobject can't cope with that (it'll always return False for NULL columns) | 05:05 |
| carlos | I need to leave for an hour and a half. Anyone needs anything urgent from me? | 05:05 |
| bradb | SteveA: I'm able to run code that drives a page that I don't have the permission to access. I'm trying to figure out how that isn't a security hole. ;) | 05:05 |
| mpt | ddaa: What have I done now? | 05:05 |
| ddaa | mpt: I'm working on branch-summary-listing.pt right now. I would like to add a href somewhere to the canonical branch url. Where should I do that? | 05:05 |
| Kinnison | stub: heh | 05:06 |
| stub | Kinnison: If that is a PITA, feel free to add arguments to the setUp method to pass in the user to connect as. | 05:06 |
| stub | (I could have sworn it already worked that way ;/) | 05:06 |
| mpt | ddaa: From the branch's name | 05:06 |
| ddaa | If it were me I would put it in the <b>branch title</b>, except I would not be using <b>, and I would be using some CSS so the hyperlink would not be underlined when the mouse is not over it. | 05:06 |
| carlos | salgado, hmm, I will fix the pofile.rawfilepublished issue then today, it will need db changes + code changes and it's not trivial is that fast enough for you or you need it now? | 05:06 |
| ddaa | mpt: the branch name is not present in the mockup | 05:06 |
| Kinnison | stub: perhaps when I have more time | 05:06 |
| SteveA | bradb: you are not running code that "drives a page". you are using vague language to try to make a point. | 05:07 |
| mpt | ddaa: Where's the mockup? | 05:07 |
| ddaa | branch-summary-listing.pt | 05:07 |
| salgado | carlos, if you can fix it today then it's not a problem. thanks. :) | 05:07 |
| mpt | ddaa: I spy a "context/title" in there | 05:08 |
| carlos | salgado, could you mail me the list of problems you get? | 05:08 |
| ddaa | mpt: ha, that's the title then | 05:08 |
| carlos | salgado, or is it only POFile.rawfilepublished ? | 05:08 |
| lifeless | q/win 19 | 05:08 |
| bradb | SteveA: Ok, moving on. Is a redirect in a view constructor considered "significant code". | 05:08 |
| bradb | s/\./?/ | 05:08 |
| ddaa | mpt: what's the procedure to get cosmetic improvements (like the CSS trick I just mentioned) done? | 05:09 |
| SteveA | bradb: i'm kinda busy with at least two things happening at once. can you mail me a detailed description of what you want to know? | 05:09 |
| bradb | ok :) | 05:09 |
| ddaa | mpt: "don't, just nag me until it's done" is an acceptable answer. | 05:09 |
| mpt | ddaa: IMO the CSS trick you mentioned would not be an improvement | 05:09 |
| salgado | carlos, I'll run the tests now with "rawfilepublished = BoolCol(notNull=True, default=False)" and see if something is still broken | 05:09 |
| mpt | ddaa: So is just "don't" an acceptable answer? :-) | 05:10 |
| ddaa | mpt: IMO you want to have "hyperlink" color for the title, but you do not want to have them all underlined. | 05:10 |
| carlos | salgado, ok, thanks. Mail me it and I will look into it as soon as I'm back | 05:10 |
| carlos | see you later | 05:10 |
| ddaa | but I'm not the UI professional here. | 05:10 |
| SteveA | salgado: that error is happening in the toPython assert. so, it seems to me that means there is a NULL in the database at that point. | 05:11 |
| mpt | ddaa: I'd really rather just have them all underlined. | 05:11 |
| ddaa | yuck | 05:11 |
| SteveA | salgado: if that's so, it means we need to do some cleaning up of NULLs in the production database before we can roll out that sqlobject patch. | 05:11 |
| === ddaa goes to make his ugly page template | ||
| lifeless | ddaa: non underlined urls are mystery meat and very bad | 05:11 |
| lifeless | _very_ | 05:12 |
| SteveA | salgado: this concerns me, so i'd like to get stub's input. | 05:12 |
| mpt | mmmmmystery meat navigation | 05:12 |
| ddaa | bah | 05:13 |
| salgado | SteveA, I'm pretty sure all we need is to run "update pofile set rawfilepublished = FALSE where rawfilepublished IS NULL;" | 05:13 |
| stub | If BoolCol can't cope with NULL, it is broken. Python has True, False and None, PostgreSQL has true, false and NULL. Shouldn't be a problem. | 05:13 |
| salgado | stub, in our current sqlobject version it can't | 05:14 |
| salgado | but that's fixed in upstream and I need to backport this change | 05:14 |
| stub | ok | 05:14 |
| SteveA | stub: current sqlobject's boolcol converts NULL/None into False transparently, both ways | 05:14 |
| lifeless | salgado: give the backported change to spiv to merge, he has rights to sqlobject IIRC | 05:14 |
| SteveA | the patch salgado wants to backport makes it a tri-state when the column is declared Non-Null | 05:15 |
| salgado | lifeless, I have rights too (I guess everybody does) | 05:15 |
| lifeless | salgado: sqlobject ? | 05:15 |
| salgado | lifeless, the problem is that wee need to fix our existing data | 05:15 |
| lifeless | hmm, it is set to canonical, whaddya know | 05:15 |
| bradb | salgado: I can't find a doctest for PersonView. Is the view class tested anywhere? If not, I'll create a new test right now, for the methods I'm interested in. | 05:16 |
| SteveA | i am surprised that we have faulty data, because the existing code looked like it never sets a NULL. | 05:16 |
| stub | salgado: rawfilepublished will always be NULL if rawfile is NULL | 05:16 |
| SteveA | so it would be non-sqlobject code that has put NULLs in | 05:16 |
| stub | The NULLs would be default values | 05:17 |
| salgado | stub, so, it should allow NULLs | 05:17 |
| salgado | carlos said it shouldn't allow NULL values | 05:17 |
| salgado | bradb, no, there's no test for that view --it's tested only by page tests | 05:17 |
| stub | It could be modeled either way. | 05:17 |
| bradb | ok, I'm creating one now, thanks | 05:17 |
| carlos | salgado, hmmm, stub is right, I assumed that POFile.rawfile is NOT NULL and that's not true... | 05:19 |
| stub | I prefer it being NULLable myself - gives me more flexibility setting up partial indexes and other stoof | 05:19 |
| carlos | salgado, stub I don't mind to fix it so 'not null' is not valid or leave it as it's atm | 05:19 |
| stub | I think to fix the data, using the current schema definition unchanged, we could do 'UPDATE pofile SET rawfilepublished=FALSE WHERE rawfilepublished IS NULL and rawfile IS NOT NULL' | 05:20 |
| stub | (if there is actually broken data) | 05:21 |
| carlos | stub, yeah, it sounds ok for me | 05:25 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Language.visible is NOT NULL (patch-2357: carlos.perello@canonical.com) | 05:28 |
| carlos | salgado, there you have it | 05:28 |
| carlos | later! | 05:28 |
| salgado | SteveA, so, what's the plan for the sqlobject fix? aparently the only other BoolCol that we should allow NULL values is the rawfilepublished | 05:32 |
| SteveA | salgado: overall, if stu is happy with the integrity of production data, and the existing BoolCols that are wrong are being fixed right now, then go ahead and apply the patch to sqlobject. | 05:33 |
| sd-tux | hi carlos , how can i download a translation/.po from roseta... "Download translations" don't work because of BUG #1978 | 05:34 |
| stub | launchpad_prod=# select count(*) from pofile where rawfile is not null and rawfilepublished is null; | 05:41 |
| stub | count | 05:41 |
| stub | ------- | 05:41 |
| stub | 9250 | 05:41 |
| stub | (1 row) | 05:41 |
| stub | So we need that update as a DB patch when the bug gets fixed. | 05:41 |
| === stub goes to bed | ||
| === mpt wonders what "There are currently no links to this bug watch" means | ||
| salgado | stub, I'll add that db patch as part of my last shipitng changes, because the sqlobject will need to be updated in production when we cherrypick the shipit changes | 05:45 |
| bradb | mpt: There are currently no tasks linked to that watch, perhaps. Not sure how to say that without sounding like you're being talked at by a computer. | 05:45 |
| elmo | stub: still here? ;) | 05:45 |
| stub | elmo: just! | 05:46 |
| ddaa | What's involved in making a discussion thing work for branches? | 05:46 |
| elmo | stub: just for my sanity - you want full debbugs mirrors on both production and staging? | 05:46 |
| ddaa | stub: ^^ | 05:47 |
| stub | elmo: Yes. We will need both. Staging before production, but I thought I'd put in the production request early. | 05:48 |
| bradb | mpt: Maybe making watch adding part of task adding/editing would eliminate the need for that wording entirely. | 05:48 |
| elmo | stub: ok | 05:48 |
| bradb | I can't think of a use case for an orphan bugwatch. | 05:48 |
| stub | ddaa: From the database side, you create a BranchMessage table which links Branch to Message. See BugMessage or *Message for details. UI I don't know if we have anything generic. | 05:50 |
| ddaa | stub: I have a BranchMessage table in BranchDataStorage.sql | 05:51 |
| ddaa | stub: who would know about generic discussion UI foo? | 05:51 |
| stub | ddaa: sabdfl might be your best bet - I think he has knocked this up for bounties and tickets and might have stuff for you to pinch or reuse. | 05:52 |
| === Nafallo [i=nafallo@c-459571d5.07-44-73746f50.cust.bredbandsbolaget.se] has joined #launchpad | ||
| === ddaa decides it's time for a smoke | ||
| ddaa | sabdfl is not around right now | 05:53 |
| sabdfl | ddaa: ? | 05:53 |
| === Nafallo_ [n=nafallo@unaffiliated/nafallo] has joined #launchpad | ||
| ddaa | well, I'll have a smoke anyway :) | 05:54 |
| ddaa | next I think you can come have a look and tell us what would suit your fancy | 05:54 |
| Kinnison | SteveA: can you cast your eye over that branch so I can merge those publisher fixes? | 05:55 |
| salgado | Kinnison, binarypackagerelease.py: essential = BoolCol(dbName='essential') | 05:55 |
| salgado | binarypackagerelease.py: architecturespecific = BoolCol(dbName='architecturespecific') | 05:55 |
| salgado | Kinnison, default=False, nutNull=True? | 05:55 |
| salgado | (I mean, can I add that?) | 05:55 |
| Kinnison | salgado: for the first yes | 05:55 |
| Kinnison | salgado: the secnd should be notNull=True, but no default declarator | 05:55 |
| salgado | okay | 05:55 |
| stub | sabdfl: I was wondering if you had any generic front end to Message and *Message tables you might have knocked up as part of Bounties or ticketing | 05:56 |
| stub | sabdfl: Because ddaa is looking at the message spool for branches | 05:56 |
| SteveA | messages are always to do with presentation, so there will always be a request available | 05:56 |
| SteveA | so, can you make it an API on the request? | 05:57 |
| SteveA | either directly, or via an adapter | 05:57 |
| mpt | bradb: Yeah, you have to add a watch, and then you have to link a task to one of the watches ... It's too much like work. | 05:57 |
| SteveA | Kinnison: which branch exactly? | 05:57 |
| Kinnison | SteveA: the one I added to your review queue a short while ago? | 05:57 |
| === SteveA remembers at last to subscribe to the PendingReviews page, seeing as the reviews list seems to have lost its subscription | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=jamesh] Supporting architeture coherent builder-queue construction, (build architecuture independent or specific) and process run-time tests. (patch-2358: celso.providelo@canonical.com) | 05:59 |
| SteveA | Kinnison: aw poop, it isn't on jamesh's pending reviews page yet | 06:00 |
| elmo | hey, can I kill python2.3 from our servers? | 06:00 |
| Kinnison | SteveA: If I can be in a position to merge it (either merge-approved or merge-conditional) by the time I get back from bowling later tonight, I'll be happy. So you can wait a bit | 06:01 |
| SteveA | elmo: cautiously yes, but i'll mail the launchpad list about it | 06:02 |
| SteveA | elmo: i don't know what version of python stub has plugged into postgresql | 06:03 |
| lifeless | 2.3 I think | 06:04 |
| lifeless | I'm sure he has had to backport some stuff a little | 06:04 |
| lifeless | kiko - any luck with the photos ? | 06:04 |
| mpt | lifeless: What did you mean by "'Remote Bug Details' could with some in-your-face help" in <https://launchpad.net/malone/bugs/1208>? | 06:13 |
| mpt | Is that help as in "here's how to use this thing", or help as in fixing the design? | 06:13 |
| lifeless | ask brad :0 | 06:14 |
| lifeless | I was sitting with him and we saw a page, and I was plain scared by it | 06:14 |
| mpt | ok | 06:16 |
| bradb | I recently observed Burgundavia wondering what a bug watch was all about too. | 06:17 |
| bradb | Sounds like this needs the same kind of love I gave to release targeting | 06:18 |
| kiko | mpt, please use a consistent name over all fields when you do fix that :-) | 06:18 |
| === bradb nominates "prioAndSevFilter" as one of the stranger variable names I've seen in LP code | ||
| sabdfl | spiv: still reviewing? | 06:21 |
| sabdfl | salgado: "whoxxx" is different to all the other db field names for a person | 06:21 |
| sabdfl | typically we use a role name | 06:22 |
| sabdfl | assignee | 06:22 |
| sabdfl | reporter | 06:22 |
| sabdfl | or similar | 06:22 |
| salgado | sabdfl, IIRC that was the name we were using in our discussions here in Brazil. that's why I kept it | 06:23 |
| salgado | (I assume you're talking about shipit?) | 06:23 |
| bradb | mpt: Would it be any great crime for now if I removed the "bugs with shared interest" part of the +assignedbugs page? It's non-trivial to test, and might be spending time on the wrong thing until we've learned more about how Real People are actually using this report, IMHO. | 06:28 |
| kiko | bradb, I think it should stay | 06:30 |
| kiko | don't test it for now if you are blocked by this | 06:30 |
| kiko | and btw | 06:30 |
| kiko | why are you changing that page? | 06:30 |
| bradb | ok, i'll leave it untested | 06:30 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=sabdfl] improvements to logout pages (patch-2359: steve.alexander@canonical.com) | 06:30 |
| bradb | kiko: I'm not changing anything user visible, I'm just adding tests for the view, because that's now the page you land on when you click "Assigned Bugs" from the Malone front page (bye bye /malone/assigned...fixing a criticalish bug in that report that's preventing mpt from accessing the full list of his assigned bugs.) | 06:31 |
| kiko | what was the criticalish bug, btw? | 06:32 |
| kiko | great that you nuked the page though | 06:32 |
| bradb | kiko: Permission Denied. I don't think /malone/assigned is handling privacy correctly; not calling the correct APIs is my guess (but that page is in bad need of nuking either way :) | 06:32 |
| kiko | heh | 06:33 |
| kiko | carlos, ping? | 06:33 |
| bradb | /malone/assigned will continue to work, but it'll just redirect you to the right place in FOAF now | 06:33 |
| === bradb follows the word of Jakob | ||
| sabdfl | all hail jakob | 06:40 |
| SteveA | "there are no cows on the ice" | 06:40 |
| Kinnison | SteveA: thanks for that review. I'll get onto it ASAP. As for the amount of database code outside of c.l.d.* I agree it's annoying from the PoV of discoverability. I'll put "Move soyuz db queries into c.l.d.*" onto my longer-term todo if that's okay with you? Something for me to tackle in UBZ perhaps? | 06:42 |
| SteveA | why were they constructed outside of there in the first place? | 06:42 |
| kiko | why aren't you adding API to your database objects? | 06:42 |
| kiko | SteveA's words are my own | 06:43 |
| Kinnison | Because at the time I didn't understand how we were laying stuff out and I just wanted to code so I did things the way I've done them in the past (I.E. not as well as I should). For the most part they should be fairly simple to move but I'm loathe to do such refactoring until such a time as I'm not the critical path for the next Ubuntu release :-) | 06:44 |
| Kinnison | It's not an excuse, I know. But it is the reason | 06:45 |
| === kiko is unhappy | ||
| SteveA | Kinnison: do you think someone other than you can move things into their correct places? do you trust the tests enough to allow others to make moves like that? | 06:46 |
| kiko | putting the database code in the database classes means the APIs were properly designed | 06:49 |
| kiko | why would it be less traumatic to move the database code later, when we are already being used daily? | 06:49 |
| Kinnison | SteveA: for now I don't want to risk having conflicts. Once I've got the breezy tracker running properly I'll be in a better position to rearrange things. Celso would probably be a good person to do the rearrangement. | 06:51 |
| SteveA | Kinnison: when do you think that time will be? | 06:52 |
| Kinnison | SteveA: I have a personal deadline of the end of this week to have it at least limping along | 06:52 |
| Kinnison | SteveA: I agreed that deadline with mark and celso | 06:52 |
| SteveA | kiko: what do you think? have a rearrangement of this database code in a couple of weeks from now/ | 06:53 |
| SteveA | ? | 06:53 |
| kiko | I still don't understand why once the tracker is running we're in a better position to rearrange the code | 06:54 |
| kiko | and not putting database code in database objects often means the APIs your software is using are wrong | 06:54 |
| Kinnison | kiko: because until the tracker is running, I will be in a major code crunch and at the same time I may have to change things at the drop of a hat, which makes conflict resolution a complete arse. | 06:57 |
| === Kinnison apologises | ||
| Kinnison | my personal stress levels are getting in the way of my work | 06:57 |
| Kinnison | I'll see what I can do to tidy up this code when I get back later tonight | 06:58 |
| Kinnison | bbl | 07:00 |
| === Kinnison has his cell if he's needed. | ||
| SteveA | salgado-lunch: got shipit running here. getting some schooltool expertise to help -- they've done this before | 07:15 |
| kiko | SteveA, wooo! | 07:15 |
| Nafallo | carlos: when do we have gajim in breezy rosetta? :-) | 07:24 |
| kiko | <kiko> should I make private bugs which have tracebacks? | 07:29 |
| kiko | <kiko> it's very inconvenient and often impossible | 07:29 |
| SteveA | i don't see why having a traceback is enough reason on its own to make a bug private | 07:31 |
| SteveA | if the traceback reveals sensitive security-related stuff, then perhaps | 07:32 |
| SteveA | but not in general | 07:32 |
| kiko | it reveals implementation details. | 07:32 |
| kiko | but I'm happy if you're happy! | 07:35 |
| Nafallo | carlos: "Administrator help needed. Gajim has not yet been setup for translation through Rosetta." | 07:35 |
| Nafallo | carlos: please do ;-) | 07:35 |
| mpt | kiko: #launchpad also reveals implementation details | 07:40 |
| kiko | mpt, so it does, so it does | 07:41 |
| SteveA | hi sabdfl | 07:44 |
| SteveA | um | 07:44 |
| SteveA | Exchat | 07:44 |
| SteveA | hi salgado | 07:44 |
| carlos | Nafallo, please, follow the instructions at https://wiki.ubuntu.com/RosettaFAQ | 07:47 |
| carlos | kiko, pong | 07:47 |
| kiko | carlos! | 07:48 |
| Nafallo | carlos: oh, nice :-). thanx | 07:48 |
| kiko | jordi, ping? | 07:59 |
| SteveA | jblack: ping | 08:00 |
| Nafallo | carlos: added on RosettaPendingImports :-) | 08:03 |
| carlos | Nafallo, thank you | 08:03 |
| === dda1 [n=ddaa@217.205.109.249] has joined #launchpad | ||
| bradb | kiko: Would you be willing to review my assigned bugs report fixes patch? | 08:07 |
| bradb | It's criticalish, so I'm hoping to get it in today to rollout by tomorrow. | 08:08 |
| kiko | uhm | 08:09 |
| kiko | how long? | 08:09 |
| bradb | kiko: 11 files changed, 201 insertions(+), 144 deletions(-) | 08:12 |
| kiko | bradb, sure, put it up on the reviews page in my section | 08:14 |
| bradb | will do, thanks | 08:15 |
| bradb | mpt: So, the fix which I believe will fix your assigned bugs perms problem (and seriously desuckify what happens when you visit /malone/assigned, or click the link on the Malone front page) is in kiko's review queue now. | 08:33 |
| jblack | steva: pong | 08:40 |
| SteveA | hi jblack . just wondering if there's going to be a baz updates meeting this week. can you send an email to the usual suspects to confirm? | 08:42 |
| jblack | Hasn't this already been settled? an hour before the launchpad meeting every thursday? | 08:43 |
| SteveA | didn't know it was regular, and it helps to send out a reminder if you're the meeting convener | 08:43 |
| === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad | ||
| jblack | I thought you were. ;) | 08:45 |
| jblack | I'll send out an email today. :) | 08:46 |
| SteveA | cool | 08:46 |
| SteveA | good night folks | 08:46 |
| kiko | night SteveA | 08:46 |
| === niemeyer calls kiko just to see the nick changing again.. | ||
| niemeyer | ;) | 08:47 |
| kiko | heh | 08:47 |
| kiko | fixed all of them now | 08:47 |
| sabdfl | spiv: still reviewing? | 08:49 |
| mpt | bradb: great -- it'll certainly help me to see all the bugs assigned to me in one place | 08:50 |
| === Adam-_ [n=uimp@217.124.95.61] has joined #launchpad | ||
| bradb | hm, /me is overwhelmingly giddy to try out Z3 form error messages after the URL dragon has been slayed | 08:57 |
| bradb | i'm on a mission to make our failure modes not suck | 08:58 |
| bradb | BjornT: ping | 08:59 |
| kiko | ConfigurationError: ('Invalid value for', 'class', "Couldn't import canonical.launchpad.browser, cannot import name WIPRevision") | 09:03 |
| kiko | any clue why I'm getting this? | 09:03 |
| bradb | kiko: __all__? | 09:03 |
| kiko | this is on a hopefully clean tree, though | 09:03 |
| bradb | mm | 09:04 |
| bradb | kiko: update cscvs | 09:04 |
| kiko | rocketfuel@canonical.com/cscvs--devel--1.0 | 09:04 |
| kiko | * tree is already up to date | 09:04 |
| kiko | @#!@# | 09:04 |
| bradb | fear becomes me | 09:05 |
| bradb | bradb@oxygen:~/launchpad $ baz resolved lib/canonical/launchpad/browser/bug.py | 09:08 |
| bradb | 1 conflicts remain in this tree | 09:08 |
| bradb | Requested conflicts have been resolved | 09:08 |
| bradb | that is a confusing message to me | 09:08 |
| bradb | SteveA: around? | 09:12 |
| kiko | nope | 09:12 |
| kiko | he's gone | 09:12 |
| bradb | hm | 09:12 |
| bradb | I've run into more pain with using IBugTask as the context. | 09:13 |
| kiko | I suspected so | 09:13 |
| bradb | e.g. for the bug description editing page | 09:13 |
| bradb | name="+edit" | 09:13 |
| bradb | for="...IBugTask" | 09:13 |
| bradb | schema="...IBug" | 09:13 |
| bradb | and here's the real kicker... | 09:13 |
| bradb | permission="...hahah!" | 09:13 |
| bradb | permission checking is done on the thing named in for="" | 09:14 |
| bradb | so, the permission checking to edit bug attributes is done on the bug *task* | 09:14 |
| bradb | with IBugInContext, ABICT, this view could have simply been registered for="...IBug", because IBiC inherits from IBug. in that case, i believe it would just work. | 09:16 |
| niemeyer | Keybuk: ping | 09:19 |
| === bradb writes SteveA an email | ||
| Keybuk | niemeyer: heyhey | 09:21 |
| niemeyer | Keybuk: Hi :) | 09:21 |
| niemeyer | Keybuk: Would you be able to explain a bit the structure you've used for patches? | 09:22 |
| niemeyer | Keybuk: I'm curious about, for instance, what happens when the software version changes. | 09:22 |
| Keybuk | I'll have to answer this with a story | 09:23 |
| Keybuk | we'll use a simple source package that has a tarball and a patch in it | 09:23 |
| Keybuk | import version 1.0-1 and we get | 09:23 |
| Keybuk | + simple--orig--1.0 | 09:23 |
| === niemeyer takes his chimarro and listens carefully.. | ||
| Keybuk | + simple--patch-name--1.0 | 09:23 |
| Keybuk | simple--orig--1.0--base-0 is the contents of the tar file | 09:24 |
| Keybuk | simple--patch-name--1.0--base-0 is the continuation of that | 09:24 |
| Keybuk | simple--patch-name--1.0--patch-1 is with the patch applied | 09:24 |
| Keybuk | -- | 09:24 |
| Keybuk | so far, so as expected | 09:24 |
| niemeyer | What about --diff--? | 09:24 |
| Keybuk | DON'T INTERRUPT :p | 09:24 |
| === niemeyer :X | ||
| Keybuk | so we import 1.0-2 now | 09:25 |
| Keybuk | this only has some changes to the patch, and none of | 09:25 |
| Keybuk | the tarball itself | 09:25 |
| Keybuk | so we don't change simple--orig--1.0 at all | 09:25 |
| Keybuk | simple--patch-name--1.0--patch-2 is the "update" to the patch branch | 09:25 |
| === SnakeBite [n=SnakeBit@84.242.143.64] has joined #launchpad | ||
| Keybuk | so if we checkout patch-1 we get the state for 1.0-1 and if we checkout patch-2 we get the state for 1.0-2 | 09:26 |
| Keybuk | -- | 09:26 |
| Keybuk | now let's import 1.0-3 which has changes to _both_ | 09:26 |
| Keybuk | simple--orig--1.0--patch-1 is the "update" to the tar file | 09:26 |
| Keybuk | we merge those changes onto the patch-name branch (to update the patch to 1.0-3) | 09:26 |
| Keybuk | simple--patch-name--1.0--patch-3 is the "update" for the changes to the tar file | 09:27 |
| Keybuk | we then import the patch changes onto the patch branch | 09:27 |
| Keybuk | simple--patch-name--1.0--patch-4 has those | 09:27 |
| Keybuk | -- | 09:27 |
| Keybuk | and lastly 1.0-4 has only changes to the tarfile | 09:27 |
| Keybuk | simple--orig--1.0--patch-2 is the update | 09:27 |
| Keybuk | and again, we merge those changes onto the patch branch | 09:27 |
| Keybuk | simple--patch-name--1.0--patch-5 is that update | 09:27 |
| Keybuk | no changes to the patch need to be imported, so that's that job done | 09:28 |
| Keybuk | -- | 09:28 |
| Keybuk | those are the "simple" operations | 09:28 |
| niemeyer | Ack | 09:28 |
| Keybuk | now, when the upstream version changes, we do something different | 09:28 |
| === carlos ->dinner | ||
| carlos | see you | 09:28 |
| niemeyer | carlos: Have a nice dinner | 09:28 |
| Keybuk | so we import 2.0-1 which has changes to both, and for fun, let's add a new patch too | 09:29 |
| niemeyer | (conflicts, please :) | 09:29 |
| Keybuk | we /branch/ the simple--orig--1.0 branch | 09:29 |
| Keybuk | so we create simple--orig--2.0--base-0 as a continuation of the last state of 1,0 | 09:29 |
| Keybuk | and simple--orig--2.0--patch-1 to "update" that to the contents of the tarball as we found it | 09:30 |
| niemeyer | Hummm.. interesting | 09:30 |
| Keybuk | that probably makes some sense, here's where it gets fun | 09:30 |
| Keybuk | we now need to do the same for the patch | 09:30 |
| Keybuk | we branch the simple--orig--2.0 branch _NOT_ the last patch branch | 09:30 |
| Keybuk | we then merge the changes from the last patch branch onto it | 09:30 |
| Keybuk | and then finally update it | 09:31 |
| Keybuk | simple--patch-name--2.0--base-0 is a continuation of simple--orig--2.0 | 09:31 |
| Keybuk | simple--patch-name--2.0--patch-1 is the merge of the simple--patch-name--1.0 branch | 09:31 |
| Keybuk | simple--patch-name--2.0--patch-2 is the update to the actual patch contents | 09:31 |
| niemeyer | By "changes from the last patch branch" you mean changes from patch-name--1.0--patch-N to orig--1.0--patch-N? | 09:31 |
| Keybuk | yes | 09:32 |
| Keybuk | delta the branch and apply it | 09:32 |
| Keybuk | adding a new patch is easy | 09:32 |
| Keybuk | branch simple--orig--2.0 (to simple--new-patch--2.0--base-0) and update it with the applied content of the patch (patch-1) | 09:32 |
| niemeyer | Understood | 09:33 |
| Keybuk | so you understand that? | 09:33 |
| niemeyer | Yes | 09:33 |
| Keybuk | good ... | 09:33 |
| Keybuk | so let's take a _real world_ example | 09:33 |
| Keybuk | we have the simple_1.0.orig.tar.gz | 09:33 |
| Keybuk | which is slightly different from simple-1.0.tar.gz the upstream one | 09:33 |
| Keybuk | and we found the differences on the CVS import of simple's upstream | 09:34 |
| Keybuk | and there was a previous import of simple_0.9.orig.tar.gz | 09:34 |
| Keybuk | ... | 09:34 |
| Keybuk | simple--orig--1.0 is a branch of simple--UPSTREAM-RELEASE--1.0 | 09:34 |
| Keybuk | we merge the changes from simple--orig--0.9 | 09:34 |
| Keybuk | we sync-tree with simple's upstream CVS at the point we found it | 09:35 |
| Keybuk | and then we update the branch to include the changes | 09:35 |
| Keybuk | - | 09:35 |
| Keybuk | so we can extend this to arbitrarily complicated structures | 09:36 |
| Keybuk | and it means that there is an incredibly short path between any patch | 09:36 |
| Keybuk | you can calculate ancestry in just one or two steps, rather than a zillion | 09:36 |
| === robitaille [n=robitail@p235-083.public.uvic.ca] has joined #launchpad | ||
| Keybuk | so where there's a CVS upstream, you can just merge from it without having to worry about complicated layers in between | 09:37 |
| niemeyer | Right.. that's nice. A "patch provider" | 09:37 |
| niemeyer | Ok.. what about conflicts? | 09:37 |
| Keybuk | what conflicts? | 09:37 |
| Keybuk | you've got what it's supposed to look like in front of you | 09:37 |
| Keybuk | you have the tarball and patch you're trying to import | 09:38 |
| niemeyer | Ok.. let me try to explain | 09:38 |
| Keybuk | so you can just go "la la la la" and ignore them all | 09:38 |
| niemeyer | We have simple--orig--1.0--patch-X available, and also simple--patch-name--1.0--patch-Y | 09:39 |
| Keybuk | hmm, available how? | 09:39 |
| niemeyer | Imported | 09:39 |
| Keybuk | it's easier to refer to this in terms of the bundled version | 09:39 |
| niemeyer | And we've found a tarball for 2.0 to import. | 09:39 |
| Keybuk | right | 09:40 |
| Keybuk | do you mean an upstream tarball? | 09:40 |
| niemeyer | Creating simple--orig--2.0--base-0, a branch of --patch-X. | 09:40 |
| Keybuk | or a new 2.0 source package | 09:40 |
| niemeyer | A 2.0 source package, for instance. | 09:40 |
| Keybuk | ok | 09:41 |
| Keybuk | so yes, we have simple--orig--2.0--base-0 from simple--orig--1.0--patch-X | 09:41 |
| Keybuk | and simple--orig--2.0--patch-1 with the content of it | 09:41 |
| Keybuk | ... no conflict so far ? | 09:42 |
| niemeyer | Now, we have a patch between simple--orig--1.0--patch-X and patch-name--1.0--patch-Y that we want to apply to patch-name--2.0--base-0, right? | 09:42 |
| Keybuk | right, assuming that patch-name is in the 2.0 package | 09:42 |
| Keybuk | we make a simple--patch-name--2.0-base-0 from simple--orig--2.0--patch-1 | 09:42 |
| Keybuk | and then try and apply the delta to that | 09:43 |
| niemeyer | Right.. but the changes might conflict with the new patch, right? | 09:43 |
| Keybuk | correct | 09:44 |
| Keybuk | however on disk you have a directory in which you unpacked simple_2.0.orig.tar.gz and applied simple-patch-name.patch | 09:44 |
| Keybuk | so you know what the /result/ is supposed to look like | 09:44 |
| Keybuk | baz goes "argh!! conflicts!!", we just ignore them and commit it anyway | 09:44 |
| Keybuk | the worst that can happen is you just commit the useful patch logs | 09:45 |
| niemeyer | Ah, that's where I'd like to get. | 09:45 |
| Keybuk | and then the next thing you do is make that branch look exactly like the unpacked copy on disk, and commit that | 09:45 |
| niemeyer | Hummm.. that's strange. | 09:45 |
| Keybuk | there's absolutely no reason that operation needs to be a merge, it could just be a sync-tree, but I like it to be a merge because it often works out quite nicely | 09:46 |
| bradb | kiko: will you have a chance to review that patch today? | 09:46 |
| kiko | I might | 09:46 |
| kiko | right now I have a fucked tree | 09:46 |
| bradb | hehhe.adskj;a | 09:47 |
| niemeyer | Keybuk: Another example, just to clarify it in my mind. Suppose I'm a user, and I have a upstream source tarball of simple-2.0 in my hands, and want to upgrade what is currently being managed by hct. | 09:47 |
| niemeyer | hct has 1.0 | 09:48 |
| niemeyer | And patches for it | 09:48 |
| niemeyer | (like you've shown) | 09:48 |
| Keybuk | right | 09:48 |
| Keybuk | this gets a little more interesting, but once you know the basic operations, it comes out quite sweet | 09:48 |
| Keybuk | so let's imagine we imported simple-1.0 like this: | 09:48 |
| Keybuk | simple-1.0.tar.gz | 09:48 |
| niemeyer | What would be the procedure, first, considering that patches do not conflict, and then considering that they conflict with the differences of 1.0 -> 2.0. | 09:48 |
| Keybuk | + simple_1.0.orig.tar.gz | 09:48 |
| Keybuk | + simple_1.0.patch | 09:49 |
| Keybuk | in other words, the source package's orig.tar.gz was a branch off the upstream tar.gz | 09:49 |
| niemeyer | Ack | 09:49 |
| Keybuk | we feed the new /upstream/ tarball into the imported | 09:49 |
| Keybuk | we get simple--release--2.0--base-0, a continuation of simple--release--1.0--base-0 | 09:49 |
| Keybuk | and simple--release--2.0--patch-1, which has the actual changes | 09:50 |
| Keybuk | so delta(simple--release--1.0--base-0, simple--release--2.0--patch-1) is the actual changes from 1.0 to 2.0 | 09:50 |
| Keybuk | that's all we do! | 09:50 |
| Keybuk | we were only given an upstream job, so that's all that happens | 09:50 |
| Keybuk | we drop a manifest against the Simple 2.0 ProductRelease record | 09:50 |
| Keybuk | now | 09:50 |
| Keybuk | CONTEXT SWITCH | 09:50 |
| Keybuk | the user, or an automated process that's part of Grumpy Groundhog comes along | 09:51 |
| Keybuk | they see that a new upstream version has been imported | 09:51 |
| Keybuk | and they do something like | 09:51 |
| Keybuk | $ hct pull products/simple/2.0 | 09:51 |
| Keybuk | (or the short-cut) | 09:51 |
| Keybuk | $ hct pull upstream | 09:51 |
| Keybuk | this uses the same code (hct.model and hct.naming, btw) to process the merge | 09:52 |
| Keybuk | it creates a new simple--orig--2.0-base-0 as a tag from simple--release--2.0-patch-1 | 09:52 |
| Keybuk | merges the delta of the previous orig branch (which might be removing non-free docs, for example) onto it and creates a simple--release--2.0--patch-2 | 09:53 |
| Keybuk | THAT MIGHT CONFLICT | 09:53 |
| Keybuk | but that's ok, we have a user sitting in front of ut | 09:53 |
| Keybuk | we leave them a directory with the conflicts in and go "oi! resolve this" | 09:53 |
| Keybuk | (grumpy reports via e-mail that there were conflicts that need fixing) | 09:53 |
| Keybuk | we carry on | 09:53 |
| niemeyer | Ok | 09:53 |
| niemeyer | Understood | 09:53 |
| Keybuk | we make a new simple--patch-name--base-0 from simple--release--2.0--patch-2 | 09:53 |
| Keybuk | we take the previous delta and make simple--patch-name--patch-1 | 09:54 |
| Keybuk | which also might conflict | 09:54 |
| Keybuk | but again, there's a user sat in front of us who can resolve that | 09:54 |
| Keybuk | and the best bit about this is that because we know we just asked the user to resolve a conflict, we can label that changeset specially Launchpad | 09:55 |
| Keybuk | and the next time someone gets that conflict (because they try the same thing), we can just grab that changeset from the database and apply it | 09:55 |
| Keybuk | -- | 09:55 |
| niemeyer | Nice! | 09:56 |
| niemeyer | Thanks for the extensive explanation | 09:56 |
| Keybuk | so we can do neat tricks | 09:57 |
| Keybuk | grumpy can once a day try to apply new upstream changes to every source package | 09:57 |
| Keybuk | and when it breaks report via e-mail | 09:57 |
| Keybuk | all the user has to do is try and do the same operation, fix the conflict and commit it | 09:57 |
| Keybuk | (to _their_ archive) | 09:57 |
| Keybuk | and grumpy (and every other user doing the same operation) would automatically pick it up | 09:58 |
| Keybuk | so we can use it as an early-warning-system for patch failures | 09:58 |
| Keybuk | -- | 09:58 |
| Keybuk | where a couple of people (hi, Mark!) get confused is where the commits go | 09:58 |
| Keybuk | the branches we've been talking about so far have all been sacred to sourcerer | 09:59 |
| Keybuk | users _don't_ commit to those branches | 09:59 |
| Keybuk | so let's say I get my simple source package again | 09:59 |
| niemeyer | Keybuk: Ah, yes, that's something I missed/overlooked on your mail. You mention that the patch will automatically be available to other on the next day, but how does it get there (in the public archive)? | 09:59 |
| Keybuk | "hct source simple" does a baz get on: | 09:59 |
| Keybuk | simple@bazaar.ubuntu.com--ubuntu/simple--orig--1.0 | 10:00 |
| Keybuk | simple@bazaar.ubuntu.com--ubuntu/simple--patch-name--1.0 | 10:00 |
| Keybuk | and that's what I have in my working tree | 10:00 |
| Keybuk | now when I type "hct commit" (which isn't in the dailies, but is on my disk and going in tomorrow) we can't commit to those branches, so we make a copy of them in the user's archive | 10:00 |
| Keybuk | so it uses the same model code (hct.model gets lots of exercise) | 10:01 |
| Keybuk | and the user ends up with | 10:01 |
| Keybuk | scott@netsplit.com/simple--orig--1.0 | 10:01 |
| Keybuk | scott@netsplit.com/simple--patch-name--1.0 | 10:01 |
| Keybuk | in their own archive, and the commit completes | 10:01 |
| Keybuk | so now any operation they do is local to them | 10:01 |
| Keybuk | and doesn't collide with anything sourcerer (or any other process) is trying to do | 10:01 |
| niemeyer | Right.. but what I'm a bit confused about is that you say: | 10:02 |
| niemeyer | """ | 10:02 |
| niemeyer | Ok, so you made some changes to it; what happens tomorrow when someone | 10:02 |
| niemeyer | else comes along and needs to make more changes? | 10:02 |
| niemeyer | """ | 10:02 |
| niemeyer | :o) => Getting dbus-0.36.2/debian/patches/dbus-some-bug-got-fixed.patch | 10:02 |
| Keybuk | in the long term (read HctDevelopmentCycle on the wiki) when you release your source, it'll be dropping a manifest referring to _your_ branches in the database | 10:02 |
| niemeyer | So it means it's on a common/shared/public/whatever archive | 10:03 |
| Keybuk | ah | 10:03 |
| Keybuk | right | 10:03 |
| Keybuk | so there's no "hct commit" command in the released version of hct | 10:03 |
| Keybuk | we're not testing that right now, we're testing the basic work-flow | 10:05 |
| Keybuk | the uploads happen by using "hct assemble" and then just uploading it into the existing ftp queue | 10:05 |
| Keybuk | so sourcerer notices the upload, and imports it | 10:05 |
| Keybuk | so it does a fresh import of the source package and the patch appears because it was found in the source package | 10:06 |
| Keybuk | sadly it's unrelated to the patch branch that exists on the original user's drive | 10:06 |
| Keybuk | but they probably won't notice <g> | 10:06 |
| Keybuk | this is a short-term hack to get distro team buy-in now, and figure out what problems they'll have with the work-flow, before we take away the existing stuff | 10:06 |
| niemeyer | $ dupload *.changes | 10:07 |
| niemeyer | This will upload the patch itself? | 10:07 |
| Keybuk | yeah, dupload is a Debian tool | 10:07 |
| niemeyer | Which will later be imported? | 10:07 |
| Keybuk | those last bits are "existing things the distro team use already" | 10:07 |
| Keybuk | it's supposed to feel comfortable to them | 10:07 |
| niemeyer | Understood | 10:07 |
| Keybuk | and it just gets imported again | 10:07 |
| niemeyer | Now it all makes sense | 10:07 |
| Keybuk | we refer to that as "laundering" | 10:07 |
| Keybuk | you loose the cash you had in your pocket, but at least you can wear the jeans again | 10:08 |
| Keybuk | in the _long_ term, they wouldn't upload it with the old tool -- they'd issue something like "hct release" which would do the magic inside launchpad to make it happen | 10:08 |
| Keybuk | HctDistroGratification (lp wiki) is what we're giving them today | 10:08 |
| Keybuk | HctDevelopmentCycle (lp wiki) is where we're going | 10:09 |
| === niemeyer checks | ||
| niemeyer | Keybuk: What about the --diff-- branches? | 10:13 |
| niemeyer | which are used as the patch-base | 10:13 |
| Keybuk | those are just second-level patch branches | 10:15 |
| Keybuk | simple--orig--1.0 | 10:15 |
| Keybuk | + simple--diff--1.0 | 10:15 |
| Keybuk | + simple--patch-name--1.0 | 10:15 |
| Keybuk | so orig changes get applied to diff, diff changes to patch-name | 10:15 |
| Keybuk | no different than patch-of-a-patch | 10:15 |
| niemeyer | Is orig ever changed? | 10:16 |
| niemeyer | Or just works as the parent of orig--N+1? | 10:17 |
| kiko | hmmm | 10:21 |
| kiko | what test is it that stuart always tells me to use | 10:21 |
| niemeyer | """ | 10:21 |
| niemeyer | The libtool package in Debian has a large monolithic diff branch, which is the logical patch base. However in Ubuntu, the package has been cleaned up and moved to a new source package format; in there, the original source is the logical patch base. | 10:21 |
| niemeyer | """ | 10:21 |
| niemeyer | That should explain part of the idea | 10:21 |
| kiko | which lists pages to check? | 10:23 |
| niemeyer | Keybuk: Thanks again. I now have food for further investigation, and won't bother you for another while. ;) | 10:23 |
| === niemeyer must leave now, though.. | ||
| niemeyer | See you guys | 10:25 |
| Keybuk | orig can be changed | 10:26 |
| Keybuk | oh, bah, he went | 10:26 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] adding a script that allows you to link your sourcecode and lib to directories hanging off another tree (patch-2360: christian.reis@canonical.com) | 10:30 |
| === kiko does TDD | ||
| === dand [n=dand@83.103.205.67] has joined #launchpad | ||
| === Alinux [n=Ubuntu@p54A38043.dip0.t-ipconnect.de] has joined #launchpad | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] When displaying a raw traceback, the errorservice forgot to check if the entry was expired. Fixed. (patch-2361: christian.reis@canonical.com) | 11:41 |
| === jbailey [n=jbailey@testhaus.cns.utoronto.ca] has joined #launchpad | ||
| jbailey | Hmm, I merged accouns and my karma didn't get transfered. Is that a bug? | 11:53 |
| jbailey | Hmm, and it also seems to still list my old account "jbailey-ubuntu" as member of the Ubuntu Core Team rather than "jbailey" | 11:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!