| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: fixed regression malone bugs; vastly simplified event handling in the process with multi-subscription adapters. no, seriously. (patch-659) | 12:28 | |
| (spiv/#launchpad) Woah, multi-subscription adapters. | 12:28 | |
| (spiv/#launchpad) I'm glad that they're actually useful :) | 12:29 | |
| BradB | yep, i just cut out a good 100 lines of code by using them | 12:31 |
|---|---|---|
| BradB | and a package | 12:31 |
| BradB | jblack: you can hammer my machine for a little while now, if you want | 12:34 |
| === BradB is now known as BradB|food | ||
| jblack | bradb: Thanks | 12:38 |
| jblack | I HATE OS X | 12:51 |
| ddaa | jblack: I suggest you mail Apple a request to assign copyright to the FSF :-P | 12:52 |
| jblack | No. | 12:52 |
| ddaa | How is the profiling going? | 12:53 |
| jblack | I'd rather the os, the code, the developers, and everything else associated get buried in some unmarked mass grave in the middle of death valley | 12:53 |
| jblack | still trying to compile tla. | 12:53 |
| ddaa | Frankly macos is the only os around with a half decent user experience... | 12:56 |
| ddaa | Too bat it's non-free. | 12:56 |
| ddaa | jblack: getting anywhere? | 12:56 |
| ddaa | Last time I tried to compile something my hand on osx (w/o using fink) I just hit a wall of mystery. But limi told me the situation has improved. | 12:56 |
| jblack | Thought I was, but I'm stuck here: cc: Internal error: Bus error (program /usr/libexec/gcc/darwin/ppc/cpp-precomp) | 12:56 |
| ddaa | Mh... there should be an option to disable precompiled headers somewhere. | 12:57 |
| ddaa | That's a funky new features they | 12:57 |
| jblack | is that what it is? | 12:58 |
| ddaa | paid for, and which dramatically cut their build time, but it obviously was not well tested enough. | 12:58 |
| ddaa | "cpp-precomp" really sounds something like that has something to do with precompiled headers. | 12:58 |
| jblack | -no-cpp-precomp (APPLE ONLY) | 12:59 |
| === ddaa is just of out a class yoda-talk | ||
| jblack | lets try that with CFLAGS | 12:59 |
| jblack | I think you're right | 12:59 |
| === jblack hugs ddaa | ||
| jblack | ddaa: I don't even need to profile this. | 01:07 |
| jblack | badb's machine is taking about 3 seconds per unit-pow2-array tests | 01:07 |
| ddaa | meaning? | 01:07 |
| jblack | meaning its a really slow, slow machine | 01:07 |
| ddaa | What model is it? | 01:07 |
| jblack | how do I know? | 01:08 |
| ddaa | MacOS X machines do not tend to be slow slow... | 01:08 |
| ddaa | Ask him... | 01:08 |
| ddaa | BradB|food: what model is your macintosh? | 01:08 |
| jblack | let me put it this way. Make test has been running 5 minutes, and its still going | 01:09 |
| ddaa | Okay, started make test here, on my machine where tla performs reasonably well... | 01:11 |
| jblack | total wallclock exceeded 6 min | 01:13 |
| jblack | and make test didn't even pass | 01:13 |
| ddaa | ho, has tla mv been fixed to behave more like regular mv in 1.2.2rc2? | 01:14 |
| jblack | not that I remember | 01:15 |
| ddaa | Wall clock time here 3m50, that does not account for 1hour star-merges. | 01:15 |
| jblack | wow. Takes me less than a minute | 01:16 |
| ddaa | I saw the mv test cases, so I was a bit surprised. | 01:16 |
| ddaa | my machine is a PIII 660 MHz... not exactly today's top of the line. | 01:16 |
| ddaa | But quite top of the line when I bought it, five years ago. | 01:16 |
| jblack | First, I'm going to profile library-add rf/lp--d--0--patch-599 | 01:16 |
| === debonzi goes for dinner | ||
| === debonzi [~debonzi@200.158.100.251] has left #launchpad ["Leaving"] | ||
| === elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| BradB|food | ddaa: the machine isn't slow, the filesystem is | 01:19 |
| jblack | hi elmo, how are you? | 01:19 |
| BradB|food | ddaa: it's a pb g4, the second most recent 15" | 01:19 |
| jblack | bradb: Your processor is certainly slow. pow2 tests on my machine take about 1/2 a second each. on yours, about 3 seconds each. | 01:19 |
| ddaa | BradB|food: duh and what ram do you have? 256M or something? | 01:19 |
| ddaa | jblack: it's maybe just that gcc sucks. | 01:20 |
| BradB|food | only 256M, unfortunately | 01:20 |
| ddaa | BradB|food: what cpu freq. | 01:20 |
| BradB|food | 867 MHz | 01:21 |
| ddaa | Laptops have slow disks, having a ton of ram us essential for decent performance. | 01:21 |
| ddaa | Bah, I'm pretty convinced that the pb is the fs. But what exactly? | 01:21 |
| BradB|food | does ext3 do zero-filling? | 01:22 |
| jblack | I doubt it | 01:22 |
| BradB|food | hfs+ does; apple says that tends to be a bottleneck | 01:22 |
| ddaa | Like, we might find out that on warm cache stat() is one order of magnitude slower than on reiserfs. | 01:22 |
| ddaa | What's zero-filling? | 01:23 |
| BradB|food | ddaa: writing zeros on the unused part of a disk allocated to a given file | 01:23 |
| ddaa | ??? you mean a part of the disk allocated to the file which is not actually used by the file? | 01:24 |
| BradB|food | yes | 01:24 |
| ddaa | What purpose could that serve??? | 01:24 |
| BradB|food | security, of course | 01:24 |
| ddaa | Come on... | 01:24 |
| ddaa | Unused disk space is unused. It's security neutral. | 01:25 |
| === ddaa switches | ||
| ddaa | I do not see how that improves security, can you teach me? | 01:26 |
| sabdfl | guys, we have a bunch of bad commits | 01:31 |
| sabdfl | def ProductBugAssignmentFactory(context, **kw): | 01:31 |
| sabdfl | - pba = ProductBugAssignment(bug=context.context.bug, **kw) | 01:31 |
| sabdfl | - product_assigned = BugAssignedProductAddedEvent( | 01:31 |
| sabdfl | - Bug.get(context.context.bug), pba) | 01:31 |
| sabdfl | - notify(product_assigned) | 01:31 |
| sabdfl | - return pba | 01:31 |
| sabdfl | + return ProductBugAssignment(bug=context.context.bug, **kw) | 01:31 |
| sabdfl | this was code that i merged into the file this afternoon | 01:33 |
| BradB|food | sabdfl: dude, those are good commits. :) | 01:33 |
| BradB|food | major simplifications. | 01:33 |
| BradB|food | i undid what i did, because i found a much simpler way to do what i was trying to do with events. | 01:33 |
| sabdfl | BradB|food: dude, i spent two hours merging your first round of changes | 01:33 |
| sabdfl | :-/ | 01:34 |
| BradB|food | ouch. :/ | 01:34 |
| BradB|food | well, the good news is that i cut out a good 100 lines of code and a package. | 01:34 |
| BradB|food | i didn't know about "multi-subscription adapters" until jim told me :) | 01:34 |
| sabdfl | so we both spent hours undoing one another's work :-) | 01:34 |
| ddaa | <troll>Maybe that's an argument against vcs tools which encourage too much concurrency, we need worse tool to prevent people from stepping on each others toes</troll> | 01:35 |
| BradB|food | sabdfl: emmm, kind of, but you moved things around. i undid my work. | 01:35 |
| sabdfl | no worries | 01:36 |
| sabdfl | i'm relieved it wasn't a tla issue :-) | 01:36 |
| sabdfl | at least the system works | 01:36 |
| BradB|food | nope, it's all good. and simplified. | 01:36 |
| sabdfl | can you teach me about multi-subscription adapters? | 01:38 |
| BradB|food | sure, to the extent that i understand them. :) | 01:38 |
| BradB|food | so, basically, the problem to be solved was: "how do i send an email when foo is added to a bug?" | 01:38 |
| BradB|food | the answer was: events. | 01:38 |
| BradB|food | the next question became: how do i fire off an event when a foo is added to a bug? | 01:39 |
| BradB|food | my first answer was to create an IFooAddedEvent | 01:39 |
| BradB|food | then manually go into the FooFactory, and call notify(some_event_obj) | 01:39 |
| BradB|food | which was an instance of an IFooAddedEvent | 01:39 |
| BradB|food | then have my handler, a simple python func, send of an email to CC'd people saying that a foo was added, providing the relevant details. | 01:40 |
| BradB|food | at first, this seems pretty interesting. | 01:40 |
| BradB|food | but then you realize, crap, there's about 7-8 things that can be added to a bug. :/ | 01:40 |
| BradB|food | this turns into a lot of code, zcml, and tediousness. every time you want to support sending a notification on something being added to a bug, you have to: | 01:41 |
| BradB|food | 1. add and IFooAddedEvent. | 01:41 |
| BradB|food | 2. Create a FooAddedEvent. | 01:41 |
| sabdfl | ok | 01:41 |
| BradB|food | 3. Modify the factory to create a FooAddedEvent and notify() | 01:41 |
| BradB|food | 4. write the handler | 01:41 |
| BradB|food | 5. configure the ZCML | 01:42 |
| BradB|food | so, scrap that...multi-subscription adapters! | 01:42 |
| BradB|food | when an object is added, z3 fires of an ObjectCreatedEvent | 01:42 |
| BradB|food | so, forget added all those special event interfaces and classes, you can now do something like this in ZCML: | 01:42 |
| sabdfl | z3? even if the object is an sqlobject? | 01:43 |
| BradB|food | yes, it doesn't matter | 01:43 |
| BradB|food | storage is an implementation detail | 01:43 |
| BradB|food | here's the ZCML magic: | 01:44 |
| BradB|food | <subscriber | 01:44 |
| BradB|food | for="canonical.launchpad.interfaces.IBugProductInfestation | 01:44 |
| BradB|food | zope.app.event.interfaces.IObjectCreatedEvent" | 01:44 |
| BradB|food | factory="canonical.launchpad.mailnotification.notify_bug_product_infestation_added" /> | 01:44 |
| BradB|food | this says, "for an IObjectCreatedEvent that happened on an IBugProductInfestation, call notify_bug_product_infestation_added" | 01:44 |
| BradB|food | so, cool, no more having to create a special event called "IBugProductInfestationAdded" | 01:45 |
| BradB|food | notify_bug_product_infestation_added is just a simple python func that sends an email. it gets called like notify_bug_product_infestation_added(product_infested, event) | 01:46 |
| sabdfl | how does zope know to pass a product to notify_bug_product_infestation_added | 01:48 |
| BradB|food | the for attribute in that config is the "multi-subscription adapter", because it's subscribing not just to the IObjectCreatedEvent, but the IObjectCreatedEvent for an IBugProductInfestation. | 01:48 |
| BradB|food | well, it passes an bugproductinfestation | 01:49 |
| BradB|food | s/an/a/ | 01:49 |
| sabdfl | ok | 01:49 |
| sabdfl | and that knows it's product | 01:49 |
| sabdfl | gotcha | 01:49 |
| BradB|food | yep | 01:50 |
| ddaa | BradB|food: about explicit tag | 01:50 |
| ddaa | you should now that they currently make tla actually run more slowly :-) | 01:50 |
| BradB|food | sabdfl: so when i found this out, i was able to delete the whole events package i had created :) | 01:50 |
| === limi [~limi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| === BradB|food is now known as BradB | ||
| ddaa | BradB|food: which i undertand is a major concern for you. | 01:51 |
| BradB | ddaa: They're our policy. | 01:51 |
| BradB | But that isn't the bottleneck. :) | 01:51 |
| === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad | ||
| BradB | sabdfl: haven't quite figured out how i'll figure out what changed on edits though. | 01:52 |
| sabdfl | ddaa: the alternative is to make the launchpad team run much more slowly :-) | 01:52 |
| ddaa | sabdfl: yeah... ideally tla | 01:53 |
| ddaa | rm and tla mv would be sane. | 01:53 |
| ddaa | But unfortunately that is not an ideal world. | 01:53 |
| sabdfl | sane? i think they work just fine | 01:53 |
| ddaa | "tla mv foo bar baz/" works | 01:54 |
| sabdfl | i dn't think is't sensible to advocate mixing tht revision control system semantics into the actual files | 01:54 |
| ddaa | if you push explicit tags, people will have to use tla mv/rm anyway. | 01:54 |
| sabdfl | for example, we are currently serving up HTML that includes arch tags in it | 01:54 |
| sabdfl | that's not sane | 01:54 |
| ddaa | So, if they "work just fine" they can handle mixed tagline/explict, and there is not point in using explicit tags. | 01:55 |
| ddaa | I mean, explicit tags as a policy. | 01:55 |
| ddaa | It is sure not sane to serve arch-tag in html pages. | 01:55 |
| BradB | jblack: you're gonna start a fire in my apt, i think. :P | 01:55 |
| ddaa | sabdfl: the only reason I understand behind that policy is that tla rm/mv would be too broken to handle tagline files transparently. | 01:57 |
| limi | BradB: he's bouncing on your poor PB? ;) | 01:57 |
| BradB | bigtime! | 01:57 |
| limi | BradB: what model is it? | 01:57 |
| BradB | pb g4, second most recent 15" | 01:58 |
| sabdfl | ddaa: there's more to it than that | 01:58 |
| ddaa | I'm sure there is. | 01:58 |
| jblack | bradb: how so? | 02:17 |
| jblack | All I did was library-add rocketfuel@canonical.com/launchpad--devel--0--patch-599 | 02:17 |
| jblack | It's up to 93, so its got about 5 hours to go. | 02:18 |
| BradB | owwwhohowwwewwwch | 02:22 |
| ddaa | jblack: I believe | 02:23 |
| ddaa | BradB got burnt... | 02:23 |
| BradB | :P my fan is going non-stop | 02:23 |
| jblack | bradb: I really don't see how you can call this a nice machine. :) | 02:24 |
| BradB | did i call it a nice machine? | 02:24 |
| BradB | it's arse | 02:24 |
| BradB | i'm trying to not hate though | 02:24 |
| jblack | want me to call it quits? | 02:25 |
| stub | jblack: Let me know if you need some tests run on a gruntier OSX box - I can probably get access to one at old work (but I won't be able to give access from the internet) | 02:26 |
| BradB | it's up to you. :) there's clearly a lot to improve about tla/arch on os x, but i'm not one to belabour the point. i gave up long ago on it being sane to use on os x. | 02:27 |
| limi | BradB: have you tried UFS? | 02:27 |
| BradB | no, but i've thought about it | 02:27 |
| === limi suspects HFS+ is really crappy | ||
| BradB | yeah, we know that HFS+ sucks :) | 02:27 |
| limi | BradB: want a repartitioning tool? | 02:27 |
| limi | so you can test it? | 02:27 |
| limi | it works really well | 02:27 |
| BradB | limi: i had that at mark's too :) didn't bother using it. | 02:27 |
| limi | I used it to make space for Ubuntu | 02:28 |
| jblack | strub: Nah. Its the nongruntiness I was interested in. | 02:28 |
| limi | super simple | 02:28 |
| BradB | i've only got one machine right now; if this thing dies, i'm taking my life with it. | 02:28 |
| limi | iSync ;) | 02:28 |
| BradB | iPod mini! | 02:28 |
| BradB | i've got a backup, but ach, i dunno | 02:28 |
| limi | or that ;) | 02:28 |
| limi | BradB: it's pretty much foolproof | 02:28 |
| jblack | bradb: Actually, as I've chased this down, the ghost has evaporated. | 02:29 |
| BradB | limi: famous last words! | 02:29 |
| limi | I can hold your hand over the phone if you want ;) | 02:29 |
| BradB | i'm not worried about how to use it :) | 02:29 |
| BradB | i'm worried about murphy's law | 02:29 |
| limi | I understand | 02:29 |
| limi | I'm in the same situation | 02:29 |
| limi | but decided "fuck it, all the important stuff is backed up or in an SVN repo anyway" | 02:30 |
| stub | BradB: An option might be an external firewire drive (which can double as backup for your life^h^h^h^hosx disk | 02:30 |
| BradB | stub: Yep, I already have an iPod mini | 02:30 |
| === limi has that too, but the 250GB of mp3 occupies that ;) | ||
| stub | BradB: I meant installing Ubuntu on the external drive (heck... you might be able to get it to boot of the iPod for that matter.... but it might not play music any more ;) ) | 02:31 |
| limi | the Mac can boot from iPod, yes | 02:31 |
| BradB | stub: heh, that'd be cool | 02:31 |
| stub | iBuntu :-) | 02:31 |
| limi | it's pretty nice when you're used to the moronic PC architecture | 02:31 |
| BradB | hah! | 02:32 |
| stub | So.... all these events creating emails and whatnot... is this going to cause havoc with writing unit tests? | 02:37 |
| BradB | with the functional tests, it's to be expected in a way. | 02:40 |
| stub | Hmm... the email spoolie thing is good, as tests can check for new files and examine them. I had to implement that myself in Z2 :-) | 02:40 |
| === stub goes and reads the page test docs | ||
| BradB | i'm not using z3's mail machinery right now | 02:40 |
| BradB | i wrote a little module to be the standard way to send email in LP. canonical.launchpad.mail | 02:41 |
| === ddaa [~ddaa@nemesis.xlii.org] has left #launchpad [] | ||
| === BradB is now known as BradB|away | ||
| sabdfl | lifeless: up? | 03:19 |
| jblack | I haven't seen him yet. | 03:32 |
| stub | SteveA: Ping | 04:38 |
| === cprov [~cprov@200-171-77-185.dsl.telesp.net.br] has joined #launchpad | ||
| stub | BradB|away: I'm working on the Z3 transactional email now | 04:55 |
| lifeless | host lifeless-38.ip6.progsoc.uts.edu.au | 06:17 |
| lifeless | bah | 06:17 |
| jblack | Hey lifeless! | 06:49 |
| jblack | Having fun tonighbt? | 06:49 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Replace stub implementation in mail.py, now using transactional goodness (patch-660) | 06:50 | |
| (dilys/#launchpad) New bug 2127 for Launchpad/Launchpad: Simple configuration information | 07:02 | |
| (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2127 | 07:02 | |
| === mdz_ [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad | ||
| === justdave [~dave@24.247.63.44.gha.mi.chartermi.net] has joined #launchpad | ||
| stub | Morning Dave. I fixed up some bits and pieces in checkwatches.py yesterday, and plugged it into the main test runner so people now if they break it again. | 08:58 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: Mail stuff including stub implementation for development (patch-661) | 09:45 | |
| === dda1 [~ddaa@nemesis.xlii.org] has joined #launchpad | ||
| === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad | ||
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| SteveA | stub: ping | 10:47 |
| SteveA | stub: pong | 10:47 |
| stub | I forget | 10:48 |
| SteveA | Are the set of Person.ids of canonical staff the same in the production database as in the sample data we use while developing launchpad? | 11:04 |
| === SteveA pings stub to see if he knows | ||
| stub | I doubt it | 11:14 |
| stub | And anything that relies on hardcoded id's is broken | 11:14 |
| SteveA | stub: see email to mark that I cc-ed you into just now. | 11:19 |
| stub | SteveA: Any idea which ftesting.zcml is being used? I've stuck deliberate syntax errors into it and nothing complains :-( | 11:34 |
| SteveA | oh | 11:34 |
| SteveA | shite | 11:34 |
| SteveA | that's next on my "make tests better" list then | 11:34 |
| stub | I suspect that is why a lot of the tests are failing (unable to locate 'Utilities') | 11:35 |
| SteveA | which tests? | 11:37 |
| sabdfl | morning all | 11:40 |
| sabdfl | yesterday i needed to tweak ftesting.zcml in the top directory to get page tests to work | 11:40 |
| sabdfl | it was including an sql.zcml file from malone or doap that i'd eliminated | 11:41 |
| sabdfl | stub, maybe that's the cause / solution to your test problem | 11:41 |
| sabdfl | lifeless: any news on x.org in arch? | 11:46 |
| sabdfl | and xfree86 too? | 11:46 |
| stub | sabdfl: Were you getting an error message before you removed the offending line? | 11:48 |
| stub | SteveA: Don't worry - I think I know what I was doing wrong | 11:49 |
| sabdfl | stub: yes | 11:50 |
| sabdfl | i reduced the sql.py to nothing and then removed it from it's local configure.zcml and deleted the file | 11:50 |
| sabdfl | then the tests all failed, when they had run before when it had nothing in it | 11:50 |
| sabdfl | turns out the sql.py was being included from ftesting.zcml which was only being used in the tests | 11:51 |
| sabdfl | so it would run fine, just not test fine | 11:51 |
| sabdfl | editing ftesting and removing the import of that sql.zcml fixed it | 11:51 |
| stub | SteveA: Is there a way to use a Unittest test harness like FunctionalTestCase with doctests? | 11:53 |
| SteveA | stub: yes, there is. I'd need to look it up, though. There are examples in the zope3 source tree, for the .txt doctests. | 11:56 |
| stub | zope/app/tests/test_functional.py | 11:59 |
| sabdfl | SteveA: any update on the moin / zwiki, and zwiki / preview status? | 12:03 |
| SteveA | preview is in the latest zwiki | 12:05 |
| SteveA | moin without tables is in the latest zwiki. Simon Michael hasn't done the tables work yet. I've extended the bounty until Monday, but I don't think he'll do it, as he was asking questions about a larger bounty for it to be done quickly. | 12:07 |
| SteveA | I've been asking around to see if someone else wants to do the tables work. It occured to me that lalo might want to do it... | 12:07 |
| SteveA | although getting him money is a pita | 12:08 |
| === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad | ||
| === BradB|away is now known as BradB | ||
| === elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| SteveA | morning brad | 12:28 |
| BradB | hi | 12:28 |
| SteveA | roche's pointers on doing cacheing look pretty straightforward. what do you think? | 12:29 |
| lulu | BradB: Morning! just spoke to Thom - he can do the first one, but needs you to help on 2&3 if you could, Brad. | 12:30 |
| BradB | SteveA, lulu: I'm not sure if that solution solves the full-page caching issues. (e.g. Apache caches /foo, accessed by an anon user, then I go to access /foo and get a cache hit, and it makes it look like i'm not logged in.) | 12:37 |
| BradB | SteveA: I don't understand how uncommenting that line of Python is of any use either, because it's setting Last-Modified to time.time(). | 12:38 |
| === BradB takes a look at the code for context | ||
| BradB | oh yeah, that makes more sense; still not sure about the full page caching problem though. | 12:44 |
| SteveA | the main thing I'm concerned about is cacheing pages when someone is logged in | 12:49 |
| BradB | caching not-logged-in pages is just as much of a problem though | 12:50 |
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| BradB | because it gives the impression that "the plone site just logged me out" :) | 12:50 |
| sabdfl | SteveA: w.r.t. moin in zwiki | 12:50 |
| sabdfl | moin tables suck | 12:50 |
| BradB | and prevents one from doing editing | 12:50 |
| sabdfl | zwiki already supports html reStructuredText and StructuredText | 12:50 |
| carlos | morning | 12:51 |
| sabdfl | what are the tables like in ReST? | 12:51 |
| lifeless | sabdfl: not yet, will try that this tomorrow | 12:53 |
| lifeless | I have tarballs from daniels for it though | 12:53 |
| SteveA | sabdfl: http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables | 12:58 |
| SteveA | so, similar, but not quite so annoying | 12:58 |
| BradB | SteveA: lulu said you were verifying the CC patch; did you take the thing that you used to see the base64 hole and try it again on site-edit now that the patch is in? | 01:07 |
| SteveA | will do so shortly | 01:08 |
| Kinnison | Python idiom question... I have a dict of dicts. I want to to create entries in the first dict when I encounter them in the input data. In lua I'd do something like: foo[key] = foo[key] or {} | 01:10 |
| Kinnison | What's the python idiom? | 01:10 |
| Kinnison | is it just: | 01:12 |
| Kinnison | if key not in foo: foo[key] = {} | 01:12 |
| Kinnison | ? | 01:12 |
| elmo_ | .setdefault | 01:12 |
| Kinnison | that'd give the same dict to each new key wouldn't it? | 01:13 |
| SteveA | Please please never use the boolean short-circuit stuff as a short-cut for an "if" statement. | 01:15 |
| Kinnison | SteveA: okay. It's a common Lua idiom you see :-) | 01:15 |
| SteveA | Lalo used loads of these in the rosetta code, and they are just so hard to read later. | 01:15 |
| Kinnison | SteveA: I will use the if statement | 01:15 |
| SteveA | thanks | 01:15 |
| SteveA | setdefault is probably the way to go, as elmo says | 01:15 |
| SteveA | it would give a new dict to each new key | 01:16 |
| Kinnison | >>> bar={} | 01:16 |
| Kinnison | >>> bar.setdefault({}) | 01:16 |
| Kinnison | TypeError: dict objects are unhashable | 01:16 |
| Kinnison | is that wrong? | 01:16 |
| SteveA | the only time you'll get the same dict is if the dict constructor (that is, {}) appears at the module level or as the default value of a function argument. | 01:16 |
| SteveA | you can't use a dict object as a key | 01:16 |
| SteveA | nor a list | 01:17 |
| SteveA | nor anything mutable | 01:17 |
| stub | bar.setdefault(key,{}) | 01:17 |
| SteveA | it must be hashable | 01:17 |
| Kinnison | oh, gotcha | 01:17 |
| Kinnison | stub: I see | 01:17 |
| === Kinnison thought it was dict.setdefault(defaultvalue) | ||
| SteveA | if you want to store a dict as a key, store tuple(mydict.items()) | 01:17 |
| Kinnison | and then dict[unknownkey] would autovivify | 01:17 |
| BradB | perler! | 01:17 |
| === Kinnison thanks you | ||
| Kinnison | If I have a value and a dbschema class which maps name->value; is there an easy way to get a name back out of the class? | 01:29 |
| Kinnison | E.g. is there FooSchema.nameOf(thisvalue) or something? | 01:29 |
| SteveA | stub: I've looked at the cookies. They're always the same, so open to a replay attack. | 01:31 |
| === limi [~limi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| stub | Yes - can't avoid that | 01:31 |
| SteveA | can't use the time as a salt, and reject too old cookies? | 01:31 |
| Kinnison | http://www.excessus.demon.co.uk/misc-hacks/#cookie | 01:32 |
| stub | If you want to reject old cookies, that would work. Or you could just encode the time in with the rest of the encrypted data. | 01:32 |
| Kinnison | I'm not suggesting you *use* mdw's cookie program; but it's a good place to crib ideas from | 01:33 |
| SteveA | still, it is better than plaintext. the worst an attacker can do is write crap all over the UL website. | 01:33 |
| SteveA | they can't easily get the password out to use against launchpad | 01:33 |
| SteveA | so, I'd be happy to go ahead and use what we have at the moment. | 01:34 |
| sabdfl | is there a password on this channel? | 01:34 |
| SteveA | but, it would be nice to put the time in there make only a small window for replays. | 01:34 |
| stub | nope | 01:34 |
| sabdfl | limi's not able to get in at the mo | 01:34 |
| SteveA | limi: ? | 01:34 |
| SteveA | --> limi (~limi@host217-37-231-28.in-addr.btopenworld.com) has joined #launchpad | 01:34 |
| SteveA | just above stub saying "yes - can't avoid that | 01:35 |
| SteveA | " | 01:35 |
| BradB | This would seem to merit an emergency upgrade to plone.org | 01:37 |
| BradB | (just confirmed that is has the bug, but that's not surprising) | 01:38 |
| SteveA | plone.org sends plaintext passwords in cookies? | 01:38 |
| BradB | base64 encoded u:p. | 01:38 |
| SteveA | wonder if zope.org does too | 01:38 |
| lifeless | well at least its not plaintext :) | 01:39 |
| SteveA | let's upgrade to rot13 | 01:39 |
| BradB | lifeless: heh, might as well be :P | 01:39 |
| === lifeless was trolling | ||
| BradB | yeah yeah, i know :P | 01:39 |
| stub | Hey - CookieCrumber has always worked like that. Its a feature :) | 01:39 |
| === BradB shreaks for having an account on plone.org | ||
| === lifeless and is tired | ||
| BradB | SteveA: yep, zope.org too. shit. | 01:42 |
| === limi [~limi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| SteveA | hello again limi | 01:43 |
| limi | Sir Alexander | 01:43 |
| limi | how's Lithuania? | 01:43 |
| SteveA | less cold | 01:44 |
| SteveA | less wet | 01:44 |
| SteveA | not so bad at the moment | 01:44 |
| limi | London also has strange weather | 01:45 |
| limi | sun and stuff ;) | 01:45 |
| BradB | SteveA: there's a meeting shortly, eh? | 01:47 |
| SteveA | yes | 01:49 |
| BradB | d29vaG9v | 01:52 |
| BradB | (that was "woohoo" in base64) | 01:52 |
| sabdfl | do we expose dbschema ENUM's to tal in a way that makes it easy to get the value, title and description? | 02:00 |
| BradB | meeting time? | 02:03 |
| SteveA | sabdfl: yes. bug/severity/lp:BugSeverity/description or something like that | 02:04 |
| SteveA | BradB: I need to workrave for a couple of minutes | 02:04 |
| sabdfl | SteveA: how do i add methods to that object? | 02:04 |
| sabdfl | #2101 | 02:04 |
| SteveA | BradB, lulu: I've copied you into an email to Viktorija Zaksiene, about making the cacheing work on the plone site. | 02:04 |
| BradB | ah, ok, cool | 02:05 |
| SteveA | BradB: copied you in in case there's changes that need to be made on the filesystem code. | 02:05 |
| lulu | SteveA: saw that - thanks Stevo. | 02:05 |
| SteveA | sabdfl: not sure what you want to do. | 02:05 |
| limi | SteveA: Mark is talking about the shorthand code I need for the portlets | 02:05 |
| === SteveA workraves for 3 mins | ||
| limi | https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2101 | 02:05 |
| (spiv/#launchpad) Meeting time? | 02:05 | |
| SteveA | in 3 mins, sharp! | 02:06 |
| (spiv/#launchpad) Ok. | 02:07 | |
| SteveA | hi everyone. let's have a lunchpad meeting. | 02:09 |
| === Kinnison raises his hand to indicate presence | ||
| === spiv is here | ||
| SteveA | all present please follow Kinnison's example | 02:10 |
| === SteveA raises hand too | ||
| sabdfl | let's go | 02:10 |
| SteveA | debonzi sends apologies | 02:10 |
| === BradB ready to rock | ||
| === carlos here too | ||
| SteveA | Kinnison needs to leave soon | 02:10 |
| === limi is here | ||
| SteveA | Malone -- where are we at? | 02:10 |
| BradB | we need to: | 02:11 |
| SteveA | what's been done since last week's meeting? | 02:11 |
| limi | eek, the dash-dash is creeping into your everyday language, SteveA | 02:11 |
| BradB | 1. implemented notification on edits | 02:11 |
| sabdfl | code has been restructured | 02:11 |
| BradB | 2. implement incoming email | 02:11 |
| limi | Malone is more sexy! | 02:11 |
| sabdfl | eye candy | 02:11 |
| BradB | 3. get a doctest suite that is enough to avoid me spending more time on regression fixes | 02:11 |
| BradB | 4. fix a bug such that ownerID isn't always set to 1 | 02:11 |
| sabdfl | several page tests, not as many as doap | 02:11 |
| sabdfl | BradB: throughout? | 02:12 |
| limi | first static version of the search/selection widget is in, using dummy data at the moment | 02:12 |
| BradB | sabdfl: yeah | 02:12 |
| sabdfl | BradB: great | 02:12 |
| BradB | that might not be a problem specific to malone either | 02:12 |
| SteveA | so, you very much need me to fix the page test maker so that it doesn't break so much | 02:12 |
| SteveA | (I'm working on it) | 02:12 |
| BradB | since last week, i've mainly spent time on keeping up with regression fixes from refactoring, and implemented notification for everything that can be added to a bug | 02:13 |
| SteveA | are you doing outgoing email too? | 02:13 |
| BradB | (and, of course, plone-related stuff) | 02:13 |
| stub | Hmm.. I had owner working on Bug... so that can be used as a basis for the other objects. | 02:13 |
| sabdfl | SteveA: instead of running launchpad and the proxy separately, can we have the pagetest script fire them up together? | 02:13 |
| BradB | SteveA: it's done for things that can be added; it's not done for edits yet. | 02:13 |
| SteveA | sabdfl: yes, we can | 02:14 |
| stub | I refactored the outgoing email sending stuff majorly today, but I don't think anyone else has had a change to look at it yet. | 02:14 |
| BradB | you mean mailnotification.py? | 02:14 |
| stub | mail.py | 02:14 |
| BradB | ah | 02:14 |
| sabdfl | stub: looked good to me | 02:15 |
| SteveA | stub: I want to make outgoing email have a "pagetests" mode where it won't send the email, but will store it in a list of emails, that has views under /emails/... so that it can be queried via pagetests | 02:15 |
| stub | There is a test harness for email - just trying to get the tests for the testharness working now. | 02:15 |
| limi | woo, offline mode - will we get MS Exchange support too? :] | 02:15 |
| stub | Emails just get stored in memory, where the tests can find them trivially | 02:15 |
| SteveA | great. I also want to make email easily tested via normal pagetests | 02:16 |
| SteveA | on releasing malone for use... | 02:16 |
| SteveA | what things are left to do? | 02:16 |
| BradB | for dogfooding, just testing | 02:17 |
| BradB | for general release, the four things i mentioned above, plus more testing | 02:17 |
| BradB | and, of course, deciding on where to put it and who'll deploy it | 02:18 |
| SteveA | do the rest of the team agree that we can start dogfooding right away? | 02:18 |
| SteveA | we're going to put is on mawson, right? | 02:18 |
| sabdfl | yes | 02:19 |
| SteveA | who will do that? | 02:19 |
| stub | The ownership bug could cause Mark to get spam atm... | 02:19 |
| BradB | for dogfooding? i don't think so. | 02:20 |
| stub | Oh... scratch that comment.. | 02:20 |
| SteveA | we need to decide on the port it will run on, and get elmo or thom to set up the vhosting appropriately | 02:20 |
| Kinnison | sabdfl: lucille just created a set of warty overrides which look and smell almost perfect | 02:20 |
| sabdfl | Kinnison: d29vaG9v! | 02:21 |
| === Kinnison grins | ||
| SteveA | BradB: will you be in charge of deploying malone on mawson? | 02:21 |
| === sabdfl wonders how bad overrides really smell | ||
| BradB | SteveA: sure | 02:21 |
| SteveA | thanks | 02:21 |
| SteveA | start it today? | 02:21 |
| BradB | SteveA: sure | 02:21 |
| sabdfl | we can use the bugzilla watch feature to watch older launchpad bugs | 02:22 |
| SteveA | ok. let's aim to have malone dogfood edition running by the end of (your) today | 02:22 |
| stub | I can take over my tomorrow if there are still things to do. | 02:22 |
| limi | Director's Cut | 02:22 |
| Kinnison | sabdfl: These ones smell like freshly baked bread when you're really hungry | 02:22 |
| limi | Warts & All | 02:22 |
| sabdfl | stub: i just realised we probably need need to support authenticated connections to remote bug systems | 02:22 |
| stub | sabdfl: Tell me about it. The test suite is talking to bugzilla.org because our bugzillas are all protected. | 02:23 |
| SteveA | can we wrap up the malone part of this meeting shortly? | 02:23 |
| sabdfl | stub, ok let's discuss oob | 02:23 |
| SteveA | spiv and Kinnison: soyuz and lucille? | 02:24 |
| sabdfl | BradB: can we set a systemwide cc for malone emails? | 02:24 |
| Kinnison | lucille since last week.... | 02:24 |
| SteveA | in case anyone missed it, spiv is the new doap dealer, and is a friend of foaf | 02:24 |
| Kinnison | I now have a cleaner dataset wrt. sections | 02:24 |
| BradB | sabdfl: sure | 02:24 |
| (spiv/#launchpad) SteveA: :) | 02:24 | |
| Kinnison | lucille just completed a perfect publishOverrides() of the warty snapshot I'm working with | 02:24 |
| Kinnison | There's now a pile of new views and stuff I'm going to ask stub to integrate into the db soon | 02:25 |
| SteveA | what does that mean? | 02:25 |
| BradB | sabdfl: it can be hacked in quickly and easily enough, but yeah, we need plenty more UI there for collector-wide config | 02:25 |
| Kinnison | the overrides tell the tools which build Sources and Packages files how/where to put everything | 02:25 |
| Kinnison | It's the second-to-last stage in generating apt-gettable archives | 02:25 |
| SteveA | why is it called an override? | 02:25 |
| SteveA | (just trying to get my head around it) | 02:25 |
| Kinnison | It's called an override because it theoretically differs from the values which may be stored in the package itself | 02:26 |
| sabdfl | SteveA: the joys of Katie naming | 02:26 |
| SteveA | i see | 02:26 |
| Kinnison | E.g. the package may say "admin" but we put it in "libs" | 02:26 |
| sabdfl | i think we should call it DistroPackagePolicy | 02:26 |
| === SteveA points at the glossary | ||
| Kinnison | sabdfl: In the db they're just the section columns etc in the Publishing tables | 02:26 |
| sabdfl | i don't think we should be exporting the overrides terminology to end-user derivatives | 02:26 |
| BradB | sabdfl, stub: do you guys want to/have more time to test malone today before i put it on mawson? | 02:27 |
| Kinnison | sabdfl: it's only at the level where we're outputting stuff for apt-ftparchive to work on that we touch the term 'override' at all | 02:27 |
| sabdfl | it should be "Define your package selection policy" | 02:27 |
| Kinnison | sabdfl: this is outside the scope of lucille currently | 02:27 |
| sabdfl | dude, i know how this stuff works, the table names bubble up to the UI | 02:27 |
| sabdfl | i just found a bunch of my own UI that talks about "product" and changed it to "upstream" because it's clearer in that context | 02:27 |
| Kinnison | the word 'override' only features in the views which lucille uses to pull the data out for the override files | 02:28 |
| Kinnison | I would hope that the UI will never touch those views | 02:28 |
| stub | BradB: I was just going to finish of the mail stuff before bed. | 02:28 |
| sabdfl | Kinnison: sure, but i think, since we are creating the tables, we should call them what we would be happy to expose | 02:28 |
| sabdfl | Kinnison: it always does though | 02:28 |
| Kinnison | sabdfl: the tables are the publishing tables; or do you mean we should name the views as though we want to expose them too? | 02:28 |
| sabdfl | packagepolicy or something thereabouts please | 02:28 |
| sabdfl | Kinnison: if the views are good and useful, which i'm sure they are, new devs on lp will use them, and expose them, so yes | 02:29 |
| BradB | stub: ok, i'll do the testing then | 02:29 |
| Kinnison | sabdfl: Okay, I'll ponder on a good name for them and do that change when I do the column-rename to make them consistent with the rest of soyuz | 02:29 |
| sabdfl | thanks | 02:29 |
| sabdfl | anything else on lucille? | 02:30 |
| stub | BradB: If we are using autogenerated forms, the owner fix is a trivial bit of .zcml I think. I might do that too if I have time. | 02:30 |
| Kinnison | It's been mostly cleaning up and doing the overrides | 02:30 |
| SteveA | getting lucille in actual use... when where how? | 02:30 |
| BradB | stub: we are; it's getting set in all the factories | 02:30 |
| Kinnison | stevea: I need to finish the bits of gina I have floating for making it safe for incremental use | 02:31 |
| BradB | stub: Either way it's just a query-replace in Emacs. | 02:31 |
| Kinnison | stevea: then we're clear to use gina to import the archive into launchpad and use lucille to export it again | 02:31 |
| Kinnison | SteveA: Once I have the apt-gettable bits sorted of course | 02:31 |
| stub | oic | 02:31 |
| sabdfl | again, let's use mawson | 02:31 |
| === Kinnison nods. Mawson is a good plan | ||
| sabdfl | aim is to have katie managing that warty / hoary archives | 02:31 |
| sabdfl | and gina running over them constantly to keep mawson's soyuz db up to date | 02:32 |
| === Kinnison nods | ||
| sabdfl | then we should be able to publish a "lucille version" of the archives | 02:32 |
| sabdfl | on mawson | 02:32 |
| === Kinnison has a couple of tweaks to gina sitting waiting for me to be ready to do a pqm merge | ||
| sabdfl | and do a lot of testing | 02:32 |
| === Kinnison nods | ||
| Kinnison | is it okay for me to continue using zhongshan for my experiments? | 02:32 |
| sabdfl | how the hell we'll cut over from katie to lucille for production i don't know :-) | 02:32 |
| sabdfl | Kinnison: fine by me | 02:33 |
| Kinnison | sabdfl: we shouldn't worry about cutting over until lucille can do uploads :-) | 02:33 |
| sabdfl | sure, and has been well, well tested | 02:33 |
| === Kinnison nods | ||
| sabdfl | also, build management | 02:33 |
| Kinnison | katie may be a bit cranky; but she's very well tested | 02:33 |
| sabdfl | then we get to the point where maintainers can steer their package through the whole upload / build / deploy process trhough the web | 02:33 |
| === Kinnison nods | ||
| sabdfl | at that point we can figure out the transition | 02:34 |
| SteveA | Kinnison: any rough idea when we'll see this stuff on mawson? | 02:34 |
| Kinnison | SteveA: My targets for lucille over the coming week... 1. Confirm the overrides look clean. 2. get apt-ftparchive doing its thing and again confirm it looks clean. 3. Get gina reliable on incremental updates. 4. Hopefully start getting it going on mawson | 02:34 |
| sabdfl | s/overrrides/ packagepolicies/ | 02:35 |
| sabdfl | that's great progress so far, thanks Kinnison | 02:36 |
| sabdfl | next? | 02:37 |
| limi | Rosetta? | 02:37 |
| SteveA | next, spiv | 02:37 |
| limi | (if they are here) | 02:37 |
| === SteveA pings carlos and daf for later | ||
| limi | ok | 02:37 |
| sabdfl | spiv: around? | 02:37 |
| carlos | SteveA: pong | 02:37 |
| (spiv/#launchpad) Ok. | 02:38 | |
| SteveA | spiv: foaf and doap plans? | 02:38 |
| SteveA | and soyuz status plase | 02:38 |
| (spiv/#launchpad) I'll about to start tackling the doap todo list that sabdfl posted to the list yesterday. | 02:39 | |
| (spiv/#launchpad) (I've been spending an unexpectedly large aount of time chasing buttress/zopeless bugs for lifeless, which has in turn found an sqlos bug) | 02:40 | |
| SteveA | what's happening with soyuz? | 02:41 |
| sabdfl | spiv: do we have a good framework for zopeless access to the db? what's kinnison using? | 02:41 |
| (spiv/#launchpad) I'm relatively out-of-the-loop on soyuz atm. | 02:41 | |
| (spiv/#launchpad) sabdfl: We will shortly. | 02:41 | |
| sabdfl | how will it be different to what kinnison is using? | 02:42 |
| SteveA | I'll catch up with the other soyuz guys a bit later. | 02:42 |
| (spiv/#launchpad) But debonzi has done some good work moving queries out of soyuz/sql.py into the SQLObject classes. | 02:42 | |
| sabdfl | Kinnison seems to have become productive very quickly | 02:42 |
| (spiv/#launchpad) The code is starting to look vaguely neat ;) | 02:42 | |
| === Kinnison is using SQLObject stuff wherever possible | ||
| Kinnison | the only non SQLObject stuff I've got is in gina | 02:43 |
| stub | spiv: There is a patch from Lalo that I think is still outstanding. Is that still relevant? | 02:43 |
| (spiv/#launchpad) Kinnison: I'm familiar with what the librarian does, what does lucille do? | 02:43 | |
| Kinnison | I'm currently driving most of my stuff using the db harness | 02:43 |
| (spiv/#launchpad) stub: Yes, that's part of what I've got for lifeless. | 02:43 | |
| (spiv/#launchpad) That will probably get merged tomorrow unless lifeless finds more bugs. | 02:43 | |
| Kinnison | spiv: Lucille is the archive management component of soyuz. Her jobs include dealing with uploads, publishing packages to distro archives on disk etc. | 02:43 |
| (spiv/#launchpad) Kinnison: I meant with respect to db access ;) | 02:44 | |
| Kinnison | spiv: Oh; she walks all sorts of tables all over the place and gathers data; etc. | 02:44 |
| === Kinnison ponders which tables lucille currently uses | ||
| (spiv/#launchpad) Kinnison: SQLObject? | 02:44 | |
| Kinnison | spiv: Oh yes; SQLObject all the way | 02:45 |
| SteveA | can we move on to rosetta? | 02:46 |
| (spiv/#launchpad) Ok. I'll catch up with Kinnison later. | 02:46 | |
| SteveA | carlos: how is the rosetta alpha going? | 02:46 |
| carlos | SteveA: well, as I said other times, we are not getting as many input as I thought we could get | 02:47 |
| SteveA | I wonder why | 02:47 |
| carlos | I think we should try to push real data in the game so they see it as a real system | 02:47 |
| SteveA | is it that there aren't the products people want to translate in the system? | 02:47 |
| sabdfl | carlos: do we have any upstreams that are interested in using the system for their products? | 02:48 |
| SteveA | we need to make it so that translators can scratch their own itches | 02:48 |
| carlos | well, we don't have all products imported, only two, | 02:48 |
| SteveA | we need to do whatever is required to get translators using rosetta, otherwise there's no point having the alpha | 02:48 |
| carlos | sabdfl: not upstreams as it, but Lliurex, a Debian derivated distributions asked us to implement some features so they could use Rosetta | 02:48 |
| carlos | for they translation team | 02:49 |
| sabdfl | ok | 02:49 |
| carlos | /s/they/their/ | 02:49 |
| SteveA | have the alpha translators been asked what they'd like to translate? | 02:49 |
| sabdfl | it's not necessarily the upstream maintainer that needs to like rosetta | 02:49 |
| sabdfl | it's just somene from theupstream translation team | 02:49 |
| carlos | SteveA: no, I will talk with daf about it | 02:50 |
| === limi can volunteer the Plone translation team | ||
| limi | 40+ languages | 02:50 |
| carlos | limi: that could be really good | 02:50 |
| SteveA | there are not so many weeks left before we wnt to do a public beta of rosetta, so getting more use out of it now is important. | 02:50 |
| sabdfl | just need one person who can act as a gateway, moving pofile patches between rosetta and upstream | 02:50 |
| limi | carlos: shoot me a mail about it when you are ready, and I will organize it | 02:50 |
| carlos | limi: ok, thanks | 02:51 |
| carlos | sabdfl, SteveA: What about get a small group of translators for Ubuntu? | 02:51 |
| limi | of course, it will take some time before people *trust* the system, but they should be willing to attempt it | 02:51 |
| carlos | I have some people at ubuntu-es asking for translate things | 02:51 |
| sabdfl | carlos: that's great, for things like the installer | 02:51 |
| sabdfl | carlos: yes, go for it | 02:52 |
| carlos | ok | 02:52 |
| SteveA | zope3 has been released as a final, I think. Maybe ask Phillip von W (who is on the rosetta testers list) if there's any interest getting people to translate it using rosetta? | 02:52 |
| limi | "zope3 has been released as a final, I think" - in the neverending series of proofs why Zope Corp's PR sucks :] | 02:52 |
| carlos | SteveA: ok, added to my list | 02:52 |
| sabdfl | is there a plan for us to update to zope3? | 02:53 |
| SteveA | we should continue using snapshots of the trunk for a while yet. | 02:53 |
| carlos | zope3, plone, ubuntu-installer and any other request from our alpha testers | 02:53 |
| SteveA | for example, the fix to make debugging traversed things clearer will not be in this zope3 release, but on the trunk | 02:53 |
| SteveA | it will be in the next zope3 release | 02:53 |
| SteveA | what's been implemented recently for rosetta? what's the next lot of rosetta work to be done? | 02:55 |
| carlos | well, the main implementation | 02:55 |
| carlos | was the msgset split (it's being review by daf) | 02:55 |
| carlos | after that merge we should not have big code changes | 02:56 |
| carlos | only bug fixes and missing features implementation | 02:56 |
| SteveA | carlos: Godefroid Chappelle, zope / plone /zope3 developer from Belgium, is interested in being a rosetta tester. gotcha@bubblenet.be | 02:56 |
| carlos | so I think we could also concentrate on the Beta release, and integration with soyuz | 02:56 |
| carlos | SteveA: ok, I willl add him to the alpha testers list, thanks | 02:57 |
| SteveA | let's have a chat about rosetta tomorrow or monday | 02:58 |
| SteveA | looking at still open bugs, things to implement next | 02:59 |
| SteveA | we can arrange this when daf shows up | 02:59 |
| SteveA | Anything more for rosetta? | 02:59 |
| carlos | only... | 02:59 |
| carlos | stub: could you review my last database request, please? | 02:59 |
| carlos | :-) | 02:59 |
| carlos | that's all | 03:00 |
| SteveA | Lastly, general launchpad issues. | 03:00 |
| SteveA | * use tla add not arch-tag: from now on | 03:00 |
| SteveA | I'll make a checkin soon that will not allow commits that use new arch-tag:s | 03:00 |
| BradB | * please mail the list when you introduce a new dependency, kthnx | 03:00 |
| BradB | ;) | 03:00 |
| SteveA | BradB: are you talking about the python-in-postgres stuff? | 03:01 |
| sabdfl | especially one that has issues on macosx | 03:01 |
| sabdfl | apt_pkg | 03:01 |
| BradB | SteveA: or apt_pkg, or whatever | 03:01 |
| SteveA | what are we doing about apt_pkg on osx ? | 03:02 |
| BradB | kiko reported the bug; it won't get fixed anytime soon (realistically speaking) | 03:02 |
| SteveA | does this have any bad effects on you? | 03:03 |
| BradB | he managed to fool it into compiling, but it hung on import; was trying to do some kind of threading calls. his bug report explains it more clearly, of course. :) | 03:03 |
| BradB | SteveA: it did, but not really anymore. | 03:03 |
| elmo_ | not being funny, but why don't we just specify linux as the development platform? | 03:03 |
| BradB | elmo_: That was my suggestion. :) | 03:03 |
| BradB | I confirmed before I started that OS X would be okay, but it turns out that's not true. :) | 03:04 |
| sabdfl | i have a workaround | 03:04 |
| sabdfl | asimple stub implementation that we knocked up for limi | 03:04 |
| sabdfl | def ParseDepends(deptext): | 03:04 |
| sabdfl | return [[('macosx', '', ''),] ] | 03:05 |
| sabdfl | same for ParseSrcDepends | 03:05 |
| BradB | yeah | 03:05 |
| sabdfl | should basically work | 03:05 |
| BradB | I'm just setting them to None, and it works fine, because I don't use Soyuz anyway | 03:05 |
| sabdfl | dont know if we can put a wrapper in launchpad which will use that implementation on macosx and the native full implementation on linux | 03:05 |
| sabdfl | BradB: that will likely break when they have better page tests | 03:06 |
| sabdfl | anyhoo | 03:06 |
| BradB | it used to make the page tests fail, but they pass now, heh heh | 03:06 |
| SteveA | any other general launchpad things? | 03:06 |
| SteveA | Can we have the next launchpad meeting on Wednesday next week, 12:00 UTC? | 03:07 |
| BradB | sure | 03:07 |
| (spiv/#launchpad) Suits me. | 03:07 | |
| SteveA | I'll be on vacation from Thursday. Back on Monday 8th. | 03:07 |
| Kinnison | Should be fine for me | 03:07 |
| === BradB might be in toronto next week | ||
| SteveA | Any other business. If not... | 03:08 |
| carlos | Wednesday is fine | 03:08 |
| SteveA | Thanks for your patience. We managed it in under 1 hour this time. | 03:08 |
| SteveA | I'll summarize this meeting and send to the list for those who were absent. | 03:08 |
| SteveA | and for those that specially requested a summary, Kinnison | 03:09 |
| === BradB goes to grab a coffee, then come back for d-day (i.e. dogfood day) | ||
| === SteveA declares the meeting over and goes to workrave a bit | ||
| carlos | limi: where could we found the .pot / .po files from zope? | 03:11 |
| === Kinnison was about to say "Oddly, workrave hasn't bothered me today" but I just realised that means I quit it :-( | ||
| limi | carlos: Zope 3? | 03:13 |
| carlos | sorry | 03:13 |
| carlos | :-) | 03:13 |
| carlos | plone | 03:13 |
| carlos | O:-) | 03:13 |
| limi | oh | 03:13 |
| limi | http://sf.net/projects/plone-i18n | 03:14 |
| SteveA | aw crap: lib/canonical/browser-exception.zcml 0e25fabf-8d8b-4f3d-a88a-de12fc152573_--> | 03:14 |
| SteveA | yep -- the closing XML comment is part of the arch id | 03:14 |
| carlos | limi: thanks | 03:15 |
| SteveA | there are quite a few of these | 03:16 |
| SteveA | I'm sort of inclined to remove the arch-tag: and make them have fileids | 03:16 |
| SteveA | any objections to losing some history from 17 zcml files? | 03:16 |
| (spiv/#launchpad) Not from me. | 03:17 | |
| limi | nope | 03:18 |
| === limi almost removed one yesterday, but didn't have the balls to do it ;) | ||
| limi | gotta keep the arch gods happy :] | 03:19 |
| === BradB removed a package yesterday, sprouted a couple more chest hairs | ||
| === BradB is now known as BradB|out | ||
| stub | SteveA: I'm messing with the zcml atm - it might cause me merge grief | 03:42 |
| SteveA | I'm not altering those zcml files right now | 03:42 |
| SteveA | but, maybe you'd like to? | 03:43 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: lucille override publishing work (patch-662) | 03:44 | |
| stub | SteveA: I have a file in package-includes that will issue warnings if it is run in the test suite (spawns a thread). Should I turn it off by encoding that configuration directly in the zopeapp.zcml you think? (This actually looks like a z3 issue, as the z3 tests would also issue the spurious warning if the queued email delivery thingy is switched on) | 03:44 |
| SteveA | arch tags go on to the end of the line | 03:44 |
| SteveA | they don't stop after a normal-looking uuid | 03:44 |
| SteveA | they go to the end of the line, with odd characters (like spaces) turned into underscores. | 03:45 |
| SteveA | <bob2> it's a semi-bug | 03:45 |
| stub | Cool... not only do they suck, they are buggy too :-) | 03:45 |
| SteveA | <ddaa> Tom likes the idea that you can put advertisements/propaganda in ids. | 03:45 |
| SteveA | <SteveA> argh! | 03:45 |
| SteveA | <SteveA> that is so fucking lame | 03:45 |
| SteveA | <SteveA> someone shoot tom | 03:45 |
| stub | Mmm.... lose file revision history by trimming spurious whitespace from the end of the line, or changing character set encoding even. | 03:46 |
| ddaa | I am seriously puzzled by what makes you think that taglines suck... | 03:46 |
| ddaa | Mh. Yeah. They are a bit more dangerous. | 03:47 |
| stub | Because they make me have to worry about magic id tags, which is the job of the rcs system. | 03:48 |
| ddaa | stub: in my experience, they do not. | 03:49 |
| SteveA | stub: can you kill the arch-tags in zcml files please? | 03:49 |
| SteveA | seeing as you're checking in soon anyway | 03:49 |
| stub | I havn't been game to try it, but I would assume you get into trouble if you delete them, copy files without changing them, accidently hit the wrong key and delete or change a letter. They scare me, and the whole point of rcs systems is to make you feel safe and secure. | 03:50 |
| ddaa | Delete: will make the file untagged. For other reasons "untagged-source unrecognized" is good, so tla won't let you commit it. Copy: will cause duplicate ids, which is an inventory error, tla won't let you commit. Modify: will cause a delete-add which is very easy to spot in the "changes" output that you (I hope) always check before commiting. | 03:53 |
| ddaa | There should maybe be a finger guard to prevent add-remove of the same file. It's never what you want to do except when you know that is what you want to do. | 03:54 |
| ddaa | safeguard: prevent commit unless an option is given. | 03:55 |
| === SteveA adds to http://manifesto.gnuarch.org/moin.cgi/ArchWarts | ||
| sabdfl | ddaa: (1) the revision control system should be an entirely hidden layer | 03:55 |
| sabdfl | in other words, my content should be ignorant of the revision control system i am using | 03:56 |
| ddaa | sabdfl: that's a valid point. | 03:56 |
| ddaa | That philosophical, but valid, | 03:56 |
| sabdfl | right now, for example, we are busily trying to convert thousands of files from CVS to Arch | 03:56 |
| sabdfl | imagine if CVS REQUIRED the presence of some cvs-tag inside the file | 03:57 |
| ddaa | sabdfl: yeah, I am aware of that :-) | 03:57 |
| sabdfl | and Arch REQUIRED that you had something else | 03:57 |
| sabdfl | then we couldn't do that | 03:57 |
| sabdfl | revision control systems need to be invisible | 03:57 |
| ddaa | Yup. The REQUIRED part is bad. | 03:57 |
| sabdfl | .arch-id's may be a poor implementation but they at least meet this criteria | 03:58 |
| SteveA | I'm somewhat gutted that there is no way of moving from tags inside files to explicit ids, while preserving history. | 03:58 |
| sabdfl | we can over time improve the implementation and use some other form of database than .arch-id's | 03:58 |
| sabdfl | which is faster | 03:58 |
| Kinnison | SteveA: copying the arch tag into the .arch-ids/filefoo doesn't work? | 03:58 |
| ddaa | I'm not sure that .arch-ids is a bad idea per se. | 03:58 |
| SteveA | apparently not. | 03:58 |
| sabdfl | but at least, for the moment, they are correct | 03:58 |
| sabdfl | (14:57:51) ddaa: Yup. The REQUIRED part is bad. | 03:58 |
| sabdfl | so that brings me to part (2) | 03:58 |
| sabdfl | revision control systems should be used consistently for different files | 03:59 |
| sabdfl | "i tried to move my file but arch doesn't see that it's been moved" | 03:59 |
| ddaa | sabdfl: good ol' tactic. It's not bad per se efficiency-wise, which is what I was answering. | 03:59 |
| sabdfl | "did you use tla mv or just mv" | 03:59 |
| (spiv/#launchpad) Kinnison: No. tla id some_file... you'll see a leading i_ or x_ depending on if it's implicit or explicit. i.e. what kind of tag it is is part of the id. | 03:59 | |
| sabdfl | "just mv like I always do" | 04:00 |
| Kinnison | spiv: oh poo | 04:00 |
| sabdfl | "it worked for half the files" | 04:00 |
| sabdfl | "which half?" | 04:00 |
| sabdfl | "everything except the jpg's" | 04:00 |
| sabdfl | "oh, the jpgs are different becuase we odn't have arch tags inside them" | 04:00 |
| sabdfl | "you have to work differently with arch tags" | 04:00 |
| SteveA | spiv: but, will tla complain if a fileid starts with an i_ ? | 04:00 |
| sabdfl | the fact that arch allows us to mv a file and preserve history is FANTASTIC | 04:01 |
| SteveA | spiv: if so, it is treating ids as containing semantics, which is kinda wrong. | 04:01 |
| sabdfl | it's no hardship to require that, when you do this, you use tla mv | 04:01 |
| sabdfl | you are requiring consistent behaviour | 04:01 |
| ddaa | sabdfl: so your point is that the fact "mv" works with tagline is a argument against using them? | 04:01 |
| sabdfl | yes, exactly | 04:01 |
| (spiv/#launchpad) My understanding is that "tla mv" is supposed to work for both, and the fact it doesn't is a bug. | 04:01 | |
| sabdfl | it's a cute feature that fucks you in the head with users | 04:02 |
| SteveA | how do people write docs about "arch-tag: " and keep them in arch? turn off the implicit tagging method? | 04:02 |
| sabdfl | it's a switch that LOOKS easy but requires detailed implementation knowledge | 04:02 |
| (spiv/#launchpad) SteveA: Not put the arch-tag text in the first or last 1k, perhaps ;) | 04:02 | |
| sabdfl | so, Canonical Arch will deprecate this altogether | 04:02 |
| sabdfl | there's another advantage to this | 04:02 |
| (spiv/#launchpad) http://wiki.gnuarch.org/moin.cgi/ID_2dtagging_20methods has some discussion of this. | 04:03 | |
| sabdfl | if we (a) make .arch-id's the required behaviour for ALL files | 04:03 |
| (spiv/#launchpad) Including "Why I Went From Loving Tagline To Disliking It, by Colin Walters" | 04:03 | |
| sabdfl | (b) remove any mention of .archids's from the documentation, users will forget they exist | 04:03 |
| sabdfl | and when we come up with a better implementation, users don't need to change or know anything different | 04:03 |
| ddaa | sabdfl: users will not forget they exist, because they remove them by hand when tree-lint tells them there are explicit ids w/o associated file. | 04:04 |
| (spiv/#launchpad) (Out of curiousity, what's the problem with .arch-ids that a different implementation could solve?) | 04:04 | |
| ddaa | sabdfl: I'm quite happy that we have a design discussion about arch, and I'd like to conduct that more in depth, but I think irc is not the best medium for that. | 04:05 |
| sabdfl | ddaa: that's a bug too | 04:05 |
| sabdfl | removing a file from the repo should be an explicit action | 04:06 |
| sabdfl | ddaa: we have a two week arch sprint planned for late november / early december | 04:06 |
| ddaa | it is an explicit | 04:06 |
| ddaa | action | 04:06 |
| Kinnison | As a small-time developer; if Canonical's arch didn't do tagline at all; I wouldn't use it | 04:06 |
| ddaa | Yeah. Still I think mailing list is the best medium. It gives more time to deep thought. | 04:06 |
| Kinnison | deprecate it by all-means; but don't prevent it | 04:07 |
| stub | ddaa: They should have to remove them by hand. arch would bitch during commands and ask them to recover it or forget it. | 04:07 |
| SteveA | doesn't "deprecate" mean "to be removed in a future version" ? | 04:07 |
| SteveA | (effectively speaking) | 04:07 |
| ddaa | sabdfl: please do me a favor and write that in a mailing list post to warthogs or launchpad. | 04:08 |
| stub | Kinnison: If it is there, users have to learn about it because they will see it in the wild. tla needs fewer features to learn, not more. | 04:08 |
| Kinnison | deprecate | 04:08 |
| Kinnison | v 1: express strong disapproval of; deplore | 04:08 |
| ddaa | All the points you have raised. | 04:08 |
| ddaa | I'm sure you have talked with lifeless about it, so you know that Arch is a complex (in terms of rich interactions between simple components) | 04:09 |
| Kinnison | stub: I far prefer arch-tag to .arch-id wherever I can have them though :-( | 04:10 |
| ddaa | so design changes need a lot of cool-headed consideration. | 04:10 |
| ddaa | Because it's easy to come up with changes which appear simple at first but have unexpected effects in corner cases. | 04:11 |
| sabdfl | Kinnison: http://wiki.gnuarch.org/moin.cgi/ID_2dtagging_20methods | 04:11 |
| Kinnison | sabdfl: read it already | 04:11 |
| Kinnison | sabdfl: doesn't stop me *personally* preferring arch-tag for my personal projects | 04:11 |
| Kinnison | sabdfl: arch-tag is one of the reasons I decided to move my personal development into tla archives | 04:12 |
| ddaa | sabdfl: I wrote most of this page. | 04:12 |
| ddaa | at least initially. | 04:12 |
| sabdfl | that's fine | 04:12 |
| sabdfl | i've no problem preserving existing behaviour | 04:13 |
| sabdfl | but i think it's necessary to strongly encourage a use pattern that leaves the maximum flexibility for changes in implementation | 04:13 |
| sabdfl | and arch-tag doesn't | 04:13 |
| ddaa | That's a valid point. | 04:14 |
| Kinnison | sabdfl: as I said; deprecate it by all-means; encourage .arch-ids by default; but don't remove arch-tag or it'll annoy too many people | 04:14 |
| sabdfl | Kinnison: agreed | 04:14 |
| === Kinnison decides that 'deprecate' is the word of the day | ||
| === Kinnison wonders if he can get it into a conversation with his father later | ||
| ddaa | sabdfl: but please write this ML message, that will be much more conducive to a fruitful discussion than irc chat. | 04:14 |
| stub | So if I want to stop things being sucked into our arch archive, all I would have to do is make sure I stick 'arch-tag: biteme' in every one of my source files? | 04:15 |
| Kinnison | stub: yep | 04:15 |
| (spiv/#launchpad) stub: Well, you can set tagging-method to ignore it, I think. | 04:16 | |
| (spiv/#launchpad) I think that's the default, even. | 04:16 | |
| (spiv/#launchpad) stub: see the docs for "tla id-tagging-method". | 04:17 | |
| ddaa | "explicit" id-tagging method ignores taglines. | 04:19 |
| === SteveA -> food | ||
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| ddaa | SteveA: "arch-tag: " is only used by tla when the leading chars are all whitespace or punctuation. | 04:32 |
| === BradB|out is now known as BradB | ||
| ddaa | In addition, an explicit tag always override a tagline. | 04:34 |
| ddaa | In the past, (the now deprecated "implicit" tagging method), the marker was "tag: " which was found to be a practical problem. | 04:35 |
| sabdfl | stub: where is the best place to learn about auto-generated forms? | 04:43 |
| stub | Second half of the Z3 tutorial if it is still around. Otherwise the zope book from srichter available on the z3 wiki. | 04:44 |
| sabdfl | i need to start work on some of the existing auto-generated forms | 04:45 |
| sabdfl | my inclination is just to re-do them as page templates but it may just be me being a luddite | 04:45 |
| stub | Once the form machinery went into Z3, nobody used anything else ever again except for the most trivial pages. | 04:48 |
| stub | Its easy to knock up a simple form in the old style, but once you start adding validation, error handling etc. to make it actually look professional you see real benefits. | 04:49 |
| === Kinnison waves | ||
| === Kinnison will check-in later from wales | ||
| stub | http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Book | 04:53 |
| stub | And from page 27 onwards: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ProgrammerTutorial/programmers_tutorial.pdf | 04:54 |
| (dilys/#launchpad) Merge to rocketfuel@canonical.com/launchpad--devel--0: fix enum descriptions for bug severity (patch-663) | 04:54 | |
| sabdfl | stub: thanks, will educate myself this evening | 04:59 |
| BradB | elmo: How do I get to mawson? | 05:01 |
| BradB | (via ssh'ing, to dogfood malone, that is) | 05:03 |
| elmo_ | https://wiki.canonical.com/Machines | 05:06 |
| elmo_ | oh, except you have some prehistoric fucking ssh | 05:07 |
| elmo_ | err, MachineOverview | 05:07 |
| elmo_ | anyway, same way you get to gentoo | 05:08 |
| elmo_ | bounce throught chinstrap | 05:08 |
| === wartylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad | ||
| === Topic for #launchpad: lunchpad: home of the sandwich artists | fogo na bomba | "qorking along happily, with SteveA egging us on" | ||
| === Topic (#launchpad): set by sabdfl at Tue Oct 19 11:05:38 2004 | ||
| lulu | BradB:ping | 07:25 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Now checks for new or changes tags on merge. (patch-668) | 07:54 |
| SteveA | that was "changed" | 08:03 |
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] | ||
| SteveA | daf: hello | 08:22 |
| === BradB|lunch is now known as BradB | ||
| === mdz_ is now known as mdz | ||
| SteveA | spiv: hello | 08:23 |
| spiv | Hello. | 08:25 |
| SteveA | have you done any more work on the xml-rpc auth server lately? | 08:26 |
| spiv | Not since the nickname worth.k. | 08:26 |
| spiv | work, rather. | 08:26 |
| SteveA | ok | 08:26 |
| SteveA | there's a job coming up to integrate the shipit database with the golden database | 08:27 |
| SteveA | and integrate shipit's auth with the golden database | 08:27 |
| spiv | Ah. | 08:27 |
| SteveA | to do this, shipit should use the xml-rpc auth server | 08:27 |
| SteveA | but, we should also improve the api of the auth server | 08:27 |
| === spiv nods | ||
| spiv | sabdfl wants the api to stop sending the salt. | 08:27 |
| SteveA | indeed | 08:27 |
| SteveA | we should do a new api | 08:28 |
| SteveA | and keep the old one around until we can get the plone ode changed | 08:28 |
| SteveA | s/ode/code/ | 08:28 |
| SteveA | the new api could run on the same port with new method names | 08:28 |
| SteveA | or could run on a new port | 08:28 |
| sabdfl | same port | 08:28 |
| sabdfl | no need to switch ports just because the api is evolving | 08:29 |
| daf | SteveA: hi | 08:29 |
| SteveA | it is easier to turn off the old one if they run on separate ports | 08:29 |
| SteveA | and it is clear which api is beign used -- all old or all new | 08:29 |
| daf | spiv: have you had a chance to look at those two test bugs I filed? | 08:29 |
| sabdfl | SteveA: we just update the server not to export the old api | 08:29 |
| SteveA | imagine this: we get someone to update the code in plone so that it uses the new api | 08:30 |
| SteveA | we test it, and it all works | 08:30 |
| SteveA | so we remove the old api | 08:30 |
| spiv | daf: The interface ones? | 08:30 |
| daf | spiv: yep | 08:30 |
| SteveA | and plone stops working, because one call to the old api was missed | 08:30 |
| spiv | daf: Not really. | 08:30 |
| daf | spiv: ok | 08:31 |
| spiv | daf: Except in the general, "Yep, these look like bugs alright" sense ;) | 08:31 |
| daf | :) | 08:31 |
| SteveA | daf: I'd like to have a rosetta meeting either tomorrow or monday | 08:31 |
| daf | SteveA: any reason why we can't do tomorrow? | 08:32 |
| SteveA | spiv: which way would you do it? new port or new api + old one on same port? | 08:32 |
| SteveA | anyhow, whichever way, are the requirements for the new api clear? | 08:32 |
| spiv | SteveA: I'm ambivalent. Code-wise for me, it's practically no difference. | 08:32 |
| SteveA | should we make this available over ssl? | 08:33 |
| daf | spiv: for #2121, is it just a matter of the parameter being added to the interface? | 08:33 |
| spiv | So if someone has a firm opinion on which way will make the transition easier, I'm happy to go with that. | 08:33 |
| spiv | daf: I think so, judging from Steve's comment. | 08:33 |
| daf | ok, I'll change the interface then | 08:33 |
| daf | #2122 seems less clear-cut | 08:34 |
| SteveA | do it mark's way, unless we need to do it over ssl, in which case, we'll need a new port anyway | 08:34 |
| spiv | I like SSL from the viewpoint of keeping our security code to a minimum. | 08:34 |
| SteveA | spiv: but, is the new api clear to you? | 08:34 |
| === BradB looks at Malone UI changes; "Sev", "Pri"...what gives? :) | ||
| SteveA | wha giv? | 08:35 |
| BradB | heh | 08:35 |
| BradB | woohoo, more unbreaking to do | 08:35 |
| spiv | SteveA: The only changes I'm aware of is sending passwords in plaintext rather than digests, and not returning salts. | 08:36 |
| daf | spiv: IBranch doesn't seem to have an __ne__, so I can't see why it's complaining | 08:37 |
| SteveA | ok. it occurs to me that you could avoid sending the salts too by always sending the same salt to plone, and decrypting in the xmlrpc auth server. | 08:37 |
| SteveA | that meets the goal of not sending any salts from the database, but without altering plone auth code. | 08:37 |
| SteveA | daf: does IBranch extend anything? | 08:38 |
| spiv | That doesn't work. | 08:38 |
| SteveA | I suppose it doesn't | 08:38 |
| daf | SteveA: oh, right, yes | 08:38 |
| daf | class IBranch(ICategoryItem, IPackage, IVersionIterable): | 08:38 |
| spiv | I can't transform SSHA(password, saltA) -> SSHA(password, saltB) without knowing the password. | 08:38 |
| BradB | stub: I don't have time to see why this is happening myself, but your mail changes don't seem to work here; I expected to get from/to of bradb@bbnet.ca, but instead got noreply/test respectively (as per what I last hardcoded in the Python code, but I expected that your changes subvert whatever the real email address was.) | 08:38 |
| SteveA | spiv: of course. I'm being gosh-it-is-late-and-i-am-not-thinkin | 08:39 |
| spiv | That's ok :) | 08:39 |
| === BradB decides to deploy a Malone from yesterday | ||
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| SteveA | spiv: so, can you add to you todo list to make appropriate changes to the auth server. add the new api, and I suppose also make it run ssl. do it the way mark wants, because i can't think of a good enough reason not to ;-) | 08:41 |
| spiv | :) | 08:41 |
| spiv | I'll file a bug against myself. | 08:42 |
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| carlos | hi | 08:42 |
| daf | INamespaceObject -> IArchiveItem -> ICategoryItem -> IBranch | 08:42 |
| daf | and INamespaceObject requires __ne__ | 08:42 |
| SteveA | looks like a bug in code. who owns that code? ddaa? | 08:43 |
| SteveA | daf: what time tomorrow? | 08:43 |
| daf | I suggest 1400 or 1500 UTC | 08:44 |
| SteveA | ok, 1400 | 08:45 |
| SteveA | carlos:is that okay with you? | 08:45 |
| BradB | SteveA: presumably i'll use the same DB as rosetta on mawson eh? | 08:47 |
| BradB | ew, hm, that might not work | 08:48 |
| SteveA | I'd suggest using a separate database | 08:48 |
| BradB | yeah, easier | 08:48 |
| SteveA | you'll want to update at different times etc. | 08:48 |
| BradB | yeah | 08:48 |
| carlos | SteveA: yes | 08:48 |
| SteveA | carlos: great | 08:48 |
| daf | spiv: who owns that code? | 08:48 |
| carlos | Don't know if it could be of your interest, but I'm packaging sqlobject for Debian, hope this weekend I will have the packages ready | 08:49 |
| daf | carlos: did you see my packages? | 08:49 |
| carlos | daf: hmm, not, do you have them? | 08:50 |
| daf | I made them a while ago | 08:50 |
| carlos | dammit | 08:50 |
| daf | but they may be of interest to you | 08:50 |
| daf | please go ahead with you packages | 08:50 |
| daf | * your | 08:50 |
| carlos | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193499 | 08:50 |
| daf | carlos: I made the packages for company use | 08:51 |
| carlos | daf: where do you have them?, perhaps I could reuse something. I have the basic packages done, I only need to split the documentation and add the suggestions for every backend supported | 08:52 |
| dilys | New bug 2128 for Launchpad/Launchpad: Update authserver API to not expose salts | 08:52 |
| dilys | https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2128 | 08:52 |
| daf | carlos: chinstrap:/home/daf/pacakges | 08:52 |
| carlos | daf: hnmm, right, I just remembered it ... | 08:52 |
| daf | actually, there are only binary packages there | 08:52 |
| SteveA | spiv: can you also file a bug on you and mako for "get shipit talking to the xmlrpc auth server for Persons" | 08:53 |
| spiv | Ok. | 08:54 |
| SteveA | thanks | 08:54 |
| carlos | daf: If you could send me the sources that could be really good, althought I think we have already the same done. | 08:54 |
| daf | carlos: I'm uploading the sources to chinstrap now | 08:55 |
| carlos | ok, thanks | 08:55 |
| daf | carlos: the .diff.gz is ugly because it removes the existing debian/ directory from the SVN snapshot | 08:55 |
| carlos | I will look at them this weekend | 08:55 |
| carlos | daf: I was using the final tar.gz and it didn't had it, so it's not a problem, don't worry | 08:56 |
| carlos | daf: Did you saw the log of today's meeting? | 08:56 |
| daf | carlos: right -- just a warning that reading the .diff.gz might be a bit troublesome :) | 08:57 |
| daf | carlos: not yet | 08:57 |
| carlos | daf: ok :-) | 08:57 |
| carlos | daf: ok, if you have time to talk about it, just tell me it, or should we wait for tomorrow's meeting with Steve? | 08:57 |
| daf | let's talk about the message set split | 09:00 |
| carlos | ok | 09:01 |
| daf | it took me a while to get a diff yesterday | 09:01 |
| daf | becuase my revision library got corrupted | 09:01 |
| daf | and arch was misbahaving in other ways | 09:01 |
| daf | and then when I did get a diff, it was quite hard to read | 09:02 |
| carlos | lots of changes... | 09:02 |
| daf | you changed the class names so that s/Message/Msg/? | 09:02 |
| carlos | I fixed some of them, then you told me that those changes should be outside the changeset (my fault) and I stopped doing it | 09:03 |
| carlos | but at that point was easy to fix the remaining renames than revert it | 09:03 |
| carlos | /s/easy/easier/ | 09:03 |
| daf | right, better to be consistent | 09:03 |
| daf | and you're confident that all references to the old class names have been changed? | 09:04 |
| carlos | I think so, I fixed the unittests, the functional tests and did some testing from the webinterface | 09:04 |
| daf | sounds good | 09:05 |
| daf | how do you store messages which appear in a PO file but not in the template? | 09:05 |
| carlos | I add the msgid to the potmsgset but with sequence=0 | 09:06 |
| carlos | the potmsgset.sequence=0, the pomsgset.sequence = SOMETHING | 09:06 |
| daf | hmm | 09:07 |
| daf | is it so that the message IDs are only stored in the potmsgset? | 09:07 |
| daf | i.e. you can't have a pomsgset without a potmsgset? | 09:08 |
| carlos | yes that was the idea behind the split | 09:08 |
| carlos | the have pomsgset.potmsgset that is a FOREIGN KEY to potmsgset.id | 09:08 |
| carlos | /s/the/we/ | 09:08 |
| daf | well, the main idea behind the split is that we didn't have one class representing two things | 09:09 |
| carlos | yes, but in Oxford I remember that we talked about it also | 09:10 |
| carlos | is it a problem? | 09:10 |
| carlos | I thought we had consensus about it, that's why I wrote the SQL script that way | 09:10 |
| dilys | New bug 2129 for Launchpad/Launchpad: get shipit talking to the xmlrpc auth server for Persons | 09:10 |
| dilys | https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2129 | 09:10 |
| daf | I'm trying to decide about it | 09:11 |
| carlos | daf: don't think it's too difficult to modify it | 09:11 |
| carlos | but I think it's better as it's now | 09:11 |
| carlos | that way, the export code is faster, you can get all pomsgset that have a potmsgset with sequence > 0 and you get the current msgsets | 09:13 |
| daf | I'm keeping an open mind about it | 09:13 |
| daf | but I would make the reference from pomsgset to potmsgset optional | 09:13 |
| daf | perhaps your approach is better :) | 09:13 |
| carlos | hmm, if we do it optional, we need pomsgidsighting for the pomsgset | 09:14 |
| daf | right | 09:14 |
| daf | okay, I think you should merge the branch | 09:14 |
| daf | if you are happy with it | 09:14 |
| carlos | could you run the unittests and functional tests so I'm sure I'm not missing anything? | 09:15 |
| daf | sure | 09:15 |
| carlos | thanks | 09:15 |
| daf | ddaa: around? | 09:15 |
| === BradB [~bradb@modemcable165.196-131-66.mc.videotron.ca] has joined #launchpad | ||
| daf | carlos: I'll also test a star-merge of the branch into a RF checkout | 09:16 |
| carlos | ok, then let me do a star-merge from rocketfuel first so I see if there is any conflict | 09:17 |
| daf | huh? | 09:19 |
| daf | how come all the unit tests on the branch pass? | 09:19 |
| daf | oh, I know | 09:20 |
| daf | because the interface tests are not automatically generated | 09:20 |
| carlos | I was merging from rocketfuel from time to time | 09:20 |
| carlos | sure? | 09:21 |
| carlos | I did not changed it | 09:21 |
| === justdave [~dave@24.247.63.44.gha.mi.chartermi.net] has joined #launchpad | ||
| BradB | elmo_: I need three things on mawson please: 1. a DB just for the malone alpha, 2. a port to listen on, 3. a URL at which to access the site (not sure what convention's in place for rosetta on URL names for the alphas.) | 09:24 |
| daf | BradB: for (2), all you need is to agree on a port the Apache proxy will forward to | 09:28 |
| BradB | sure, that's what i expected | 09:28 |
| daf | ok | 09:28 |
| daf | I wasn't sure | 09:29 |
| daf | I suggest 9020 | 09:29 |
| BradB | i get to punt apache config off to elmo_ though right? :) | 09:29 |
| daf | http://w.ul.o points to 9000 and http://r.sf.o points to 9010 | 09:29 |
| daf | yes, elmo will do the Apache config | 09:29 |
| daf | :) | 09:29 |
| BradB | yeah, so 9020 sounds fine to me | 09:30 |
| daf | I tend to run debug servers on N+1 or N+2 | 09:31 |
| elmo_ | you guys need to choose the URL, not me | 09:31 |
| elmo_ | you can create a db as the launchpad use which you have access to | 09:31 |
| daf | so I can set up an SSH tunnel from localhost:9011 to mawson:9011 and use the debug server on mawson from my browser | 09:31 |
| === BradB chooses malone.ul.o | ||
| elmo_ | I don't think sabdfl will go for that kind of URL for a pre-alpha dogfood | 09:35 |
| daf | why not? | 09:36 |
| BradB | ok, so we don't get to choose the URL then :) | 09:36 |
| elmo_ | daf: same reason as rosetta was moved | 09:36 |
| sabdfl | elmo_ it's fine, as long as we can put a client cert on it | 09:36 |
| BradB | i'll take whatever, as long it starts with malone | 09:36 |
| sabdfl | guys, i think we should make mawson the same as rosetaa currently | 09:36 |
| sabdfl | just have everything accessible from / | 09:37 |
| sabdfl | rosetta, soyuz, malone | 09:37 |
| sabdfl | then we can move seamlessly from doap to packages to bugs to translations | 09:37 |
| daf | how is that different from what we currently have? | 09:37 |
| sabdfl | all talking to the same db | 09:37 |
| BradB | sabdfl: can't | 09:37 |
| sabdfl | BradB: what am i missing? | 09:37 |
| BradB | sabdfl: e.g. the db the rosetta alpha's running on may not work with the schema i'm going to run with the version of malone i want to deploy | 09:38 |
| sabdfl | BradB: the rosetta alpha uses a different db altogether | 09:38 |
| sabdfl | u'm just saying use the same url layout | 09:38 |
| daf | sabdfl: use the same URL layout for what as what? | 09:39 |
| BradB | sabdfl: what did you mean by "all talking to the same db" then? | 09:39 |
| sabdfl | rosetta-dogfood, malone-dogfood, soyuz-dogfood | 09:40 |
| sabdfl | currently if I go to mawson.ubuntu.com | 09:40 |
| sabdfl | i see the development sevrer | 09:40 |
| BradB | sabdfl: only one alpha app will be talking to one db (even though you may be able to access the other apps from within that alpha app, there's only meant to be one that's actually being alpha'd, since the others may be in a pre-alpha state at the time you took a snapshot of the app you're wanting to deploy as an alpha.) | 09:40 |
| sabdfl | the one that resets every 30 minutes | 09:40 |
| daf | it doesn't make sense for us to dogfood rosetta because we're not doing translation | 09:40 |
| daf | we can dogfood Malone because we need a bug tracking system | 09:41 |
| sabdfl | daf: next step from the alpha would be to bring the user base to a more intense environment that includes the doap, package, bug stuff | 09:41 |
| daf | sabdfl: right, but that's not dogfood because it's not us using it | 09:41 |
| sabdfl | fari 'nff | 09:42 |
| sabdfl | it's kind of the "beta test next version" server | 09:42 |
| daf | sabdfl: maybe I'm being dim, but I can't grasp what you're saying about Mawson :) | 09:42 |
| sabdfl | look at the url table for https://mawson.ubuntu.com/ | 09:43 |
| sabdfl | it's the same as you get on your dev box | 09:43 |
| sabdfl | but different to the rosetta alpha | 09:43 |
| carlos | daf: in launchpad meeting we talked about start some translations of ubuntu as people are requesting those kind of contributions | 09:43 |
| sabdfl | i think the dogfood box should look the same as our dev boxen | 09:43 |
| sabdfl | just with a more serious db behind it | 09:44 |
| sabdfl | i tihnk we should do daily code updates on the dogfood box | 09:44 |
| daf | oh, right | 09:44 |
| daf | I think I'm with you now | 09:44 |
| sabdfl | each day stub would update the dogfood db and code simultaneously unless we *know* it's busted | 09:44 |
| daf | so you're saying the Malone dogfooding should not be restricted to Malone? | 09:44 |
| sabdfl | dafL: exactly | 09:44 |
| daf | why didn't you just say so? :) | 09:45 |
| sabdfl | daf: brain drain, i'm being a bit tired and dim :-) | 09:45 |
| daf | we'll need to be careful with DB updates | 09:45 |
| daf | we don't want to trash our bugs | 09:45 |
| sabdfl | sure, but that care is needed anyhow | 09:45 |
| sabdfl | backups | 09:45 |
| daf | right | 09:45 |
| sabdfl | later we can also access the same machine through: | 09:46 |
| sabdfl | malone-test.ubuntulinux.org | 09:47 |
| sabdfl | rosetta-test.ubuntulinux.org | 09:47 |
| sabdfl | and see the same codebase and same db, just with the url map structured appropriately | 09:47 |
| sabdfl | for a malone-only or rosetta-only view | 09:47 |
| sabdfl | also, we might get a partner project to let that be rosetta-test.project.org so their translators could use the bleeding edge stuff | 09:48 |
| daf | spiv: seems I'm getting functional tests failing because there's an existing authserver running | 09:48 |
| daf | spiv: this is rather annoying | 09:48 |
| sabdfl | and we get to exercise the domain-specific branding code | 09:48 |
| spiv | daf: :( | 09:48 |
| spiv | Hmm, actually, I think I have an idea how to make that more robust. | 09:49 |
| === sabdfl is now known as sabdfl|food | ||
| BradB | This would make my job a helluva lot easier | 09:52 |
| daf | BradB: whose job would it make harder? ;) | 09:52 |
| BradB | heh heh | 09:52 |
| === carlos goes to have dinner | ||
| daf | DatabaseException: ERROR: relation "beer_id_seq" already exists | 09:52 |
| daf | ?! | 09:52 |
| BradB | daf: maybe me (as for who's job it would make harder.) | 09:52 |
| carlos | Do we have beers in launchpad? | 09:52 |
| carlos | :-D | 09:53 |
| daf | yes, we do | 09:53 |
| carlos | nice! | 09:53 |
| daf | CREATE TABLE beer ( | 09:53 |
| daf | id SERIAL PRIMARY KEY, | 09:53 |
| daf | name TEXT NOT NULL UNIQUE, | 09:53 |
| daf | rating INT | 09:53 |
| daf | ) | 09:53 |
| BradB | we rank developers by how many beers they deserver | 09:53 |
| BradB | s/deserver/deserve/ | 09:53 |
| spiv | Hah. | 09:53 |
| BradB | wishful thinking anyway :) | 09:53 |
| daf | I like that idea :) | 09:54 |
| daf | UPDATE Person SET beers = (beers + 5) WHERE nick = 'daf'; | 09:55 |
| BradB | sabdfl|food: When and where do we deploy the dogfood LP and who's deploying it? | 09:55 |
| BradB | daf: heh | 09:55 |
| === BradB ctrl-c's his build config, in any case | ||
| daf | BradB: forget the "Donato to Ubuntu" portlet | 09:56 |
| daf | * Donate | 09:56 |
| daf | we need a "Send Canonical Developers a Beer" portlet | 09:56 |
| BradB | that'd be more practical | 09:56 |
| BradB | you can't get drunk off dollar bills, afterall | 09:56 |
| === SteveA [~steve@adsl-213-190-44-43.takas.lt] has joined #launchpad | ||
| BradB | SteveA: i like sabdfl|food's idea: dogfood LP | 10:00 |
| BradB | it's a lot simpler | 10:01 |
| SteveA | BradB: I think I missed something crucial to understanding that | 10:04 |
| BradB | SteveA: instead of dogfooding Malone, let's just have one dogfooded launchpad app | 10:05 |
| BradB | so instead of 4-5 dogfood apps, we'll just have one; instead of 4-5 dogfood db's, we'll just have one; etc. | 10:06 |
| SteveA | for malone and soyuz combined? | 10:06 |
| SteveA | rosetta isn't being dogfooded | 10:06 |
| BradB | it kind of should be though | 10:06 |
| SteveA | doing malone and soyuz combined makes sense to me | 10:06 |
| SteveA | don't know where 4-5 DBs came from | 10:06 |
| SteveA | I think your eggsagerating again ;-) | 10:07 |
| === SteveA mentions eggs | ||
| BradB | rosetta, doap, foaf, soyuz, malone; i count 5 | 10:07 |
| spiv | SteveA: egghead ;) | 10:07 |
| SteveA | I don't think there was ever any plan to dogfood doap and foaf separately | 10:07 |
| BradB | so, 1 instead of 3; the principle's the same :) | 10:09 |
| SteveA | anyhow, I think it is a good idea definitely for soyuz and malone (and doap and foaf). It may be a good idea for rosetta. Daf and carlos would need to decide that. | 10:11 |
| === SteveA goes to make evening food | ||
| BradB | i get the impression they're in favour. daf, carlos? | 10:12 |
| daf | I'm not sure what the change is, exactly | 10:13 |
| BradB | all in favour of dogfood say "arf!" | 10:13 |
| daf | it involves having more domains names? | 10:13 |
| BradB | daf: well, i'm not quite sure about the current rosetta. can it be considered to be dogfooding if we say it is, or are other people actually using it? | 10:14 |
| daf | "the current rosetta"? | 10:14 |
| BradB | daf: the current alpha you guys have running, or "beta test new version" or whatever you were saying it was earlier | 10:15 |
| daf | that's an Alpha | 10:16 |
| BradB | so there are outside users? | 10:16 |
| daf | yes | 10:16 |
| BradB | ok, hm | 10:16 |
| daf | it makes inherent sense for us to dogfood malone, because we need a BTS while doing Launchpad development | 10:18 |
| daf | I'm not sure if Soyuz would be useful to use as Launchpad developers | 10:18 |
| daf | and I'm pretty usre that Rosetta wouldn't be | 10:19 |
| BradB | if our "dogs" include ubuntu developers, then i'd say dogfooding all three makes sense | 10:20 |
| daf | ah, right, that would make more sense | 10:20 |
| daf | but I'd still consider that an alpha (or whatever) rather than a dogfood, because the people using the system aren't the ones developing it | 10:21 |
| BradB | then malone fits as much into that category as anything else ("alpha" not dogfooding :) | 10:22 |
| BradB | because malone isn't designed to be a BTS for malone bugs, it's designed to be a BTS for products and packages | 10:22 |
| BradB | we'd shoehorn it into being a BTS for malone, just to make some use of it, but we won't touch 95% of the most interesting functionality while using it only for malone BT'ing | 10:23 |
| === kiko is now known as kiko-fud | ||
| daf | true | 10:28 |
| BradB | when it comes down to it, i think we need one dev LP instance, one testing LP instance, and one live LP instance; nothing more, nothing less | 10:30 |
| === carlos is back | ||
| carlos | daf: did you finished the tests in my branch? Can I merge it? | 10:36 |
| daf | the functional tests are failing for me now | 10:37 |
| daf | I don't think it's because of your changes | 10:37 |
| daf | but I'd like to be sure | 10:37 |
| carlos | which ones? | 10:37 |
| carlos | I have two fails | 10:37 |
| carlos | but I think they are failing also with rocketfuel's version | 10:37 |
| carlos | BrokenMethodImplementation: The implementation of newSourceSource violates its contract | 10:38 |
| carlos | because implementation requires too many arguments. | 10:38 |
| carlos | and BrokenImplementation: An object has failed to implement interface <InterfaceClass canonical.launchpad.iandrew.IBranch> | 10:38 |
| carlos | The __ne__ attribute was not provided. | 10:38 |
| daf | those are unit test failures | 10:42 |
| carlos | hmmm, I did not saw the "functional" word O:-) | 10:43 |
| daf | spiv: it says a twistd is already running, but the PID it mentions doesn't exist when I check | 10:43 |
| carlos | remember that you need to recreate the database with the schema from my branch | 10:43 |
| spiv | daf: Hmm | 10:43 |
| daf | carlos: good idea O:-) | 10:44 |
| carlos | daf: :-) | 10:44 |
| spiv | daf: I have a potential fix for that in my archive. | 10:44 |
| spiv | Mirroring now. | 10:44 |
| daf | lovely, thanks | 10:45 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Remove small race in authserver ftests (patch-669) | 11:01 |
| ddaa | (20:43:00) daf: and INamespaceObject requires __ne__ | 11:12 |
| ddaa | (20:43:27) SteveA: looks like a bug in code. who owns that code? ddaa? | 11:12 |
| daf | hi ddaa | 11:13 |
| ddaa | It's probably some code dating back to when I first wrote canonical.arch.interfaces | 11:13 |
| ddaa | I do not see why that is a buf. | 11:13 |
| ddaa | * a bug | 11:14 |
| daf | it's a bug because the interface has an __ne__ method | 11:14 |
| daf | and the implementation does not | 11:14 |
| ddaa | Yes, I had trouble defining those... was not sure what was the right way to define operator overloading in interfaces. | 11:14 |
| ddaa | The pyarch implementation has one. That's the only one I wrote. | 11:14 |
| daf | well, should IBranch have an __ne__ method? | 11:15 |
| ddaa | But you can argue that is a misfeature. | 11:15 |
| ddaa | NamespaceObject do equality comparison on their type and their fullname. | 11:16 |
| daf | well, I don't know enough about it to argue | 11:16 |
| daf | what I do know is that a test is failing because of this disparity | 11:16 |
| ddaa | Eventually, the equality relation between objects of the same fullname might turn into an identity relation in pyarch. | 11:17 |
| ddaa | Whether or not that is appropriate to reflect that in launchpad I cannot tell. | 11:17 |
| daf | is there an appropriate short-term solution? | 11:17 |
| daf | e.g. either implement __ne__ in Branch or remove __ne__ from IBranch | 11:17 |
| ddaa | Fix the implementation so the test case passes or modify the interface. I do not really care. | 11:18 |
| ddaa | I think you have to pick one. | 11:18 |
| daf | I think fixing the implementation would be easier | 11:18 |
| daf | because messing with IBranch's inheritance looks sticky | 11:18 |
| ddaa | Some people have been charging me with inheritance abuse. | 11:19 |
| daf | maybe, but as I say, I have neither competence for or interest in arguing that | 11:20 |
| daf | :) | 11:20 |
| ddaa | I threatened to sue back with unit-testual harassment, and we reached an agreement :-) | 11:20 |
| ddaa | daf: at least, you can make the method raise UnimplementedError | 11:21 |
| daf | true | 11:21 |
| spiv | Hah. That's a cop-out. :) | 11:22 |
| ddaa | That will pass until make check run pychecker. | 11:22 |
| daf | it is :-/ | 11:22 |
| ddaa | Which it will certainly do one day. | 11:22 |
| daf | I could also disable the test, but I'd rather not do that :) | 11:23 |
| daf | well | 11:23 |
| daf | is anything actually using __ne__? | 11:23 |
| ddaa | if you have the time, just write the code and a test case for it, and be done with it forever. | 11:23 |
| daf | in any of the interfaces it's defined for? | 11:24 |
| === sabdfl|food is now known as sabdfl | ||
| daf | spiv: any reason why iandrew.py is still around? | 11:26 |
| spiv | No good reason. | 11:28 |
| sabdfl | daf: how does rosetta.w.h.c reset its db? Seems that it's missing a few tables | 11:30 |
| daf | ahem | 11:31 |
| daf | it doesn't reset its db | 11:31 |
| daf | that would appear to be the problem :) | 11:31 |
| carlos | sabdfl: it resets its db when you poke daf to do it :-) | 11:33 |
| daf | createlang: language installation failed: ERROR: permission denied for language c | 11:34 |
| sabdfl | daf: poke :-) | 11:34 |
| daf | ow | 11:34 |
| daf | hmm | 11:34 |
| carlos | :-) | 11:34 |
| sabdfl | this is why i want the dogfood server to be updated every day | 11:34 |
| sabdfl | but you can't have too many "production" instances or it gets a pain | 11:34 |
| daf | yeah, I was supposed to do this | 11:34 |
| daf | mea culpa | 11:34 |
| daf | looks like we have some problem with permissions at the moment, though | 11:35 |
| sabdfl | we can't have rosetta-alpha and separate dogfoods for each lp component and the staging and the production | 11:35 |
| daf | no, that would be silly | 11:35 |
| sabdfl | our bdba would be running around all day | 11:35 |
| daf | also, the diferent apps couldn't share data | 11:35 |
| daf | which means you can't test any integration features | 11:35 |
| daf | sabdfl: I've mailed launchpad about the DB reset problem | 11:40 |
| daf | sabdfl: I'll get a cron job set up to reset it regularly | 11:40 |
| daf | ddaa: did you see my question? | 11:40 |
| ddaa | I did not, I am on the phone. | 11:41 |
| lifeless | ddaa: isn't that uncomfortable ? | 11:52 |
| BradB | sabdfl: What's the pronouncement on the dogfooding then? I think we should have one dev LP, one test LP, and one live LP. | 11:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!