[12:04] BradB: text, not textarea [12:08] sabdfl: i dunno then, because value="" should work fine [12:09] Title: [12:09] not working [12:10] sabdfl: when you view source, are you seeing the value="blah"? [12:10] it works fine for me [12:10] yes, as above [12:10] it might be the collapsing fieldset that causes it [12:17] SteveA: ping [12:44] Merge to rocketfuel@canonical.com/cscvs--devel--1.0: fix default branch enabled changeste creation to merge changsets correctly, and disable aliased cvs repositories temporarily (patch-38) [12:46] still no stub! [12:49] stubless [12:49] SteveA: two things about your tales fix: 1. it breaks when value is an int, 2. it doesn't handle multiple selects (which was the hard-part of trying to shoehorn this in by-hand in tales) [12:49] :) [12:58] BradB: please add to the malone bug the behaviour you want from multiple selects [12:59] making it handle ints is easy enough [12:59] I guess you'd want it to behave nicely in the presence of a sequence object -- that is, match on any element of the sequence [01:00] SteveA: the bug already mentions that this thing should highlight the zero, one, or more values selected. [01:01] well, more specifically "When a user selects one or more of these values, submits the form, and then it's rerendered, I want the values the user selected to be shown as, well, selected in this widget." [01:02] what does the query part of the URL look like in this case? [01:02] or, more to the point, what does request.form look like? [01:04] SteveA: in short: request/htmlform:foo/selected/?value should return True whenever value is a selected value of that field. naturally, for multiple selects that could happen more than once on the same field. [01:04] so, what would you do in python code? [01:05] SteveA: i'm not writing any python code here, so nothing. [01:06] but for request['foo'] where foo is a multiple select, it might be a single value, or a list, depending on how many values are selected. [01:11] nighty [01:16] BradB: okay, looks like I have some code [01:17] phwoar [01:19] SteveA: i can't access this functional with python: either eh? i'm needing that right about now. [01:19] s/functional/functionality/ [01:20] BradB: in your email [01:20] should be faster than tla [01:21] heh [01:22] night all [01:23] see ya tomorrow sabdfl [01:24] BradB: and tomorrow, you'll also see how malone performs with 200,000 bugs in the db :-) [01:24] kthnxbye [01:24] hehe, cool === sabdfl is now known as sabdfl|away [01:25] how's the new code look, brad? [01:28] i'll try it in about 3 minutes, just finishing the another change on these search widgets [01:32] ok, applying now [01:33] er, i have to commit my current changes anyway, i guess, otherwise my diff's get all screwed up [01:34] not really [01:34] I mean, I haven't committed this [01:34] ah, ok [01:34] it is just a few lines of code to one module [01:35] you want me to commit it then? (even still i'll have to first commit my current changes anyway) [01:35] if it works, yes [01:35] ok [01:36] it'll take about 15 mins, at least, unfortunately [01:36] oh? [01:37] by the time i commit these current changes, patch, and get around to testing it [01:37] can't you just apply the patch, and test it now? [01:37] (and, of course, i run make check before committing, because there's no point doing a commit where all the tests don't pass) [01:38] who cares if it is in your own archive? [01:38] of course, make check before submitting a merge to pqm [01:38] SteveA: because it removes the self-containedness of a patch [01:38] but before every commit of your own? sounds a little sadistic to me. [01:39] I'd suggest running a subset of the tests that reflect what you've been working on [01:39] SteveA: as opposed to "oh, grab patch-55 where i added that...oh and patch-57 where i fixed what patch-55 broke) [01:39] the thing is, I need to go to bed very soon, and I'd like to be able to help you out with any problems the code causes you [01:40] ok, i'll patch now, and commit these two things at once [01:40] thanks -- practicality sometimes beats purity ;-) [01:43] seems to work. doing a bit more testing. [01:45] yeah, it seems to work. [01:46] cool [01:46] mail me about any problems, or file them in malone, and I'll look at it tomorrow [01:46] sure, thanks a lot [02:23] daf: event: product assignment edited [02:23] Malone bug #11 closed for package malone: Correct from & errors addresses [02:23] https://launchpad.ubuntu.com/malone/bugs/11 [02:23] Malone bug #9 closed for package malone: What is an "Owner" of a bug? [02:23] https://launchpad.ubuntu.com/malone/bugs/9 [02:24] Malone bug #9 closed for package malone: What is an "Owner" of a bug? [02:24] https://launchpad.ubuntu.com/malone/bugs/9 [02:24] Malone bug #8 closed for package malone: Title *and* summary *and* Description is too much [02:24] https://launchpad.ubuntu.com/malone/bugs/8 [02:24] Malone bug #13 closed for package malone: Comment incorrectly credited to "(none)" [02:24] https://launchpad.ubuntu.com/malone/bugs/13 [02:24] Malone bug #14 closed for package malone: Bug submitter should be automatically subscribed to bug [02:24] https://launchpad.ubuntu.com/malone/bugs/14 [02:24] Malone bug #15 closed for package malone: Title field on bug add form needs to be widened [02:24] https://launchpad.ubuntu.com/malone/bugs/15 [02:24] Malone bug #30 closed for package malone: Comment textarea needs to be larger [02:24] https://launchpad.ubuntu.com/malone/bugs/30 [02:24] Malone bug #33 closed for package malone: Bug subject line should include bug number [02:24] https://launchpad.ubuntu.com/malone/bugs/33 [02:33] does that mean it works? :P [02:33] I think so [02:34] what's with that first line? daf: event: ... [02:35] that was some debugging stuff I forgot to remove :) [02:36] ah, heh [02:47] Malone bug #35 closed for package malone: Person dropdown should be shortened [02:47] https://launchpad.ubuntu.com/malone/bugs/35 [03:39] Merge to rocketfuel@canonical.com/launchpad--devel--0: mostly bug search-related fixes (patch-801) === BradB is now known as BradB|away [09:11] Merge to thelove@canonical.com/bazaar-debian--debian--1.1: branch to the 1.1 version (patch-1) [09:43] anybody know where stub is? === sabdfl|away is now known as sabdfl === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:14] morning all :o) === Kinnison [~dsilvers@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:45] sabdfl: ping === ddaa [~ddaa@deep-thought.xlii.org] has joined #launchpad [11:02] heya people, i'm making *.pyc files in launchpad junk. [11:03] Since it's cache data and it's transparently generated, junk is the right category. [11:03] s/category/class/ [11:04] seems reasonable to me [11:04] Sounds sane. Occasionally people distribute proprietary code as .pyc files, but I doubt we would be touching junk like that. [11:05] stub: you see, that's even the term you use naturally ;-) [11:05] Actually, there is a use case for me when I'm trynig to clean up stuff when changing python version on the same source tree. [11:06] I need to figure out the important compiled stuff that's here. [11:06] Heh [11:07] sabdfl: I'm ready when you are. [11:07] ok === ddaa does the same to zope [11:21] Merge to rocketfuel@canonical.com/launchpad--devel--0: junk *.pyc (patch-802) [11:43] Merge to rocketfuel@canonical.com/buildbot--devel--0: junk *.pyc (patch-68) [11:45] Merge to rocketfuel@canonical.com/pyarch--devel--0.5: junk *.pyc and *.pyo (patch-53) [11:45] stub: who is authorised to merge to zope and sqlobject? [11:45] Just lifeless I believe [11:52] Merge to rocketfuel@canonical.com/sqlos--test--3.0: junk *.pyc and *.pyo (patch-4) [11:52] Ha, looks like he forgot to lock that one down :-) === cprov [~cprov@200.158.100.251] has joined #launchpad [12:14] lifeless: broken taxi again. [12:14] ../lib/importd/Job.py:138:mirrorTarget: exceptions.TypeError, importVersion() takes exactly 4 arguments (3 given) [12:19] Merge to rocketfuel@canonical.com/launchpad--devel--0: Database schema and sample data updates (patch-803) === debonzi [~debonzi@200.158.100.251] has joined #launchpad === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [12:34] morning [12:35] carlos, morning [12:40] carlos: morning, how to run a page test individually in our current tree ? I mean, do you know where is the "pagetest" app refered on pagetests/README ? [12:41] cprov: I don't have any idea, I'm having problems with the tests (as I said yesterday by mail) [12:42] carlos: me too :( [12:43] cprov: I think that's "science fiction" [12:43] can you write such a script? [12:47] SteveA: I think yes .. test on page per shoot should be useful, isn't it ? [12:48] well... [12:48] you'd specify one page, or perhaps a story and page [12:49] if it is just one page, you get just that page [12:49] if you say a story and a page, you get the story up to that page. [12:52] SteveA: I see, the group of pagetests, the story, might be more useful in real cases, just as is described in that README, that "pagetest" is the solution, why did you say it is "science fiction" ? === elmo__ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === elmo__ is now known as elmo === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad [01:35] SteveA: ping [01:36] hello lu [01:36] hey Stevo :o) [01:36] SteveA: Elmo had a chat to me today about our 1.6Gig database. Apparently we need to "pack" it - and save history on a weekly basis. [01:36] cprov: the script to run just one pagetest might be "science fiction" -- that is, it is described well, but doesn't actually exist. [01:36] lulu: um... "pack it and lose history" I think [01:37] that is what packing actually does [01:37] SteveA: yes, but save history for a week? [01:37] and we could have a "button to press" to make this easy for us to do...... [01:37] we can remove history up until one week ago, yes [01:38] ther is a button to press to do this [01:38] but, it should actually be scripted instead [01:38] it will be easy to script once zeo is set up [01:38] SteveA: agreed - automated would be best..... [01:38] if you go to the true root of the site, using gentoo:whateverport/manage [01:39] SteveA: yes... [01:39] then you can click on "control_panel" and then "database" and then choose to pack it [01:39] put "7" in the "number of days of history to keep" place === lulu logs in [01:39] it takes a little while to process [01:39] once you ask it to pack [01:39] the site will still be running, though [01:41] one sec.... [01:45] SteveA: done === Kinnison raises his hand just in case we're having a meeting [01:53] SteveA: ? [01:55] hello carlos [01:55] SteveA: hi [01:55] SteveA: do we have a meeting now? [01:56] oh yeah [01:56] I was so caught up in writing code... [01:56] thanks for the reminder [01:56] let's have a launchpad meeting [01:56] who is here? === carlos is here [01:57] SteveA: ok, backing to the main target, do you think write the famous "pagetest" is useful now, at least for my task, or not ? === stub raises hand [01:58] cprov: it is a different task. [01:59] cprov: your main task is about making the diff output more useful. you can do that without even running a pagetest. Just keep a textfile of actual output and desired output with '...'s, and work on the diffing algorithm [01:59] cprov: I think you're here :-) [01:59] Merge to rocketfuel@canonical.com/launchpad--devel--0: moved tales stuff into webapp (patch-804) [01:59] SteveA: ok, I'll concentrate in "better output" [02:00] daf, debonzi, kiko, Kinnison, sabdfl ? [02:00] cprov: the 'pagetest' script could actually be quite trivial to write if you hack it. It could just call set a magic environment variable and call the main test.py. The test_pages.py script would see the environment variable and only run the specified story. [02:00] hey SteveA [02:00] SteveA, [02:01] BradB|away: ??? [02:02] let's start with rosetta [02:02] stub: maybe, I can't see it quite simple, like you ... but you might be right [02:02] env vars are evil [02:02] SteveA: I've just got lunch [02:02] carlos: how is the "get rosetta on the dogfood system" task going? === Kinnison is chez lunchpad :-) [02:03] SteveA: yesterday, daf imported the users into the dogfood database [02:03] SteveA: I think the remaining task is finish the .pot/.po import from gnome-applets and gnome-panel [02:03] and we are ready to move there [02:03] that is all that needs to happen before we can permanently turn off daf's rosetta alpha server? [02:03] what about changing the virtual hosting configuration? [02:04] I think so, the front page seems to be ready already [02:04] hmmm, not sure [02:04] when can we finish the pot/po import ? [02:04] cprov: It would work and be solid and future proof. Just ugly ;) [02:04] SteveA: it depends on daf, so I don't know. I don't have access to the server so I cannot do anything about it [02:05] where is daf? anyone know? [02:05] don't know [02:06] I just asked mako to pour a bucket of icy water over daf [02:07] meanwhile, how is the rest of rosetta going? [02:07] what work has been done since last week?> [02:07] X-) [02:07] Some UI improvements, code cleanups and functional test rewrites to fix them (I'm on it at this moment) [02:09] what about getting lots more people to use rosetta? [02:09] blocked until the dogfood movement [02:09] that's the big issue as soon as we have the dogfood done [02:09] hi guys [02:10] ok. I see no reason at all we can't have the dogfood stuff done today. Do you carlos, daf? [02:10] how is the password for foo.bar@ in the default database ? [02:10] morning [02:10] cprov: test [02:10] carlos: thanks [02:10] daf, sabdfl: morning [02:10] daf: how is the dogfood project going? carlos says two more things to do: po imports, and virtual hosting. [02:10] SteveA: not sure, daf? [02:10] daf, carlos, any reason not to have rosetta running on dogfood today, as per stevea's question? [02:10] SteveA: I did the user import last night [02:11] so I think everything is ready [02:11] greate [02:11] what about po imports and virtual hosting config? [02:11] everything except for those two things [02:12] how long do po imports take? when can you start? [02:12] are they doable today daf? [02:12] the hosting stuff is pretty easy [02:13] yes, you just need to make sure elmo will be available to do it for you [02:13] I'm pretty sure the imports can be done today too [02:13] I can start this morning [02:13] well, if I give elmo a diff, it should be pretty trivial [02:13] I'd like to see the dogfood stuff totally complete before I finish work today [02:13] so that I can try it out [02:13] Does this affect dogfood rollouts at all? [02:14] stub: don't think so, as there is nothing extra special about rosetta at this point [02:14] no extra external dependencies [02:14] daf, carlos: can you confirm that? [02:15] stub: are all database patches applied to the dogfood server? [02:15] All except the last one, which is being rolled out right now. [02:15] I don't think it affects the other dogfood stuff [02:15] stub: ok [02:15] Who handles the codebase updates? [02:15] ''cos whoever does forgot to restart the librarian last time [02:16] SteveA: If daf thinks it can be done, I agree [02:16] :-) [02:16] Kinnison: That would be me === Kinnison tsks stub :-) [02:16] ok. tomorrow, I want to have a session with daf and carlos to talk about what to do next with rosetta. [02:16] daf, carlos: okay? 12:30 UTC? [02:17] SteveA: it's ok for me [02:17] ok [02:17] as soon as the dogfood stuff is done today, you can get more people using rosetta [02:17] it could be later if it's better for daf [02:18] anything else to ask / report for rosetta? [02:18] ok, next, malone please! [02:18] SteveA: not rosetta specific but I will appreciate an answer to my mail about the tests [02:18] summary of work since last week, current activities, goals for the next week [02:19] carlos: ok [02:19] thanks [02:19] Bradb has made a ton of good improvements [02:19] i've been working on the bug assignment and status reports [02:20] i've got a big refactor of the bugmessage system waiting for stub's approval [02:20] stub, check private msg's [02:20] i'm also setting up the debbugs sync system [02:21] we should be able to test it a little today on zhongshan [02:21] do we have a plan on setting up a bugzilla watch for the launchpad bugzilla? [02:21] stub was to sort out auth for bug watches, or arrange for lp to not require auth from dogfood [02:22] stub: how it that going? [02:22] We need to implement authentication for bugwatches, which will have to be custom coded for each bugsystemtype. [02:23] do you think that's a big job? [02:23] can we get it going as a special case for our bugzilla for now? [02:23] So if someone defines a bugzilla bugsyste, they can enter the username and the password. The checkwatches.py then needs to use that to log in, and propogate the auth credentials to all bugs checked on that tracker [02:23] Coding hasn't started. [02:24] We can special case it, but most of the work is in the checkwatch cron stuff since it needs to know how o log in, and what credentials to propogate. Which involves me or whoever learning more about Bugzilla. [02:25] stub, I've done such systems before, if you need some bugzilla help. [02:26] the only tracker that requires it is our own launchpad bugzilla [02:26] we could just continue to close bugs in there without watches, till the auth stuff is done [02:26] I guess so, as the main point is to test out the watch system, [02:27] kiko: Ta. will do. [02:27] so, there's no point testing out a special case [02:27] we have plenty of watches that will come in from debbugs sync [02:27] sabdfl: So we won't support watches on other systems that require auth? (such as trackers that do it to stop spambots harvesting email addresses?) [02:28] we will in time, i'm just saying we shouldn't think that malone is unusable for our purposes without auth support in watches [02:29] any thoughts on how to allow malone to accept pre-formatted text? such as source code snippets, tracebacks, etc? [02:29] none from me [02:29] i have a similar issue though [02:30] debbugs sync basically means bring in a ton of mail messages [02:30] our message class is *sort of* like an rfc822 message [02:30] but we don't distinguish between headers and body [02:31] since we want email-into-malone, and debbugs sync, we need to make the Message class smarter in the way it displays those messages [02:32] ok, so it becomes a "sensible presentation please" issue, rather than trying to push extra structure into the database [02:32] I sketched out one possibility in the malone bug I opened on this issue. [02:32] number [02:32] ? [02:35] I'd like to point out something I added to TALES for page templates recently, at Brad's suggestion. [02:35] https://launchpad.ubuntu.com/malone/bugs/48 [02:35] Bug 45 [02:35] When you want to do selects or radio buttons or checkboxes in html forms, without using schemas and fields and widgets [02:36] you can use request/htmlform:form_field_name/selected/literalvalue [02:36] or use request/htmlform:form_field_name/selected/?variable_containing_value [02:36] to get the text "selected" if the form_field's value matches a particular value [02:37] Security: I'm starting work on the more flexible security code today. [02:38] this will allow you to use different permissions for different actions on an object, and grant different people those permissions depending on their relationship to an object. [02:38] So, for example, a Bug's owner would get particular rights that another Person wouldn't have. [02:39] Also, I've been slowly moving code out of canonical.lp. So far, most of it has ended up in canonical.launchpad.webapp [02:40] canonical.launchpad.webapp is for the machinery that helps to run launchpad under the hood [02:40] (or bonnet, for speakers of british english) [02:40] Anything more to talk about for malone? [02:41] sourcepacakge selection is crap and ambiguous. I need to talk to the soyuz group to see if it is fixable. [02:41] ok, let's talk about soyuz. [02:41] hello soyuz team [02:41] Hello [02:41] Mainly in that there is no way to reference a unique sourcepackage except by its integer key. [02:42] hey soyuz [02:42] SteveA: hmm, perhaps we can improve the situation for radio buttons also [02:42] daf: you can use "checked" instead of "selected" [02:43] soyuz: what's been happening? what is currently underway? [02:43] mainly cleanups and preparationf or dogfooding [02:44] (and I've myself been a bit hassled taking care of contracts and travel) [02:44] SteveA, one thing that keeps coming up is using the ZODB effectively in some soyuz features -- do we have a status update on how usable that is? [02:45] did salgado get any time with andrew to talk about doap? [02:45] kiko: I need to write up how to do that. I can do that today, as it is a small thing. [02:45] SteveA, thanks. [02:46] I speced with mark yesterday bits about karma that will be going to salgado; apart from that I don't think they spoke much. [02:46] I need to sit down with salgado to get him up-to-speed on what should be done in terms of moving code into FOAF, I've set it down for this afternoon when he comes in (he's still in classes this month) [02:47] ok. we should arrange that salgado and andrew talk on andrew's return, so that we can share the foaf and doap stuff around a bit [02:47] I think I said "doap" earlier when I meant "foaf" [02:47] any other soyuz news? what will happen during the next week? [02:48] Kinnison: how is your stuff going? [02:48] SteveA: I finally got to dump a load of stuff into launchpad over the past week [02:48] SteveA: I'm currently chez sabdfl and we've been discussing the next phase [02:49] I have some plans to rationalise Lucille's views before I get stub to integrate them [02:49] I think I've made too many [02:49] SteveA, essentially taking advantage of kinnison's lucille work and finishing off the malone and rosetta bits. [02:49] Kinnison: I'll throw an ftp server at elmo a bit later, btw [02:49] SteveA: excellent. I'm looking forward to starting on the upload handler === Kinnison has some notes to that effect that were made on the train this morning :-) [02:50] will you be working on that too? [02:50] Unless someone else gets assigned to help me; assume I'll pretty much be writing anything lucille-related [02:50] Kinnison: okay. I'll put it into RF then, under lucille [02:50] elmo has done some work on the upload checking stuff which I will get him to give me; but I think he's mega-busy being our sysadmin so I doubt he'll have much time to help [02:51] SteveA: What does it comprise? Is it just a couple of classes or is it an app or what? [02:51] okay/ [02:51] once Kinnison has uploads and archives working, the next bit is to integrate the build system to LP [02:52] kiko: would be nice to have some more concrete goals for the next week, just to keep me sufficiently pointy-headed ;-) [02:52] Kinnison: goal is to have a fully integrated system running on dogfood by the end of es-conf [02:52] SteveA, yeah, sorry, things have been a bit in flux for me. [02:52] sabdfl: Yep I may have to ask for another pair of hands though [02:52] SteveA: we, me and debonzi, are planning more some infrastructure improve on soyuz for this week, moving classes do launchpad/[db,zcml,browser,etc] [02:52] so i can upload a package to that, watch it build, get it published, see it in the archive [02:52] Kinnison: a couple of modules, depending on a very limited subset of zope3 [02:53] SteveA: lib/canonical/lucille/uploader/*.py then I think would be best [02:53] debonzi: thanks for you help getting things into shape, i appreciate that you are always willing to take on new work! [02:53] you have been great in terms of getting the code base up to spec with newer standards [02:53] sabdfl, thanks :) [02:53] Kinnison: there are hooks to do stuff when a client disconnects. each client gets a fresh uploads directory inaccessible to other clients. [02:53] SteveA: Cool; that was pretty much what elmo said [02:54] I need to iron a few kinks out of it, update elmo's tests, and write some minimal docs === Kinnison nods [02:54] but, it basically works in my sandbox now [02:55] excellent. [02:55] tested with something like dput or dupload? [02:55] no, just plan ftp client [02:55] I'll leave that to you [02:56] There is still an iandrew.py in canonical/launchpad [02:56] it seems to mostly contain pyarch interfaces === SteveA pings ddaa [02:56] yeah? [02:56] wassup? [02:56] be nice if these can be moved, perhaps into canonical/launchpad/interfaces/pyarch.py [02:56] BradB|away, SteveA: we currently can create new users via soyuz, for the record. we're wondering how auth/ will handle this, if at all? [02:56] SteveA: I think you should ask spiv. [02:57] ddaa: there's a file in launchpad called lib/canonical/launchpad/iandrew.py [02:57] does it look like pyarch stuff to you? === ddaa looks [02:57] if so, we should move it into lib/canonical/launchpad/interfaces/pyarch.py, as at least there the name of the module tells you what to expect inside it [02:58] kiko: it doesn't have much to do with creating new users. [02:58] I think it would be interesting to see what is the diff compared to lib/canonical/arch/interfaces.py [02:58] you can protect the ability to create new users by a particular permission [02:58] ha... the interfaces are not here any longer... [02:58] SteveA, that's what I'm talking about. what are our security levels. [02:59] SteveA: in any case, it's massively based on the zope-interface stuff I did a while ago. [02:59] right now, just permissions zope.Public and launchpad.AnyPerson. I'll write more about that once the system is in rocketfuel. [02:59] ddaa: so it is all pyarch stuff? [02:59] I cannot be positive. I don't know what is the delta. [03:00] I do not even know what has become of that interface file I wrote. [03:00] glancing through it, would you give it a "probably mostly pyarch" ? [03:00] I wonder if it is even used... [03:01] ha... actually that _is_ the interface file I wrote I while ago. [03:01] SteveA, thanks. [03:01] if it isn't even used, we should get rid of it from launchpad [03:01] until it is used [03:01] It was renamed in patch-410 on october 1st. [03:02] Then you should ask spiv. I have not been involved in working with that crack for something like 4 months. [03:02] ok, thanks ddaa [03:03] any other business for this launchpad meeting? [03:03] SteveA: it's probably "mostly pyarch", but actually I never quite understood the purpose of that interface file to start with. [03:04] ddaa: i think those are the bits of buttress [03:05] in other words, those are interfaces used for the system to know about all the arch tables in the db [03:05] id like to know who in the arch team is repsonsible for those [03:05] since it's call spiv, I'd say spiv :) [03:05] no [03:05] when we were restructuring, we each created a file iname.py [03:06] then moved classes into our own files [03:06] but it doesn't mean that you knew too much about that subsystem [03:06] the summary of the revision when it was renamed was "Move interfaces and database classes for buttress and librarian." [03:06] then the subsystem owners were supposed to move the classes to interfaces/*.py and database/*.py [03:06] as i understand it you are the owner of the buttress system, right? [03:06] arch-in-launchpad? [03:07] I do not think so. All I did was writing the arch/interfaces.py file a while ago. [03:07] I should be taking ownership of buildbot in the next weeks. [03:08] Frankly I have no idea of the current scope of buttress. [03:08] How urgent is determining the fate of this file? [03:09]