#launchpad 2004-11-01 (dilys/#launchpad) Merge to lauren32@example.com/launchpad--devel--0: fixed regression malone bugs; vastly simplified event handling in the process with multi-subscription adapters. no, seriously. (patch-659) (spiv/#launchpad) Woah, multi-subscription adapters. (spiv/#launchpad) I'm glad that they're actually useful :) <BradB> yep, i just cut out a good 100 lines of code by using them <BradB> and a package <BradB> jblack: you can hammer my machine for a little while now, if you want <jblack> bradb: Thanks <jblack> I HATE OS X <ddaa> jblack: I suggest you mail Apple a request to assign copyright to the FSF :-P <jblack> No. <ddaa> How is the profiling going? <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 <jblack> still trying to compile tla. <ddaa> Frankly macos is the only os around with a half decent user experience... <ddaa> Too bat it's non-free. <ddaa> jblack: getting anywhere? <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. <jblack> Thought I was, but I'm stuck here: cc: Internal error: Bus error (program /usr/libexec/gcc/darwin/ppc/cpp-precomp) <ddaa> Mh... there should be an option to disable precompiled headers somewhere. <ddaa> That's a funky new features they <jblack> is that what it is? <ddaa> paid for, and which dramatically cut their build time, but it obviously was not well tested enough. <ddaa> "cpp-precomp" really sounds something like that has something to do with precompiled headers. <jblack> -no-cpp-precomp (APPLE ONLY) * ddaa is just of out a class yoda-talk <jblack> lets try that with CFLAGS <jblack> I think you're right * jblack hugs ddaa <jblack> ddaa: I don't even need to profile this. <jblack> badb's machine is taking about 3 seconds per unit-pow2-array tests <ddaa> meaning? <jblack> meaning its a really slow, slow machine <ddaa> What model is it? <jblack> how do I know? <ddaa> MacOS X machines do not tend to be slow slow... <ddaa> Ask him... <ddaa> BradB|food: what model is your macintosh? <jblack> let me put it this way. Make test has been running 5 minutes, and its still going <ddaa> Okay, started make test here, on my machine where tla performs reasonably well... <jblack> total wallclock exceeded 6 min <jblack> and make test didn't even pass <ddaa> ho, has tla mv been fixed to behave more like regular mv in 1.2.2rc2? <jblack> not that I remember <ddaa> Wall clock time here 3m50, that does not account for 1hour star-merges. <jblack> wow. Takes me less than a minute <ddaa> I saw the mv test cases, so I was a bit surprised. <ddaa> my machine is a PIII 660 MHz... not exactly today's top of the line. <ddaa> But quite top of the line when I bought it, five years ago. <jblack> First, I'm going to profile library-add rf/lp--d--0--patch-599 * debonzi goes for dinner <BradB|food> ddaa: the machine isn't slow, the filesystem is <jblack> hi elmo, how are you? <BradB|food> ddaa: it's a pb g4, the second most recent 15" <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. <ddaa> BradB|food: duh and what ram do you have? 256M or something? <ddaa> jblack: it's maybe just that gcc sucks. <BradB|food> only 256M, unfortunately <ddaa> BradB|food: what cpu freq. <BradB|food> 867 MHz <ddaa> Laptops have slow disks, having a ton of ram us essential for decent performance. <ddaa> Bah, I'm pretty convinced that the pb is the fs. But what exactly? <BradB|food> does ext3 do zero-filling? <jblack> I doubt it <BradB|food> hfs+ does; apple says that tends to be a bottleneck <ddaa> Like, we might find out that on warm cache stat() is one order of magnitude slower than on reiserfs. <ddaa> What's zero-filling? <BradB|food> ddaa: writing zeros on the unused part of a disk allocated to a given file <ddaa> ??? you mean a part of the disk allocated to the file which is not actually used by the file? <BradB|food> yes <ddaa> What purpose could that serve??? <BradB|food> security, of course <ddaa> Come on... <ddaa> Unused disk space is unused. It's security neutral. * ddaa switches <ddaa> I do not see how that improves security, can you teach me? <sabdfl> guys, we have a bunch of bad commits <sabdfl> def ProductBugAssignmentFactory(context, **kw): <sabdfl> - pba = ProductBugAssignment(bug=context.context.bug, **kw) <sabdfl> - product_assigned = BugAssignedProductAddedEvent( <sabdfl> - Bug.get(context.context.bug), pba) <sabdfl> - notify(product_assigned) <sabdfl> - return pba <sabdfl> + return ProductBugAssignment(bug=context.context.bug, **kw) <sabdfl> this was code that i merged into the file this afternoon <BradB|food> sabdfl: dude, those are good commits. :) <BradB|food> major simplifications. <BradB|food> i undid what i did, because i found a much simpler way to do what i was trying to do with events. <sabdfl> BradB|food: dude, i spent two hours merging your first round of changes <sabdfl> :-/ <BradB|food> ouch. :/ <BradB|food> well, the good news is that i cut out a good 100 lines of code and a package. <BradB|food> i didn't know about "multi-subscription adapters" until jim told me :) <sabdfl> so we both spent hours undoing one another's work :-) <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> <BradB|food> sabdfl: emmm, kind of, but you moved things around. i undid my work. <sabdfl> no worries <sabdfl> i'm relieved it wasn't a tla issue :-) <sabdfl> at least the system works <BradB|food> nope, it's all good. and simplified. <sabdfl> can you teach me about multi-subscription adapters? <BradB|food> sure, to the extent that i understand them. :) <BradB|food> so, basically, the problem to be solved was: "how do i send an email when foo is added to a bug?" <BradB|food> the answer was: events. <BradB|food> the next question became: how do i fire off an event when a foo is added to a bug? <BradB|food> my first answer was to create an IFooAddedEvent <BradB|food> then manually go into the FooFactory, and call notify(some_event_obj) <BradB|food> which was an instance of an IFooAddedEvent <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. <BradB|food> at first, this seems pretty interesting. <BradB|food> but then you realize, crap, there's about 7-8 things that can be added to a bug. :/ <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: <BradB|food> 1. add and IFooAddedEvent. <BradB|food> 2. Create a FooAddedEvent. <sabdfl> ok <BradB|food> 3. Modify the factory to create a FooAddedEvent and notify() <BradB|food> 4. write the handler <BradB|food> 5. configure the ZCML <BradB|food> so, scrap that...multi-subscription adapters! <BradB|food> when an object is added, z3 fires of an ObjectCreatedEvent <BradB|food> so, forget added all those special event interfaces and classes, you can now do something like this in ZCML: <sabdfl> z3? even if the object is an sqlobject? <BradB|food> yes, it doesn't matter <BradB|food> storage is an implementation detail <BradB|food> here's the ZCML magic: <BradB|food> <subscriber <BradB|food> for="canonical.launchpad.interfaces.IBugProductInfestation <BradB|food> zope.app.event.interfaces.IObjectCreatedEvent" <BradB|food> factory="canonical.launchpad.mailnotification.notify_bug_product_infestation_added" /> <BradB|food> this says, "for an IObjectCreatedEvent that happened on an IBugProductInfestation, call notify_bug_product_infestation_added" <BradB|food> so, cool, no more having to create a special event called "IBugProductInfestationAdded" <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) <sabdfl> how does zope know to pass a product to notify_bug_product_infestation_added <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. <BradB|food> well, it passes an bugproductinfestation <BradB|food> s/an/a/ <sabdfl> ok <sabdfl> and that knows it's product <sabdfl> gotcha <BradB|food> yep <ddaa> BradB|food: about explicit tag <ddaa> you should now that they currently make tla actually run more slowly :-) <BradB|food> sabdfl: so when i found this out, i was able to delete the whole events package i had created :) <ddaa> BradB|food: which i undertand is a major concern for you. <BradB> ddaa: They're our policy. <BradB> But that isn't the bottleneck. :) <BradB> sabdfl: haven't quite figured out how i'll figure out what changed on edits though. <sabdfl> ddaa: the alternative is to make the launchpad team run much more slowly :-) <ddaa> sabdfl: yeah... ideally tla <ddaa> rm and tla mv would be sane. <ddaa> But unfortunately that is not an ideal world. <sabdfl> sane? i think they work just fine <ddaa> "tla mv foo bar baz/" works <sabdfl> i dn't think is't sensible to advocate mixing tht revision control system semantics into the actual files <ddaa> if you push explicit tags, people will have to use tla mv/rm anyway. <sabdfl> for example, we are currently serving up HTML that includes arch tags in it <sabdfl> that's not sane <ddaa> So, if they "work just fine" they can handle mixed tagline/explict, and there is not point in using explicit tags. <ddaa> I mean, explicit tags as a policy. <ddaa> It is sure not sane to serve arch-tag in html pages. <BradB> jblack: you're gonna start a fire in my apt, i think. :P <ddaa> sabdfl: the only reason I understand behind that policy is that tla rm/mv would be too broken to handle tagline files transparently. <limi> BradB: he's bouncing on your poor PB? ;) <BradB> bigtime! <limi> BradB: what model is it? <BradB> pb g4, second most recent 15" <sabdfl> ddaa: there's more to it than that <ddaa> I'm sure there is. <jblack> bradb: how so? <jblack> All I did was library-add lauren32@example.com/launchpad--devel--0--patch-599 <jblack> It's up to 93, so its got about 5 hours to go. <BradB> owwwhohowwwewwwch <ddaa> jblack: I believe <ddaa> BradB got burnt... <BradB> :P my fan is going non-stop <jblack> bradb: I really don't see how you can call this a nice machine. :) <BradB> did i call it a nice machine? <BradB> it's arse <BradB> i'm trying to not hate though <jblack> want me to call it quits? <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) <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. <limi> BradB: have you tried UFS? <BradB> no, but i've thought about it * limi suspects HFS+ is really crappy <BradB> yeah, we know that HFS+ sucks :) <limi> BradB: want a repartitioning tool? <limi> so you can test it? <limi> it works really well <BradB> limi: i had that at mark's too :) didn't bother using it. <limi> I used it to make space for Ubuntu <jblack> strub: Nah. Its the nongruntiness I was interested in. <limi> super simple <BradB> i've only got one machine right now; if this thing dies, i'm taking my life with it. <limi> iSync ;) <BradB> iPod mini! <BradB> i've got a backup, but ach, i dunno <limi> or that ;) <limi> BradB: it's pretty much foolproof <jblack> bradb: Actually, as I've chased this down, the ghost has evaporated. <BradB> limi: famous last words! <limi> I can hold your hand over the phone if you want ;) <BradB> i'm not worried about how to use it :) <BradB> i'm worried about murphy's law <limi> I understand <limi> I'm in the same situation <limi> but decided "fuck it, all the important stuff is backed up or in an SVN repo anyway" <stub> BradB: An option might be an external firewire drive (which can double as backup for your life^h^h^h^hosx disk <BradB> stub: Yep, I already have an iPod mini * 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 ;) ) <limi> the Mac can boot from iPod, yes <BradB> stub: heh, that'd be cool <stub> iBuntu :-) <limi> it's pretty nice when you're used to the moronic PC architecture <BradB> hah! <stub> So.... all these events creating emails and whatnot... is this going to cause havoc with writing unit tests? <BradB> with the functional tests, it's to be expected in a way. <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 :-) * stub goes and reads the page test docs <BradB> i'm not using z3's mail machinery right now <BradB> i wrote a little module to be the standard way to send email in LP. canonical.launchpad.mail <sabdfl> lifeless: up? <jblack> I haven't seen him yet. <stub> SteveA: Ping <stub> BradB|away: I'm working on the Z3 transactional email now <lifeless> host lifeless-38.ip6.progsoc.uts.edu.au <lifeless> bah <jblack> Hey lifeless! <jblack> Having fun tonighbt? (dilys/#launchpad) Merge to lauren32@example.com/launchpad--devel--0: Replace stub implementation in mail.py, now using transactional goodness (patch-660) (dilys/#launchpad) New bug 2127 for Launchpad/Launchpad: Simple configuration information (dilys/#launchpad) https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2127 <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. (dilys/#launchpad) Merge to lauren32@example.com/launchpad--devel--0: Mail stuff including stub implementation for development (patch-661) <SteveA> stub: ping <SteveA> stub: pong <stub> I forget <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? * SteveA pings stub to see if he knows <stub> I doubt it <stub> And anything that relies on hardcoded id's is broken <SteveA> stub: see email to mark that I cc-ed you into just now. <stub> SteveA: Any idea which ftesting.zcml is being used? I've stuck deliberate syntax errors into it and nothing complains :-( <SteveA> oh <SteveA> shite <SteveA> that's next on my "make tests better" list then <stub> I suspect that is why a lot of the tests are failing (unable to locate 'Utilities') <SteveA> which tests? <sabdfl> morning all <sabdfl> yesterday i needed to tweak ftesting.zcml in the top directory to get page tests to work <sabdfl> it was including an sql.zcml file from malone or doap that i'd eliminated <sabdfl> stub, maybe that's the cause / solution to your test problem <sabdfl> lifeless: any news on x.org in arch? <sabdfl> and xfree86 too? <stub> sabdfl: Were you getting an error message before you removed the offending line? <stub> SteveA: Don't worry - I think I know what I was doing wrong <sabdfl> stub: yes <sabdfl> i reduced the sql.py to nothing and then removed it from it's local configure.zcml and deleted the file <sabdfl> then the tests all failed, when they had run before when it had nothing in it <sabdfl> turns out the sql.py was being included from ftesting.zcml which was only being used in the tests <sabdfl> so it would run fine, just not test fine <sabdfl> editing ftesting and removing the import of that sql.zcml fixed it <stub> SteveA: Is there a way to use a Unittest test harness like FunctionalTestCase with doctests? <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. <stub> zope/app/tests/test_functional.py <sabdfl> SteveA: any update on the moin / zwiki, and zwiki / preview status? <SteveA> preview is in the latest zwiki <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. <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... <SteveA> although getting him money is a pita <SteveA> morning brad <BradB> hi <SteveA> roche's pointers on doing cacheing look pretty straightforward. what do you think? <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. <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.) <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(). * 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. <SteveA> the main thing I'm concerned about is cacheing pages when someone is logged in <BradB> caching not-logged-in pages is just as much of a problem though <BradB> because it gives the impression that "the plone site just logged me out" :) <sabdfl> SteveA: w.r.t. moin in zwiki <sabdfl> moin tables suck <BradB> and prevents one from doing editing <sabdfl> zwiki already supports html reStructuredText and StructuredText <carlos> morning <sabdfl> what are the tables like in ReST? <lifeless> sabdfl: not yet, will try that this tomorrow <lifeless> I have tarballs from daniels for it though <SteveA> sabdfl: http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables <SteveA> so, similar, but not quite so annoying <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? <SteveA> will do so shortly <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 {} <Kinnison> What's the python idiom? <Kinnison> is it just: <Kinnison> if key not in foo: foo[key] = {} <Kinnison> ? <elmo_> .setdefault <Kinnison> that'd give the same dict to each new key wouldn't it? <SteveA> Please please never use the boolean short-circuit stuff as a short-cut for an "if" statement. <Kinnison> SteveA: okay. It's a common Lua idiom you see :-) <SteveA> Lalo used loads of these in the rosetta code, and they are just so hard to read later. <Kinnison> SteveA: I will use the if statement <SteveA> thanks <SteveA> setdefault is probably the way to go, as elmo says <SteveA> it would give a new dict to each new key <Kinnison> >>> bar={} <Kinnison> >>> bar.setdefault({}) <Kinnison> TypeError: dict objects are unhashable <Kinnison> is that wrong? <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. <SteveA> you can't use a dict object as a key <SteveA> nor a list <SteveA> nor anything mutable <stub> bar.setdefault(key,{}) <SteveA> it must be hashable <Kinnison> oh, gotcha <Kinnison> stub: I see * Kinnison thought it was dict.setdefault(defaultvalue) <SteveA> if you want to store a dict as a key, store tuple(mydict.items()) <Kinnison> and then dict[unknownkey] would autovivify <BradB> perler! * 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? <Kinnison> E.g. is there FooSchema.nameOf(thisvalue) or something? <SteveA> stub: I've looked at the cookies. They're always the same, so open to a replay attack. <stub> Yes - can't avoid that <SteveA> can't use the time as a salt, and reject too old cookies? <Kinnison> http://www.excessus.demon.co.uk/misc-hacks/#cookie <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. <Kinnison> I'm not suggesting you *use* mdw's cookie program; but it's a good place to crib ideas from <SteveA> still, it is better than plaintext. the worst an attacker can do is write crap all over the UL website. <SteveA> they can't easily get the password out to use against launchpad <SteveA> so, I'd be happy to go ahead and use what we have at the moment. <sabdfl> is there a password on this channel? <SteveA> but, it would be nice to put the time in there make only a small window for replays. <stub> nope <sabdfl> limi's not able to get in at the mo <SteveA> limi: ? <SteveA> --> limi (~lauren32@example.com) has joined #launchpad <SteveA> just above stub saying "yes - can't avoid that <SteveA> " <BradB> This would seem to merit an emergency upgrade to plone.org <BradB> (just confirmed that is has the bug, but that's not surprising) <SteveA> plone.org sends plaintext passwords in cookies? <BradB> base64 encoded u:p. <SteveA> wonder if zope.org does too <lifeless> well at least its not plaintext :) <SteveA> let's upgrade to rot13 <BradB> lifeless: heh, might as well be :P * lifeless was trolling <BradB> yeah yeah, i know :P <stub> Hey - CookieCrumber has always worked like that. Its a feature :) * BradB shreaks for having an account on plone.org * lifeless and is tired <BradB> SteveA: yep, zope.org too. shit. <SteveA> hello again limi <limi> Sir Alexander <limi> how's Lithuania? <SteveA> less cold <SteveA> less wet <SteveA> not so bad at the moment <limi> London also has strange weather <limi> sun and stuff ;) <BradB> SteveA: there's a meeting shortly, eh? <SteveA> yes <BradB> d29vaG9v <BradB> (that was "woohoo" in base64) <sabdfl> do we expose dbschema ENUM's to tal in a way that makes it easy to get the value, title and description? <BradB> meeting time? <SteveA> sabdfl: yes. bug/severity/lp:BugSeverity/description or something like that <SteveA> BradB: I need to workrave for a couple of minutes <sabdfl> SteveA: how do i add methods to that object? <sabdfl> #2101 <SteveA> BradB, lulu: I've copied you into an email to Viktorija Zaksiene, about making the cacheing work on the plone site. <BradB> ah, ok, cool <SteveA> BradB: copied you in in case there's changes that need to be made on the filesystem code. <lulu> SteveA: saw that - thanks Stevo. <SteveA> sabdfl: not sure what you want to do. <limi> SteveA: Mark is talking about the shorthand code I need for the portlets * SteveA workraves for 3 mins <limi> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2101 (spiv/#launchpad) Meeting time? <SteveA> in 3 mins, sharp! (spiv/#launchpad) Ok. <SteveA> hi everyone. let's have a lunchpad meeting. * Kinnison raises his hand to indicate presence * spiv is here <SteveA> all present please follow Kinnison's example * SteveA raises hand too <sabdfl> let's go <SteveA> debonzi sends apologies * BradB ready to rock * carlos here too <SteveA> Kinnison needs to leave soon * limi is here <SteveA> Malone -- where are we at? <BradB> we need to: <SteveA> what's been done since last week's meeting? <limi> eek, the dash-dash is creeping into your everyday language, SteveA <BradB> 1. implemented notification on edits <sabdfl> code has been restructured <BradB> 2. implement incoming email <limi> Malone is more sexy! <sabdfl> eye candy <BradB> 3. get a doctest suite that is enough to avoid me spending more time on regression fixes <BradB> 4. fix a bug such that ownerID isn't always set to 1 <sabdfl> several page tests, not as many as doap <sabdfl> BradB: throughout? <limi> first static version of the search/selection widget is in, using dummy data at the moment <BradB> sabdfl: yeah <sabdfl> BradB: great <BradB> that might not be a problem specific to malone either <SteveA> so, you very much need me to fix the page test maker so that it doesn't break so much <SteveA> (I'm working on it) <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 <SteveA> are you doing outgoing email too? <BradB> (and, of course, plone-related stuff) <stub> Hmm.. I had owner working on Bug... so that can be used as a basis for the other objects. <sabdfl> SteveA: instead of running launchpad and the proxy separately, can we have the pagetest script fire them up together? <BradB> SteveA: it's done for things that can be added; it's not done for edits yet. <SteveA> sabdfl: yes, we can <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. <BradB> you mean mailnotification.py? <stub> mail.py <BradB> ah <sabdfl> stub: looked good to me <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 <stub> There is a test harness for email - just trying to get the tests for the testharness working now. <limi> woo, offline mode - will we get MS Exchange support too? :] <stub> Emails just get stored in memory, where the tests can find them trivially <SteveA> great. I also want to make email easily tested via normal pagetests <SteveA> on releasing malone for use... <SteveA> what things are left to do? <BradB> for dogfooding, just testing <BradB> for general release, the four things i mentioned above, plus more testing <BradB> and, of course, deciding on where to put it and who'll deploy it <SteveA> do the rest of the team agree that we can start dogfooding right away? <SteveA> we're going to put is on mawson, right? <sabdfl> yes <SteveA> who will do that? <stub> The ownership bug could cause Mark to get spam atm... <BradB> for dogfooding? i don't think so. <stub> Oh... scratch that comment.. <SteveA> we need to decide on the port it will run on, and get elmo or thom to set up the vhosting appropriately <Kinnison> sabdfl: lucille just created a set of warty overrides which look and smell almost perfect <sabdfl> Kinnison: d29vaG9v! * Kinnison grins <SteveA> BradB: will you be in charge of deploying malone on mawson? * sabdfl wonders how bad overrides really smell <BradB> SteveA: sure <SteveA> thanks <SteveA> start it today? <BradB> SteveA: sure <sabdfl> we can use the bugzilla watch feature to watch older launchpad bugs <SteveA> ok. let's aim to have malone dogfood edition running by the end of (your) today <stub> I can take over my tomorrow if there are still things to do. <limi> Director's Cut <Kinnison> sabdfl: These ones smell like freshly baked bread when you're really hungry <limi> Warts & All <sabdfl> stub: i just realised we probably need need to support authenticated connections to remote bug systems <stub> sabdfl: Tell me about it. The test suite is talking to bugzilla.org because our bugzillas are all protected. <SteveA> can we wrap up the malone part of this meeting shortly? <sabdfl> stub, ok let's discuss oob <SteveA> spiv and Kinnison: soyuz and lucille? <sabdfl> BradB: can we set a systemwide cc for malone emails? <Kinnison> lucille since last week.... <SteveA> in case anyone missed it, spiv is the new doap dealer, and is a friend of foaf <Kinnison> I now have a cleaner dataset wrt. sections <BradB> sabdfl: sure (spiv/#launchpad) SteveA: :) <Kinnison> lucille just completed a perfect publishOverrides() of the warty snapshot I'm working with <Kinnison> There's now a pile of new views and stuff I'm going to ask stub to integrate into the db soon <SteveA> what does that mean? <BradB> sabdfl: it can be hacked in quickly and easily enough, but yeah, we need plenty more UI there for collector-wide config <Kinnison> the overrides tell the tools which build Sources and Packages files how/where to put everything <Kinnison> It's the second-to-last stage in generating apt-gettable archives <SteveA> why is it called an override? <SteveA> (just trying to get my head around it) <Kinnison> It's called an override because it theoretically differs from the values which may be stored in the package itself <sabdfl> SteveA: the joys of Katie naming <SteveA> i see <Kinnison> E.g. the package may say "admin" but we put it in "libs" <sabdfl> i think we should call it DistroPackagePolicy * SteveA points at the glossary <Kinnison> sabdfl: In the db they're just the section columns etc in the Publishing tables <sabdfl> i don't think we should be exporting the overrides terminology to end-user derivatives <BradB> sabdfl, stub: do you guys want to/have more time to test malone today before i put it on mawson? <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 <sabdfl> it should be "Define your package selection policy" <Kinnison> sabdfl: this is outside the scope of lucille currently <sabdfl> dude, i know how this stuff works, the table names bubble up to the UI <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 <Kinnison> the word 'override' only features in the views which lucille uses to pull the data out for the override files <Kinnison> I would hope that the UI will never touch those views <stub> BradB: I was just going to finish of the mail stuff before bed. <sabdfl> Kinnison: sure, but i think, since we are creating the tables, we should call them what we would be happy to expose <sabdfl> Kinnison: it always does though <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? <sabdfl> packagepolicy or something thereabouts please <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 <BradB> stub: ok, i'll do the testing then <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 <sabdfl> thanks <sabdfl> anything else on lucille? <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. <Kinnison> It's been mostly cleaning up and doing the overrides <SteveA> getting lucille in actual use... when where how? <BradB> stub: we are; it's getting set in all the factories <Kinnison> stevea: I need to finish the bits of gina I have floating for making it safe for incremental use <BradB> stub: Either way it's just a query-replace in Emacs. <Kinnison> stevea: then we're clear to use gina to import the archive into launchpad and use lucille to export it again <Kinnison> SteveA: Once I have the apt-gettable bits sorted of course <stub> oic <sabdfl> again, let's use mawson * Kinnison nods. Mawson is a good plan <sabdfl> aim is to have katie managing that warty / hoary archives <sabdfl> and gina running over them constantly to keep mawson's soyuz db up to date * Kinnison nods <sabdfl> then we should be able to publish a "lucille version" of the archives <sabdfl> on mawson * 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 * Kinnison nods <Kinnison> is it okay for me to continue using zhongshan for my experiments? <sabdfl> how the hell we'll cut over from katie to lucille for production i don't know :-) <sabdfl> Kinnison: fine by me <Kinnison> sabdfl: we shouldn't worry about cutting over until lucille can do uploads :-) <sabdfl> sure, and has been well, well tested * Kinnison nods <sabdfl> also, build management <Kinnison> katie may be a bit cranky; but she's very well tested <sabdfl> then we get to the point where maintainers can steer their package through the whole upload / build / deploy process trhough the web * Kinnison nods <sabdfl> at that point we can figure out the transition <SteveA> Kinnison: any rough idea when we'll see this stuff on mawson? <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 <sabdfl> s/overrrides/ packagepolicies/ <sabdfl> that's great progress so far, thanks Kinnison <sabdfl> next? <limi> Rosetta? <SteveA> next, spiv <limi> (if they are here) * SteveA pings carlos and daf for later <limi> ok <sabdfl> spiv: around? <carlos> SteveA: pong (spiv/#launchpad) Ok. <SteveA> spiv: foaf and doap plans? <SteveA> and soyuz status plase (spiv/#launchpad) I'll about to start tackling the doap todo list that sabdfl posted to the list yesterday. (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) <SteveA> what's happening with soyuz? <sabdfl> spiv: do we have a good framework for zopeless access to the db? what's kinnison using? (spiv/#launchpad) I'm relatively out-of-the-loop on soyuz atm. (spiv/#launchpad) sabdfl: We will shortly. <sabdfl> how will it be different to what kinnison is using? <SteveA> I'll catch up with the other soyuz guys a bit later. (spiv/#launchpad) But debonzi has done some good work moving queries out of soyuz/sql.py into the SQLObject classes. <sabdfl> Kinnison seems to have become productive very quickly (spiv/#launchpad) The code is starting to look vaguely neat ;) * Kinnison is using SQLObject stuff wherever possible <Kinnison> the only non SQLObject stuff I've got is in gina <stub> spiv: There is a patch from Lalo that I think is still outstanding. Is that still relevant? (spiv/#launchpad) Kinnison: I'm familiar with what the librarian does, what does lucille do? <Kinnison> I'm currently driving most of my stuff using the db harness (spiv/#launchpad) stub: Yes, that's part of what I've got for lifeless. (spiv/#launchpad) That will probably get merged tomorrow unless lifeless finds more bugs. <Kinnison> spiv: Lucille is the archive management component of soyuz. Her jobs include dealing with uploads, publishing packages to distro archives on disk etc. (spiv/#launchpad) Kinnison: I meant with respect to db access ;) <Kinnison> spiv: Oh; she walks all sorts of tables all over the place and gathers data; etc. * Kinnison ponders which tables lucille currently uses (spiv/#launchpad) Kinnison: SQLObject? <Kinnison> spiv: Oh yes; SQLObject all the way <SteveA> can we move on to rosetta? (spiv/#launchpad) Ok. I'll catch up with Kinnison later. <SteveA> carlos: how is the rosetta alpha going? <carlos> SteveA: well, as I said other times, we are not getting as many input as I thought we could get <SteveA> I wonder why <carlos> I think we should try to push real data in the game so they see it as a real system <SteveA> is it that there aren't the products people want to translate in the system? <sabdfl> carlos: do we have any upstreams that are interested in using the system for their products? <SteveA> we need to make it so that translators can scratch their own itches <carlos> well, we don't have all products imported, only two, <SteveA> we need to do whatever is required to get translators using rosetta, otherwise there's no point having the alpha <carlos> sabdfl: not upstreams as it, but Lliurex, a Debian derivated distributions asked us to implement some features so they could use Rosetta <carlos> for they translation team <sabdfl> ok <carlos> /s/they/their/ <SteveA> have the alpha translators been asked what they'd like to translate? <sabdfl> it's not necessarily the upstream maintainer that needs to like rosetta <sabdfl> it's just somene from theupstream translation team <carlos> SteveA: no, I will talk with daf about it * limi can volunteer the Plone translation team <limi> 40+ languages <carlos> limi: that could be really good <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. <sabdfl> just need one person who can act as a gateway, moving pofile patches between rosetta and upstream <limi> carlos: shoot me a mail about it when you are ready, and I will organize it <carlos> limi: ok, thanks <carlos> sabdfl, SteveA: What about get a small group of translators for Ubuntu? <limi> of course, it will take some time before people *trust* the system, but they should be willing to attempt it <carlos> I have some people at ubuntu-es asking for translate things <sabdfl> carlos: that's great, for things like the installer <sabdfl> carlos: yes, go for it <carlos> ok <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? <limi> "zope3 has been released as a final, I think" - in the neverending series of proofs why Zope Corp's PR sucks :] <carlos> SteveA: ok, added to my list <sabdfl> is there a plan for us to update to zope3? <SteveA> we should continue using snapshots of the trunk for a while yet. <carlos> zope3, plone, ubuntu-installer and any other request from our alpha testers <SteveA> for example, the fix to make debugging traversed things clearer will not be in this zope3 release, but on the trunk <SteveA> it will be in the next zope3 release <SteveA> what's been implemented recently for rosetta? what's the next lot of rosetta work to be done? <carlos> well, the main implementation <carlos> was the msgset split (it's being review by daf) <carlos> after that merge we should not have big code changes <carlos> only bug fixes and missing features implementation <SteveA> carlos: Godefroid Chappelle, zope / plone /zope3 developer from Belgium, is interested in being a rosetta tester. lauren32@example.com <carlos> so I think we could also concentrate on the Beta release, and integration with soyuz <carlos> SteveA: ok, I willl add him to the alpha testers list, thanks <SteveA> let's have a chat about rosetta tomorrow or monday <SteveA> looking at still open bugs, things to implement next <SteveA> we can arrange this when daf shows up <SteveA> Anything more for rosetta? <carlos> only... <carlos> stub: could you review my last database request, please? <carlos> :-) <carlos> that's all <SteveA> Lastly, general launchpad issues. <SteveA> * use tla add not arch-tag: from now on <SteveA> I'll make a checkin soon that will not allow commits that use new arch-tag:s <BradB> * please mail the list when you introduce a new dependency, kthnx <BradB> ;) <SteveA> BradB: are you talking about the python-in-postgres stuff? <sabdfl> especially one that has issues on macosx <sabdfl> apt_pkg <BradB> SteveA: or apt_pkg, or whatever <SteveA> what are we doing about apt_pkg on osx ? <BradB> kiko reported the bug; it won't get fixed anytime soon (realistically speaking) <SteveA> does this have any bad effects on you? <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. :) <BradB> SteveA: it did, but not really anymore. <elmo_> not being funny, but why don't we just specify linux as the development platform? <BradB> elmo_: That was my suggestion. :) <BradB> I confirmed before I started that OS X would be okay, but it turns out that's not true. :) <sabdfl> i have a workaround <sabdfl> asimple stub implementation that we knocked up for limi <sabdfl> def ParseDepends(deptext): <sabdfl> return [[('macosx', '', ''),] ] <sabdfl> same for ParseSrcDepends <BradB> yeah <sabdfl> should basically work <BradB> I'm just setting them to None, and it works fine, because I don't use Soyuz anyway <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 <sabdfl> BradB: that will likely break when they have better page tests <sabdfl> anyhoo <BradB> it used to make the page tests fail, but they pass now, heh heh <SteveA> any other general launchpad things? <SteveA> Can we have the next launchpad meeting on Wednesday next week, 12:00 UTC? <BradB> sure (spiv/#launchpad) Suits me. <SteveA> I'll be on vacation from Thursday. Back on Monday 8th. <Kinnison> Should be fine for me * BradB might be in toronto next week <SteveA> Any other business. If not... <carlos> Wednesday is fine <SteveA> Thanks for your patience. We managed it in under 1 hour this time. <SteveA> I'll summarize this meeting and send to the list for those who were absent. <SteveA> and for those that specially requested a summary, Kinnison * 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? * 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? <carlos> sorry <carlos> :-) <carlos> plone <carlos> O:-) <limi> oh <limi> http://sf.net/projects/plone-i18n <SteveA> aw crap: lib/canonical/browser-exception.zcml 0e25fabf-8d8b-4f3d-a88a-de12fc152573_--> <SteveA> yep -- the closing XML comment is part of the arch id <carlos> limi: thanks <SteveA> there are quite a few of these <SteveA> I'm sort of inclined to remove the arch-tag: and make them have fileids <SteveA> any objections to losing some history from 17 zcml files? (spiv/#launchpad) Not from me. <limi> nope * limi almost removed one yesterday, but didn't have the balls to do it ;) <limi> gotta keep the arch gods happy :] * BradB removed a package yesterday, sprouted a couple more chest hairs <stub> SteveA: I'm messing with the zcml atm - it might cause me merge grief <SteveA> I'm not altering those zcml files right now <SteveA> but, maybe you'd like to? (dilys/#launchpad) Merge to lauren32@example.com/launchpad--devel--0: lucille override publishing work (patch-662) <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) <SteveA> arch tags go on to the end of the line <SteveA> they don't stop after a normal-looking uuid <SteveA> they go to the end of the line, with odd characters (like spaces) turned into underscores. <SteveA> <bob2> it's a semi-bug <stub> Cool... not only do they suck, they are buggy too :-) <SteveA> <ddaa> Tom likes the idea that you can put advertisements/propaganda in ids. <SteveA> <SteveA> argh! <SteveA> <SteveA> that is so fucking lame <SteveA> <SteveA> someone shoot tom <stub> Mmm.... lose file revision history by trimming spurious whitespace from the end of the line, or changing character set encoding even. <ddaa> I am seriously puzzled by what makes you think that taglines suck... <ddaa> Mh. Yeah. They are a bit more dangerous. <stub> Because they make me have to worry about magic id tags, which is the job of the rcs system. <ddaa> stub: in my experience, they do not. <SteveA> stub: can you kill the arch-tags in zcml files please? <SteveA> seeing as you're checking in soon anyway <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. <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. <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. <ddaa> safeguard: prevent commit unless an option is given. * SteveA adds to http://manifesto.gnuarch.org/moin.cgi/ArchWarts <sabdfl> ddaa: (1) the revision control system should be an entirely hidden layer <sabdfl> in other words, my content should be ignorant of the revision control system i am using <ddaa> sabdfl: that's a valid point. <ddaa> That philosophical, but valid, <sabdfl> right now, for example, we are busily trying to convert thousands of files from CVS to Arch <sabdfl> imagine if CVS REQUIRED the presence of some cvs-tag inside the file <ddaa> sabdfl: yeah, I am aware of that :-) <sabdfl> and Arch REQUIRED that you had something else <sabdfl> then we couldn't do that <sabdfl> revision control systems need to be invisible <ddaa> Yup. The REQUIRED part is bad. <sabdfl> .arch-id's may be a poor implementation but they at least meet this criteria <SteveA> I'm somewhat gutted that there is no way of moving from tags inside files to explicit ids, while preserving history. <sabdfl> we can over time improve the implementation and use some other form of database than .arch-id's <sabdfl> which is faster <Kinnison> SteveA: copying the arch tag into the .arch-ids/filefoo doesn't work? <ddaa> I'm not sure that .arch-ids is a bad idea per se. <SteveA> apparently not. <sabdfl> but at least, for the moment, they are correct <sabdfl> (14:57:51) ddaa: Yup. The REQUIRED part is bad. <sabdfl> so that brings me to part (2) <sabdfl> revision control systems should be used consistently for different files <sabdfl> "i tried to move my file but arch doesn't see that it's been moved" <ddaa> sabdfl: good ol' tactic. It's not bad per se efficiency-wise, which is what I was answering. <sabdfl> "did you use tla mv or just mv" (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. <sabdfl> "just mv like I always do" <Kinnison> spiv: oh poo <sabdfl> "it worked for half the files" <sabdfl> "which half?" <sabdfl> "everything except the jpg's" <sabdfl> "oh, the jpgs are different becuase we odn't have arch tags inside them" <sabdfl> "you have to work differently with arch tags" <SteveA> spiv: but, will tla complain if a fileid starts with an i_ ? <sabdfl> the fact that arch allows us to mv a file and preserve history is FANTASTIC <SteveA> spiv: if so, it is treating ids as containing semantics, which is kinda wrong. <sabdfl> it's no hardship to require that, when you do this, you use tla mv <sabdfl> you are requiring consistent behaviour <ddaa> sabdfl: so your point is that the fact "mv" works with tagline is a argument against using them? <sabdfl> yes, exactly (spiv/#launchpad) My understanding is that "tla mv" is supposed to work for both, and the fact it doesn't is a bug. <sabdfl> it's a cute feature that fucks you in the head with users <SteveA> how do people write docs about "arch-tag: " and keep them in arch? turn off the implicit tagging method? <sabdfl> it's a switch that LOOKS easy but requires detailed implementation knowledge (spiv/#launchpad) SteveA: Not put the arch-tag text in the first or last 1k, perhaps ;) <sabdfl> so, Canonical Arch will deprecate this altogether <sabdfl> there's another advantage to this (spiv/#launchpad) http://wiki.gnuarch.org/moin.cgi/ID_2dtagging_20methods has some discussion of this. <sabdfl> if we (a) make .arch-id's the required behaviour for ALL files (spiv/#launchpad) Including "Why I Went From Loving Tagline To Disliking It, by Colin Walters" <sabdfl> (b) remove any mention of .archids's from the documentation, users will forget they exist <sabdfl> and when we come up with a better implementation, users don't need to change or know anything different <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. (spiv/#launchpad) (Out of curiousity, what's the problem with .arch-ids that a different implementation could solve?) <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. <sabdfl> ddaa: that's a bug too <sabdfl> removing a file from the repo should be an explicit action <sabdfl> ddaa: we have a two week arch sprint planned for late november / early december <ddaa> it is an explicit <ddaa> action <Kinnison> As a small-time developer; if Canonical's arch didn't do tagline at all; I wouldn't use it <ddaa> Yeah. Still I think mailing list is the best medium. It gives more time to deep thought. <Kinnison> deprecate it by all-means; but don't prevent it <stub> ddaa: They should have to remove them by hand. arch would bitch during commands and ask them to recover it or forget it. <SteveA> doesn't "deprecate" mean "to be removed in a future version"
{'channel': 'launchpad', 'month': 11}