| sabdfl | BradB: text, not textarea | 12:04 |
|---|---|---|
| BradB | sabdfl: i dunno then, because value="" should work fine | 12:08 |
| sabdfl | <b>Title:</b> <input name="field.title" type="text" size="50" value="Re: Reproduced on AIX" /> | 12:09 |
| sabdfl | not working | 12:09 |
| BradB | sabdfl: when you view source, are you seeing the value="blah"? | 12:10 |
| BradB | it works fine for me | 12:10 |
| sabdfl | yes, as above | 12:10 |
| sabdfl | it might be the collapsing fieldset that causes it | 12:10 |
| BradB | SteveA: ping | 12:17 |
| dilys | 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:44 |
| sabdfl | still no stub! | 12:46 |
| lifeless | stubless | 12:49 |
| BradB | 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 |
| lifeless | :) | 12:49 |
| SteveA | BradB: please add to the malone bug the behaviour you want from multiple selects | 12:58 |
| SteveA | making it handle ints is easy enough | 12:59 |
| SteveA | 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 | 12:59 |
| BradB | SteveA: the bug already mentions that this thing should highlight the zero, one, or more values selected. | 01:00 |
| BradB | 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:01 |
| SteveA | what does the query part of the URL look like in this case? | 01:02 |
| SteveA | or, more to the point, what does request.form look like? | 01:02 |
| BradB | 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 |
| SteveA | so, what would you do in python code? | 01:04 |
| BradB | SteveA: i'm not writing any python code here, so nothing. | 01:05 |
| BradB | 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:06 |
| Kinnison | nighty | 01:11 |
| SteveA | BradB: okay, looks like I have some code | 01:16 |
| sabdfl | phwoar | 01:17 |
| BradB | SteveA: i can't access this functional with python: either eh? i'm needing that right about now. | 01:19 |
| BradB | s/functional/functionality/ | 01:19 |
| SteveA | BradB: in your email | 01:20 |
| SteveA | should be faster than tla | 01:20 |
| BradB | heh | 01:21 |
| sabdfl | night all | 01:22 |
| BradB | see ya tomorrow sabdfl | 01:23 |
| sabdfl | BradB: and tomorrow, you'll also see how malone performs with 200,000 bugs in the db :-) | 01:24 |
| sabdfl | kthnxbye | 01:24 |
| BradB | hehe, cool | 01:24 |
| === sabdfl is now known as sabdfl|away | ||
| SteveA | how's the new code look, brad? | 01:25 |
| BradB | i'll try it in about 3 minutes, just finishing the another change on these search widgets | 01:28 |
| BradB | ok, applying now | 01:32 |
| BradB | er, i have to commit my current changes anyway, i guess, otherwise my diff's get all screwed up | 01:33 |
| SteveA | not really | 01:34 |
| SteveA | I mean, I haven't committed this | 01:34 |
| BradB | ah, ok | 01:34 |
| SteveA | it is just a few lines of code to one module | 01:34 |
| BradB | you want me to commit it then? (even still i'll have to first commit my current changes anyway) | 01:35 |
| SteveA | if it works, yes | 01:35 |
| BradB | ok | 01:35 |
| BradB | it'll take about 15 mins, at least, unfortunately | 01:36 |
| SteveA | oh? | 01:36 |
| BradB | by the time i commit these current changes, patch, and get around to testing it | 01:37 |
| SteveA | can't you just apply the patch, and test it now? | 01:37 |
| BradB | (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:37 |
| SteveA | who cares if it is in your own archive? | 01:38 |
| SteveA | of course, make check before submitting a merge to pqm | 01:38 |
| BradB | SteveA: because it removes the self-containedness of a patch | 01:38 |
| SteveA | but before every commit of your own? sounds a little sadistic to me. | 01:38 |
| SteveA | I'd suggest running a subset of the tests that reflect what you've been working on | 01:39 |
| BradB | 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 |
| SteveA | 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:39 |
| BradB | ok, i'll patch now, and commit these two things at once | 01:40 |
| SteveA | thanks -- practicality sometimes beats purity ;-) | 01:40 |
| BradB | seems to work. doing a bit more testing. | 01:43 |
| BradB | yeah, it seems to work. | 01:45 |
| SteveA | cool | 01:46 |
| SteveA | mail me about any problems, or file them in malone, and I'll look at it tomorrow | 01:46 |
| BradB | sure, thanks a lot | 01:46 |
| dilys | daf: event: product assignment edited | 02:23 |
| dilys | Malone bug #11 closed for package malone: Correct from & errors addresses | 02:23 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/11 | 02:23 |
| dilys | Malone bug #9 closed for package malone: What is an "Owner" of a bug? | 02:23 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/9 | 02:23 |
| dilys | Malone bug #9 closed for package malone: What is an "Owner" of a bug? | 02:24 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/9 | 02:24 |
| dilys | Malone bug #8 closed for package malone: Title *and* summary *and* Description is too much | 02:24 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/8 | 02:24 |
| dilys | Malone bug #13 closed for package malone: Comment incorrectly credited to "(none)" | 02:24 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/13 | 02:24 |
| dilys | Malone bug #14 closed for package malone: Bug submitter should be automatically subscribed to bug | 02:24 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/14 | 02:24 |
| dilys | Malone bug #15 closed for package malone: Title field on bug add form needs to be widened | 02:24 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/15 | 02:24 |
| dilys | Malone bug #30 closed for package malone: Comment textarea needs to be larger | 02:24 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/30 | 02:24 |
| dilys | Malone bug #33 closed for package malone: Bug subject line should include bug number | 02:24 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/33 | 02:24 |
| BradB | does that mean it works? :P | 02:33 |
| daf | I think so | 02:33 |
| BradB | what's with that first line? daf: event: ... | 02:34 |
| daf | that was some debugging stuff I forgot to remove :) | 02:35 |
| BradB | ah, heh | 02:36 |
| dilys | Malone bug #35 closed for package malone: Person dropdown should be shortened | 02:47 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/35 | 02:47 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: mostly bug search-related fixes (patch-801) | 03:39 |
| === BradB is now known as BradB|away | ||
| dilys | Merge to thelove@canonical.com/bazaar-debian--debian--1.1: branch to the 1.1 version (patch-1) | 09:11 |
| sabdfl|away | anybody know where stub is? | 09:43 |
| === 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 | ||
| lulu | morning all :o) | 10:14 |
| === Kinnison [~dsilvers@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad | ||
| stub | sabdfl: ping | 10:45 |
| === ddaa [~ddaa@deep-thought.xlii.org] has joined #launchpad | ||
| ddaa | heya people, i'm making *.pyc files in launchpad junk. | 11:02 |
| ddaa | Since it's cache data and it's transparently generated, junk is the right category. | 11:03 |
| ddaa | s/category/class/ | 11:03 |
| Kinnison | seems reasonable to me | 11:04 |
| stub | Sounds sane. Occasionally people distribute proprietary code as .pyc files, but I doubt we would be touching junk like that. | 11:04 |
| ddaa | stub: you see, that's even the term you use naturally ;-) | 11:05 |
| ddaa | 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:05 |
| ddaa | I need to figure out the important compiled stuff that's here. | 11:06 |
| Kinnison | Heh | 11:06 |
| Kinnison | sabdfl: I'm ready when you are. | 11:07 |
| sabdfl | ok | 11:07 |
| === ddaa does the same to zope | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: junk *.pyc (patch-802) | 11:21 |
| dilys | Merge to rocketfuel@canonical.com/buildbot--devel--0: junk *.pyc (patch-68) | 11:43 |
| dilys | Merge to rocketfuel@canonical.com/pyarch--devel--0.5: junk *.pyc and *.pyo (patch-53) | 11:45 |
| ddaa | stub: who is authorised to merge to zope and sqlobject? | 11:45 |
| stub | Just lifeless I believe | 11:45 |
| dilys | Merge to rocketfuel@canonical.com/sqlos--test--3.0: junk *.pyc and *.pyo (patch-4) | 11:52 |
| ddaa | Ha, looks like he forgot to lock that one down :-) | 11:52 |
| === cprov [~cprov@200.158.100.251] has joined #launchpad | ||
| ddaa | lifeless: broken taxi again. | 12:14 |
| ddaa | ../lib/importd/Job.py:138:mirrorTarget: exceptions.TypeError, importVersion() takes exactly 4 arguments (3 given) | 12:14 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Database schema and sample data updates (patch-803) | 12:19 |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| carlos | morning | 12:34 |
| debonzi | carlos, morning | 12:35 |
| cprov | 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:40 |
| carlos | cprov: I don't have any idea, I'm having problems with the tests (as I said yesterday by mail) | 12:41 |
| cprov | carlos: me too :( | 12:42 |
| SteveA | cprov: I think that's "science fiction" | 12:43 |
| SteveA | can you write such a script? | 12:43 |
| cprov | SteveA: I think yes .. test on page per shoot should be useful, isn't it ? | 12:47 |
| SteveA | well... | 12:48 |
| SteveA | you'd specify one page, or perhaps a story and page | 12:48 |
| SteveA | if it is just one page, you get just that page | 12:49 |
| SteveA | if you say a story and a page, you get the story up to that page. | 12:49 |
| cprov | 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" ? | 12:52 |
| === 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 | ||
| lulu | SteveA: ping | 01:35 |
| SteveA | hello lu | 01:36 |
| lulu | hey Stevo :o) | 01:36 |
| lulu | 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 |
| SteveA | 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 |
| SteveA | lulu: um... "pack it and lose history" I think | 01:36 |
| SteveA | that is what packing actually does | 01:37 |
| lulu | SteveA: yes, but save history for a week? | 01:37 |
| lulu | and we could have a "button to press" to make this easy for us to do...... | 01:37 |
| SteveA | we can remove history up until one week ago, yes | 01:37 |
| SteveA | ther is a button to press to do this | 01:38 |
| SteveA | but, it should actually be scripted instead | 01:38 |
| SteveA | it will be easy to script once zeo is set up | 01:38 |
| lulu | SteveA: agreed - automated would be best..... | 01:38 |
| SteveA | if you go to the true root of the site, using gentoo:whateverport/manage | 01:38 |
| lulu | SteveA: yes... | 01:39 |
| SteveA | then you can click on "control_panel" and then "database" and then choose to pack it | 01:39 |
| SteveA | put "7" in the "number of days of history to keep" place | 01:39 |
| === lulu logs in | ||
| SteveA | it takes a little while to process | 01:39 |
| SteveA | once you ask it to pack | 01:39 |
| SteveA | the site will still be running, though | 01:39 |
| lulu | one sec.... | 01:41 |
| lulu | SteveA: done | 01:45 |
| === Kinnison raises his hand just in case we're having a meeting | ||
| carlos | SteveA: ? | 01:53 |
| SteveA | hello carlos | 01:55 |
| carlos | SteveA: hi | 01:55 |
| carlos | SteveA: do we have a meeting now? | 01:55 |
| SteveA | oh yeah | 01:56 |
| SteveA | I was so caught up in writing code... | 01:56 |
| SteveA | thanks for the reminder | 01:56 |
| SteveA | let's have a launchpad meeting | 01:56 |
| SteveA | who is here? | 01:56 |
| === carlos is here | ||
| cprov | SteveA: ok, backing to the main target, do you think write the famous "pagetest" is useful now, at least for my task, or not ? | 01:57 |
| === stub raises hand | ||
| SteveA | cprov: it is a different task. | 01:58 |
| SteveA | 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 |
| SteveA | cprov: I think you're here :-) | 01:59 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: moved tales stuff into webapp (patch-804) | 01:59 |
| cprov | SteveA: ok, I'll concentrate in "better output" | 01:59 |
| SteveA | daf, debonzi, kiko, Kinnison, sabdfl ? | 02:00 |
| stub | 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 |
| kiko | hey SteveA | 02:00 |
| debonzi | SteveA, | 02:00 |
| SteveA | BradB|away: ??? | 02:01 |
| SteveA | let's start with rosetta | 02:02 |
| cprov | stub: maybe, I can't see it quite simple, like you ... but you might be right | 02:02 |
| SteveA | env vars are evil | 02:02 |
| Kinnison | SteveA: I've just got lunch | 02:02 |
| SteveA | carlos: how is the "get rosetta on the dogfood system" task going? | 02:02 |
| === Kinnison is chez lunchpad :-) | ||
| carlos | SteveA: yesterday, daf imported the users into the dogfood database | 02:03 |
| carlos | SteveA: I think the remaining task is finish the .pot/.po import from gnome-applets and gnome-panel | 02:03 |
| carlos | and we are ready to move there | 02:03 |
| SteveA | that is all that needs to happen before we can permanently turn off daf's rosetta alpha server? | 02:03 |
| SteveA | what about changing the virtual hosting configuration? | 02:03 |
| carlos | I think so, the front page seems to be ready already | 02:04 |
| carlos | hmmm, not sure | 02:04 |
| SteveA | when can we finish the pot/po import ? | 02:04 |
| stub | cprov: It would work and be solid and future proof. Just ugly ;) | 02:04 |
| carlos | 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:04 |
| SteveA | where is daf? anyone know? | 02:05 |
| carlos | don't know | 02:05 |
| SteveA | I just asked mako to pour a bucket of icy water over daf | 02:06 |
| SteveA | meanwhile, how is the rest of rosetta going? | 02:07 |
| SteveA | what work has been done since last week?> | 02:07 |
| carlos | X-) | 02:07 |
| carlos | Some UI improvements, code cleanups and functional test rewrites to fix them (I'm on it at this moment) | 02:07 |
| SteveA | what about getting lots more people to use rosetta? | 02:09 |
| carlos | blocked until the dogfood movement | 02:09 |
| SteveA | that's the big issue as soon as we have the dogfood done | 02:09 |
| sabdfl | hi guys | 02:09 |
| SteveA | ok. I see no reason at all we can't have the dogfood stuff done today. Do you carlos, daf? | 02:10 |
| cprov | how is the password for foo.bar@ in the default database ? | 02:10 |
| daf | morning | 02:10 |
| carlos | cprov: test | 02:10 |
| cprov | carlos: thanks | 02:10 |
| carlos | daf, sabdfl: morning | 02:10 |
| SteveA | daf: how is the dogfood project going? carlos says two more things to do: po imports, and virtual hosting. | 02:10 |
| carlos | SteveA: not sure, daf? | 02:10 |
| sabdfl | daf, carlos, any reason not to have rosetta running on dogfood today, as per stevea's question? | 02:10 |
| daf | SteveA: I did the user import last night | 02:10 |
| daf | so I think everything is ready | 02:11 |
| sabdfl | greate | 02:11 |
| SteveA | what about po imports and virtual hosting config? | 02:11 |
| daf | everything except for those two things | 02:11 |
| SteveA | how long do po imports take? when can you start? | 02:12 |
| sabdfl | are they doable today daf? | 02:12 |
| daf | the hosting stuff is pretty easy | 02:12 |
| SteveA | yes, you just need to make sure elmo will be available to do it for you | 02:13 |
| daf | I'm pretty sure the imports can be done today too | 02:13 |
| daf | I can start this morning | 02:13 |
| daf | well, if I give elmo a diff, it should be pretty trivial | 02:13 |
| SteveA | I'd like to see the dogfood stuff totally complete before I finish work today | 02:13 |
| SteveA | so that I can try it out | 02:13 |
| stub | Does this affect dogfood rollouts at all? | 02:13 |
| SteveA | stub: don't think so, as there is nothing extra special about rosetta at this point | 02:14 |
| SteveA | no extra external dependencies | 02:14 |
| SteveA | daf, carlos: can you confirm that? | 02:14 |
| carlos | stub: are all database patches applied to the dogfood server? | 02:15 |
| stub | All except the last one, which is being rolled out right now. | 02:15 |
| daf | I don't think it affects the other dogfood stuff | 02:15 |
| carlos | stub: ok | 02:15 |
| Kinnison | Who handles the codebase updates? | 02:15 |
| Kinnison | ''cos whoever does forgot to restart the librarian last time | 02:15 |
| carlos | SteveA: If daf thinks it can be done, I agree | 02:16 |
| carlos | :-) | 02:16 |
| stub | Kinnison: That would be me | 02:16 |
| === Kinnison tsks stub :-) | ||
| SteveA | ok. tomorrow, I want to have a session with daf and carlos to talk about what to do next with rosetta. | 02:16 |
| SteveA | daf, carlos: okay? 12:30 UTC? | 02:16 |
| carlos | SteveA: it's ok for me | 02:17 |
| daf | ok | 02:17 |
| SteveA | as soon as the dogfood stuff is done today, you can get more people using rosetta | 02:17 |
| carlos | it could be later if it's better for daf | 02:17 |
| SteveA | anything else to ask / report for rosetta? | 02:18 |
| SteveA | ok, next, malone please! | 02:18 |
| carlos | SteveA: not rosetta specific but I will appreciate an answer to my mail about the tests | 02:18 |
| SteveA | summary of work since last week, current activities, goals for the next week | 02:18 |
| SteveA | carlos: ok | 02:19 |
| carlos | thanks | 02:19 |
| sabdfl | Bradb has made a ton of good improvements | 02:19 |
| sabdfl | i've been working on the bug assignment and status reports | 02:19 |
| sabdfl | i've got a big refactor of the bugmessage system waiting for stub's approval | 02:20 |
| sabdfl | stub, check private msg's | 02:20 |
| sabdfl | i'm also setting up the debbugs sync system | 02:20 |
| sabdfl | we should be able to test it a little today on zhongshan | 02:21 |
| SteveA | do we have a plan on setting up a bugzilla watch for the launchpad bugzilla? | 02:21 |
| sabdfl | stub was to sort out auth for bug watches, or arrange for lp to not require auth from dogfood | 02:21 |
| SteveA | stub: how it that going? | 02:22 |
| stub | We need to implement authentication for bugwatches, which will have to be custom coded for each bugsystemtype. | 02:22 |
| SteveA | do you think that's a big job? | 02:23 |
| SteveA | can we get it going as a special case for our bugzilla for now? | 02:23 |
| stub | 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 |
| stub | Coding hasn't started. | 02:23 |
| stub | 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:24 |
| kiko | stub, I've done such systems before, if you need some bugzilla help. | 02:25 |
| sabdfl | the only tracker that requires it is our own launchpad bugzilla | 02:26 |
| sabdfl | we could just continue to close bugs in there without watches, till the auth stuff is done | 02:26 |
| SteveA | I guess so, as the main point is to test out the watch system, | 02:26 |
| stub | kiko: Ta. will do. | 02:27 |
| SteveA | so, there's no point testing out a special case | 02:27 |
| sabdfl | we have plenty of watches that will come in from debbugs sync | 02:27 |
| stub | 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:27 |
| sabdfl | 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:28 |
| SteveA | any thoughts on how to allow malone to accept pre-formatted text? such as source code snippets, tracebacks, etc? | 02:29 |
| sabdfl | none from me | 02:29 |
| sabdfl | i have a similar issue though | 02:29 |
| sabdfl | debbugs sync basically means bring in a ton of mail messages | 02:30 |
| sabdfl | our message class is *sort of* like an rfc822 message | 02:30 |
| sabdfl | but we don't distinguish between headers and body | 02:30 |
| sabdfl | 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:31 |
| SteveA | ok, so it becomes a "sensible presentation please" issue, rather than trying to push extra structure into the database | 02:32 |
| stub | I sketched out one possibility in the malone bug I opened on this issue. | 02:32 |
| SteveA | number | 02:32 |
| SteveA | ? | 02:32 |
| SteveA | I'd like to point out something I added to TALES for page templates recently, at Brad's suggestion. | 02:35 |
| SteveA | https://launchpad.ubuntu.com/malone/bugs/48 | 02:35 |
| stub | Bug 45 | 02:35 |
| SteveA | When you want to do selects or radio buttons or checkboxes in html forms, without using schemas and fields and widgets | 02:35 |
| SteveA | you can use request/htmlform:form_field_name/selected/literalvalue | 02:36 |
| SteveA | or use request/htmlform:form_field_name/selected/?variable_containing_value | 02:36 |
| SteveA | to get the text "selected" if the form_field's value matches a particular value | 02:36 |
| SteveA | Security: I'm starting work on the more flexible security code today. | 02:37 |
| SteveA | 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 |
| SteveA | So, for example, a Bug's owner would get particular rights that another Person wouldn't have. | 02:38 |
| SteveA | Also, I've been slowly moving code out of canonical.lp. So far, most of it has ended up in canonical.launchpad.webapp | 02:39 |
| SteveA | canonical.launchpad.webapp is for the machinery that helps to run launchpad under the hood | 02:40 |
| SteveA | (or bonnet, for speakers of british english) | 02:40 |
| SteveA | Anything more to talk about for malone? | 02:40 |
| stub | sourcepacakge selection is crap and ambiguous. I need to talk to the soyuz group to see if it is fixable. | 02:41 |
| SteveA | ok, let's talk about soyuz. | 02:41 |
| SteveA | hello soyuz team | 02:41 |
| Kinnison | Hello | 02:41 |
| stub | Mainly in that there is no way to reference a unique sourcepackage except by its integer key. | 02:41 |
| kiko | hey soyuz | 02:42 |
| daf | SteveA: hmm, perhaps we can improve the situation for radio buttons also | 02:42 |
| SteveA | daf: you can use "checked" instead of "selected" | 02:42 |
| SteveA | soyuz: what's been happening? what is currently underway? | 02:43 |
| kiko | mainly cleanups and preparationf or dogfooding | 02:43 |
| kiko | (and I've myself been a bit hassled taking care of contracts and travel) | 02:44 |
| kiko | 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:44 |
| SteveA | did salgado get any time with andrew to talk about doap? | 02:45 |
| SteveA | kiko: I need to write up how to do that. I can do that today, as it is a small thing. | 02:45 |
| kiko | SteveA, thanks. | 02:45 |
| kiko | 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 |
| kiko | 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:46 |
| SteveA | 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 |
| SteveA | I think I said "doap" earlier when I meant "foaf" | 02:47 |
| SteveA | any other soyuz news? what will happen during the next week? | 02:47 |
| SteveA | Kinnison: how is your stuff going? | 02:48 |
| Kinnison | SteveA: I finally got to dump a load of stuff into launchpad over the past week | 02:48 |
| Kinnison | SteveA: I'm currently chez sabdfl and we've been discussing the next phase | 02:48 |
| Kinnison | I have some plans to rationalise Lucille's views before I get stub to integrate them | 02:49 |
| Kinnison | I think I've made too many | 02:49 |
| kiko | SteveA, essentially taking advantage of kinnison's lucille work and finishing off the malone and rosetta bits. | 02:49 |
| SteveA | Kinnison: I'll throw an ftp server at elmo a bit later, btw | 02:49 |
| Kinnison | SteveA: excellent. I'm looking forward to starting on the upload handler | 02:49 |
| === Kinnison has some notes to that effect that were made on the train this morning :-) | ||
| SteveA | will you be working on that too? | 02:50 |
| Kinnison | Unless someone else gets assigned to help me; assume I'll pretty much be writing anything lucille-related | 02:50 |
| SteveA | Kinnison: okay. I'll put it into RF then, under lucille | 02:50 |
| Kinnison | 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:50 |
| Kinnison | SteveA: What does it comprise? Is it just a couple of classes or is it an app or what? | 02:51 |
| SteveA | okay/ | 02:51 |
| sabdfl | once Kinnison has uploads and archives working, the next bit is to integrate the build system to LP | 02:51 |
| SteveA | kiko: would be nice to have some more concrete goals for the next week, just to keep me sufficiently pointy-headed ;-) | 02:52 |
| sabdfl | Kinnison: goal is to have a fully integrated system running on dogfood by the end of es-conf | 02:52 |
| kiko | SteveA, yeah, sorry, things have been a bit in flux for me. | 02:52 |
| Kinnison | sabdfl: Yep I may have to ask for another pair of hands though | 02:52 |
| cprov | 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 |
| sabdfl | so i can upload a package to that, watch it build, get it published, see it in the archive | 02:52 |
| SteveA | Kinnison: a couple of modules, depending on a very limited subset of zope3 | 02:52 |
| Kinnison | SteveA: lib/canonical/lucille/uploader/*.py then I think would be best | 02:53 |
| sabdfl | debonzi: thanks for you help getting things into shape, i appreciate that you are always willing to take on new work! | 02:53 |
| sabdfl | you have been great in terms of getting the code base up to spec with newer standards | 02:53 |
| debonzi | sabdfl, thanks :) | 02:53 |
| SteveA | Kinnison: there are hooks to do stuff when a client disconnects. each client gets a fresh uploads directory inaccessible to other clients. | 02:53 |
| Kinnison | SteveA: Cool; that was pretty much what elmo said | 02:53 |
| SteveA | I need to iron a few kinks out of it, update elmo's tests, and write some minimal docs | 02:54 |
| === Kinnison nods | ||
| SteveA | but, it basically works in my sandbox now | 02:54 |
| Kinnison | excellent. | 02:55 |
| Kinnison | tested with something like dput or dupload? | 02:55 |
| SteveA | no, just plan ftp client | 02:55 |
| SteveA | I'll leave that to you | 02:55 |
| SteveA | There is still an iandrew.py in canonical/launchpad | 02:56 |
| SteveA | it seems to mostly contain pyarch interfaces | 02:56 |
| === SteveA pings ddaa | ||
| ddaa | yeah? | 02:56 |
| ddaa | wassup? | 02:56 |
| SteveA | be nice if these can be moved, perhaps into canonical/launchpad/interfaces/pyarch.py | 02:56 |
| kiko | 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 |
| ddaa | SteveA: I think you should ask spiv. | 02:56 |
| SteveA | ddaa: there's a file in launchpad called lib/canonical/launchpad/iandrew.py | 02:57 |
| SteveA | does it look like pyarch stuff to you? | 02:57 |
| === ddaa looks | ||
| SteveA | 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:57 |
| SteveA | kiko: it doesn't have much to do with creating new users. | 02:58 |
| ddaa | I think it would be interesting to see what is the diff compared to lib/canonical/arch/interfaces.py | 02:58 |
| SteveA | you can protect the ability to create new users by a particular permission | 02:58 |
| ddaa | ha... the interfaces are not here any longer... | 02:58 |
| kiko | SteveA, that's what I'm talking about. what are our security levels. | 02:58 |
| ddaa | SteveA: in any case, it's massively based on the zope-interface stuff I did a while ago. | 02:59 |
| SteveA | right now, just permissions zope.Public and launchpad.AnyPerson. I'll write more about that once the system is in rocketfuel. | 02:59 |
| SteveA | ddaa: so it is all pyarch stuff? | 02:59 |
| ddaa | I cannot be positive. I don't know what is the delta. | 02:59 |
| ddaa | I do not even know what has become of that interface file I wrote. | 03:00 |
| SteveA | glancing through it, would you give it a "probably mostly pyarch" ? | 03:00 |
| SteveA | I wonder if it is even used... | 03:00 |
| ddaa | ha... actually that _is_ the interface file I wrote I while ago. | 03:01 |
| kiko | SteveA, thanks. | 03:01 |
| SteveA | if it isn't even used, we should get rid of it from launchpad | 03:01 |
| SteveA | until it is used | 03:01 |
| ddaa | It was renamed in patch-410 on october 1st. | 03:01 |
| ddaa | Then you should ask spiv. I have not been involved in working with that crack for something like 4 months. | 03:02 |
| SteveA | ok, thanks ddaa | 03:02 |
| SteveA | any other business for this launchpad meeting? | 03:03 |
| ddaa | SteveA: it's probably "mostly pyarch", but actually I never quite understood the purpose of that interface file to start with. | 03:03 |
| sabdfl | ddaa: i think those are the bits of buttress | 03:04 |
| sabdfl | in other words, those are interfaces used for the system to know about all the arch tables in the db | 03:05 |
| sabdfl | id like to know who in the arch team is repsonsible for those | 03:05 |
| ddaa | since it's call spiv, I'd say spiv :) | 03:05 |
| sabdfl | no | 03:05 |
| sabdfl | when we were restructuring, we each created a file iname.py | 03:05 |
| sabdfl | then moved classes into our own files | 03:06 |
| sabdfl | but it doesn't mean that you knew too much about that subsystem | 03:06 |
| ddaa | the summary of the revision when it was renamed was "Move interfaces and database classes for buttress and librarian." | 03:06 |
| sabdfl | then the subsystem owners were supposed to move the classes to interfaces/*.py and database/*.py | 03:06 |
| sabdfl | as i understand it you are the owner of the buttress system, right? | 03:06 |
| sabdfl | arch-in-launchpad? | 03:06 |
| ddaa | I do not think so. All I did was writing the arch/interfaces.py file a while ago. | 03:07 |
| ddaa | I should be taking ownership of buildbot in the next weeks. | 03:07 |
| ddaa | Frankly I have no idea of the current scope of buttress. | 03:08 |
| ddaa | How urgent is determining the fate of this file? | 03:08 |
| sabdfl | this is why buttress is lying in pieces on the floor then | 03:09 |
| sabdfl | nobody has ownership | 03:09 |
| === BradB|away is now known as BradB | ||
| kiko | yeah, I asked about this a while back and nobody was in charge then either. | 03:09 |
| sabdfl | hi BradB | 03:09 |
| BradB | hi | 03:09 |
| sabdfl | we have 4 arch people on the team, one of them will have to take on buttress | 03:09 |
| SteveA | hello brad. can you skip through the log of the meeting, and see if you need to add anything? | 03:09 |
| BradB | argh, sorry, i forgot :( | 03:10 |
| BradB | will definitely catch up though | 03:10 |
| === ddaa greps through the code | ||
| BradB | SteveA: A few to things I would add are: | 03:14 |
| BradB | I'm planning on doing three things today: 1. setting default search criteria, based on the person looking at the page | 03:15 |
| BradB | This means we need to get everyone setup properly as maintainers of their respective products, or they won't see anything by default. | 03:15 |
| BradB | 2. Bug paging. | 03:15 |
| BradB | 3. Smarter notification, namely Cc'ing assignees automatically. | 03:16 |
| BradB | Secondly, that for the code formatting, maybe we could do as I've seen other sites do and break the rules a bit and use <code></code> for multi-line code/traceback snippets (even though the spec says it's meant for partial-line snippets, it might be the most natural thing to use in our case for multi-line) | 03:17 |
| BradB | sabdfl, SteveA, whomever: What do you think? | 03:17 |
| SteveA | how does the message presentation tell when to use <code> </code> around something? | 03:17 |
| ddaa | sabdfl: this stuff is used mainly in the (largely useless) arch/broker.py module | 03:17 |
| SteveA | or do you mean that a person includes that? | 03:17 |
| BradB | SteveA: the user puts it in there. we might have a little note saying "put <code></code> around code snippets" to somehow make it obvious. | 03:18 |
| ddaa | And also in some places in the new database stuff and in cscvs | 03:18 |
| ddaa | Probably, you should also ask "what about arch.broker". | 03:19 |
| SteveA | BradB: as we'll be drawing stuff in from other bug tracking systems, I think we'll need to have some heuristics that understand how these things work in such other systems. | 03:19 |
| SteveA | <code> </code> could be one such heuristi | 03:19 |
| sabdfl | ddaa: what is arch.broker? | 03:19 |
| sabdfl | BradB: i think we need to chat a bit about the reporting pages | 03:19 |
| sabdfl | BradB: we seem to have different ideas of how the system is likely to be used | 03:19 |
| ddaa | Something lifeless had bob2 to write during the last arch sprint, when we were trying to work around the missing database interface. | 03:20 |
| sabdfl | i definitely think a paging system will be very useful | 03:20 |
| ddaa | Mostly stub. | 03:20 |
| ddaa | Not THE stub, stub as in "place holder code". | 03:20 |
| stub | BradB, SteveA: I don't think we should be defining yet-another-markup-language. I'd rather just render everything in a fixed with font preserving whitespace | 03:20 |
| BradB | sabdfl: there's only meant to really be one main "reporting" page, and if anything the current links like "bugs assigned to me", or "bugs i submitted" would be "shortcuts" with the appropriate pre-selected search criteria. heck, we could even give the user custom searches. | 03:20 |
| BradB | stub: YAML? <code></code> is in the spec, at least. | 03:21 |
| stub | (like <pre>, except allowing the browser to break lines) | 03:21 |
| BradB | yeah, basically. | 03:21 |
| SteveA | stub, BradB: if we render it in a fixed-width font, I guess we could use python's textwrap to wrap it at a sensible line length | 03:21 |
| stub | BradB: So we are allowing HTML? Or a subset of HTML? | 03:21 |
| SteveA | and make the original plaintext available at a link if necessary | 03:21 |
| BradB | stub: we'll allow a few tags | 03:22 |
| stub | So we are defining a new spec | 03:22 |
| ddaa | sabdfl: I guess we should discuss the fate of that cruft during the sprint. | 03:22 |
| sabdfl | ddaa: ok | 03:22 |
| BradB | stub: we're defining the tags from the spec you're allowed to use, yeah. | 03:22 |
| stub | How will this interact with incomming and outgoing emails? | 03:23 |
| BradB | stub: the rules will be no different | 03:23 |
| BradB | we might have to special-case lines that start with ">>> ", i dunno. we'll figure some of this out as we go along, no doubt. | 03:24 |
| BradB | stub: but, well, outgoing, i'm not sure. | 03:24 |
| BradB | we could give a choice to the user to have html formatted mail, i suppose. | 03:24 |
| SteveA | I'd like to declare this launchpad meeting officially over. Doesn't mean you have to stop discussing bug formatting though. | 03:24 |
| daf | if you're importing comments from debbugs, you'll have to treat the formatting in those differently, no? | 03:25 |
| stub | The rules are different. Text based email (from developers) is in a monospace font. The system takes that and displays some of it as monospace and some of it as proportional. The outgoing emails are probably the original that was sent. We have two different renderings, and the person sending the email can't see which is used until after the message appears on the web site. | 03:25 |
| Kinnison | sabdfl: same place, dogfood_dump.bz2 | 03:25 |
| stub | If we just use monospace for everything, there is no need for <code> | 03:25 |
| BradB | stub: eeee, that would hurt | 03:25 |
| stub | Why? Email will be monospace anyway, which is what the bulk of messages will be read in. | 03:26 |
| BradB | stub: are you familiar with debian's bug tracking stuff? i'm not, but if it's good, we could just borrow ideas mostly from them. i don't think it's worth spending too much time brainstorming about problems that have already been solved by several other systems. | 03:27 |
| dilys | Malone bug #29 closed for package malone: Make maintainer assignees visible | 03:27 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/29 | 03:27 |
| stub | BradB: I'm not familiar with debbugs. | 03:28 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: More work on functional tests reactivation (patch-805) | 03:28 |
| daf | debbugs just shows emils in a monospace font | 03:29 |
| SteveA | do the simplest thing that works. | 03:29 |
| BradB | that doesn't surprise me. i can't see DD's wanting HTML-formatted email. | 03:29 |
| daf | BradB: quite | 03:29 |
| daf | I agree with Steve | 03:30 |
| BradB | me too, that's why i said i don't want to spend much time on this one. | 03:30 |
| daf | except that linkifying stuff automatically is very useful | 03:30 |
| BradB | maybe pre + textwrap? | 03:30 |
| SteveA | the #NNNN feature of bugzilla is nice | 03:30 |
| daf | yep | 03:30 |
| daf | and http:/... should be turned into <a href="http:/...">http:/...</a> | 03:31 |
| SteveA | I'd like it to read "bug 56" rather than "#56" though | 03:31 |
| daf | except you can't do the strikethrough thing that Bugzilla does, because bugs are never closed, as far as I can tell | 03:31 |
| daf | they just have their package assignements closed | 03:31 |
| stub | BradB: Just do each line as a <pre>, or <code> or <tt> or whatever | 03:33 |
| stub | https://launchpad.ubuntu.com/malone/bugs/45 | 03:33 |
| dilys | New Malone bug #50: "Add an option to comment why we do a status change", submitted by Carlos Perell=C3=B3 Mar=C3=ADn | 03:33 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/50 | 03:33 |
| daf | erk, need to implement quoted-printable decoding | 03:34 |
| carlos | dilys: you need to learn nonascii chars :-) | 03:34 |
| stub | daf: Its all in the email package just waiting for you to use it. | 03:34 |
| daf | stub: yeah? | 03:35 |
| stub | Yup | 03:35 |
| daf | stub: I thought it was elsewhere in the standard library | 03:35 |
| BradB | stub: hm, come to think of it, i don't think we want to break lines for code anyway. | 03:35 |
| BradB | stub: we don't we just allow <pre></pre> around blocks of code and be done with it? | 03:35 |
| daf | stub: also, I've noticed that Malone notification emails contain newlines in the subjects | 03:35 |
| BradB | s/we/why/ | 03:35 |
| stub | daf: Well, if you are hacking it you can just do 'foo'.decode('quopri'). | 03:36 |
| === debonzi -> lunch | ||
| stub | BradB: It seems to much up CSS - someone sends an email without line breaks and it screws up the rendering. Nicer if the browser knows it should break lines I think (my opinion anyway) | 03:37 |
| carlos | SteveA: not sure if you said it already, but I suppose the meeting is over, right? | 03:37 |
| === carlos wants to go to have lunch | ||
| BradB | stub: how does it muck up the CSS if it's only around code blocks anyway? | 03:38 |
| daf | carlos: yes, it's over | 03:38 |
| === kiko is now known as kiko-fud | ||
| carlos | ok | 03:38 |
| carlos | see you later | 03:38 |
| daf | BradB: how do you propose detecting code blocks? | 03:38 |
| BradB | daf: by not doing that. | 03:38 |
| stub | BradB: How do you detect a code block? How do you enforce people to use 80 column windows when editing their source? | 03:38 |
| BradB | daf: the user just puts a <pre></pre> in there. | 03:39 |
| daf | eurgh | 03:39 |
| BradB | stub: you can't enforce sanity. "wrapping" code is equally insane. | 03:39 |
| daf | I suppose that work | 03:39 |
| daf | s | 03:39 |
| BradB | s/enforce sanity/enforce sane coding/ | 03:39 |
| stub | Well, if we are assuming sane code then the lines won't be split anyway because they won't be too long | 03:40 |
| dilys | New Malone bug #50: "Add an option to comment why we do a status change", submitted by Carlos Perell Marn | 03:40 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/50 | 03:40 |
| daf | better | 03:40 |
| sabdfl | nice | 03:40 |
| stub | carlos the trouble maker | 03:40 |
| carlos | daf: thanks :-) | 03:41 |
| BradB | stub: we're assuming occassionally insane code, but that most of the time people don't write 100-column wide code blocks. | 03:41 |
| daf | carlos: no problem :) | 03:41 |
| daf | carlos: thanks for finding my bug | 03:41 |
| carlos | stub: my name is a good UTF-8 betatesting thing :-) | 03:41 |
| stub | Oh - we definitely want to avoid giving HTML tags meaning in messages, because people need to discuss bugs in HTML templates and pages and <pre> is a pretty common string when discussing web development. | 03:42 |
| BradB | stub: are you saying if someone say "yeah so i was using a <pre> tag and blah blah..."? | 03:43 |
| BradB | s,say,says, # still not sufficiently caffeinated | 03:44 |
| stub | Yup. | 03:44 |
| BradB | stub: then they'd escape it, of course :) | 03:44 |
| BradB | that's a non-issue. | 03:44 |
| stub | BradB: It is a major issue. Messages that come in via email cannot be proofed by the end user. | 03:45 |
| daf | I suggest DTSTTW for now, file a bug on fancy formatting later | 03:45 |
| daf | * for later | 03:46 |
| stub | Is that welsh or an acronym? | 03:46 |
| daf | Do The Simplest Thing That Works | 03:46 |
| BradB | stub: i don't think malone is going to support incoming mail for a first the first release anyway, so i still think using <pre> is the simplest thing that works for now. | 03:47 |
| stub | Pre in our template, sure. Not interpreting <pre> in message body though. | 03:48 |
| BradB | stub: you're wanting to auto-detect code then? | 03:49 |
| stub | No - just render the entire thing as <pre>. | 03:49 |
| BradB | ugh :) | 03:50 |
| BradB | that looks horrid though | 03:50 |
| stub | It is all just plain test, and code is no different to ascii tables, bullet lists, whatever | 03:50 |
| BradB | it's hard on the eyes. reading an entire programming text, for example, in fixed-width font, would not be a pleasant thing. | 03:50 |
| BradB | stub: anyway, i have to get on to the three things i mentioned earlier. i'd say either 1. go with my/SteveA/daf's side (i think?) and allow <pre> or 2. do it your way, and see if people accept it. | 03:51 |
| stub | But it doesn't have surprises. The unusal cases (large blocks of documentation) are better catered for using HTML or PDF attachments rather than giving surprising results for the normal situation (people type stuff that looks correct and enter submit) | 03:52 |
| BradB | stub: ok, go for it that way then, if you want to make the change. if malone users don't like it, they'll be sure to let you know. :) | 03:52 |
| stub | Sure. There is a bug open on it, because I didn't want to just go and implement my opinion even though I know it is right ;) | 03:52 |
| daf | BradB: I think I'm with stub here | 03:53 |
| daf | if there's going to be special formatting, it should probably be only if the user explicitly selects it | 03:54 |
| daf | and rather than creating a little Malone-specific markup language, it would be better to use RST or a wiki-like syntax | 03:55 |
| daf | and you also want a preview mode so that users can check their markup is ok | 03:55 |
| daf | so not doing any special formatting is much simpler in the short term | 03:55 |
| stub | Yup. Not sure how to do previews when the message comes in via email, but agree. | 03:56 |
| BradB | sabdfl: got a moment to chat about the bug reporting? | 03:56 |
| sabdfl | BradB: sure | 03:56 |
| BradB | sabdfl: what was your concern? | 03:56 |
| daf | stub: something debbugs does for bug submissions is treating the beginning of the body as an extra set of headers -- Package, Severity, etc. | 03:57 |
| daf | stub: possibly Malone could do something similar for comments | 03:57 |
| sabdfl | the form on the bug listing page... | 03:57 |
| daf | stub: or, just not format email | 03:57 |
| sabdfl | each of those selectors is going to be horribly difficult | 03:58 |
| sabdfl | because that page has no sense of it's own context | 03:58 |
| BradB | sabdfl: what is its context? | 03:59 |
| BradB | i would have thought 1. the defaults come from things we know about the current user and if those aren't good enough 2. we have the most kickass widget (when it's fully implemented) for searching large collections of things so they can easily find something different than what we defaulted to. | 04:00 |
| BradB | Zope 3.1 (i think) will have this thing called "sources" which is meant for huge vocabs. I'm not sure what the scope of sources in Zope 3 are though (i.e. if they'll come with some really cool widget.) This is such a critical thing for all of Launchpad though, that maybe we want to take an active role in that owrk. | 04:01 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: utilities/rocketsync, mirror rocketfuel with rsync (patch-806) | 04:12 |
| === kiko-fud is now known as kiko | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Message display in monospace (patch-807) | 04:50 |
| === cprov [~cprov@200.158.100.251] has joined #launchpad | ||
| BradB | carlos: ever get your test failure sorted out? | 05:08 |
| BradB | carlos: it sounds like a possible bug in LaunchpadFunctionalTestCase. you might want to override setUp and tearDown in your class and throw some pdb.set_trace()'s in there to follow what's going on. | 05:10 |
| carlos | BradB: no I did not got a solution yet | 05:12 |
| carlos | BradB: ok, as soon as I finish my current work I will try to debug it that way | 05:13 |
| carlos | thanks | 05:13 |
| dilys | Merge to rocketfuel@canonical.com/buildbot--devel--0: fix use of taxi.importVersion to pass required logger argument (patch-69) | 05:17 |
| dilys | Malone bug #22 closed for package malone: Bug assignments table bad UI | 05:22 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/22 | 05:22 |
| BradB | stub: so does "Open" mean "someone's working on this"? | 05:23 |
| stub | I think so - Assigned might be a better name for it. | 05:24 |
| stub | Or 'accepted' | 05:25 |
| BradB | I like assigned | 05:25 |
| BradB | It's what Bugzilla uses, and is perhaps the most clear. | 05:25 |
| stub | we can tell assigned by seeing if there is an assignee, so that is almost a second status. | 05:26 |
| stub | At the moment, a bug can be open without having an assignee so it might not be a good idea to use that. | 05:26 |
| BradB | stub: any status that is implicit by having someone assigned though is a second status. we want to have something that marks these as saying "someone's assigned to this bug" so that we can search for the bugs that don't have someone assigned. | 05:27 |
| BradB | what does "Open" mean then? | 05:27 |
| BradB | if it means Accepted, then well... :) | 05:28 |
| stub | At the moment, I'm not sure :-( | 05:28 |
| BradB | why don't we have New, Accepted, Assigned and Closed then? (ugh, I hate Closed, it's so unclear) | 05:29 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Malone polish (patch-808) | 05:29 |
| stub | 'in progress', 'pending', 'deferred' ? | 05:30 |
| BradB | stub: those seem less clear | 05:30 |
| BradB | well, deferred would be an addition to what i proposed. | 05:30 |
| BradB | New, Accepted, Deferred, Assigned and Closed. | 05:30 |
| BradB | New, Accepted, Deferred, Assigned, Fixed, Rejected, perhaps | 05:31 |
| stub | I personally like an 'in progress' indicator, but people rarely use it so I don't know if we can include it | 05:32 |
| stub | That last is sounding good. | 05:32 |
| BradB | I'll make the change and let people holler if it turns out to be unclear. | 05:32 |
| BradB | It can't be worse than what we currently have, that's for sure. | 05:33 |
| stub | sabdfl or the others who speced this might know more about why it is like it currently is. | 05:33 |
| stub | :) | 05:33 |
| BradB | sabdfl: can I go ahead and make this status change? | 05:33 |
| BradB | (for assignments) | 05:33 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Add in checking of upload stuff from James (patch-809) | 05:35 |
| BradB | Open says "This bug has been reviewed and accepted by the maintainer, and is still open." which is recursive. | 05:35 |
| stub | :-) | 05:38 |
| stub | I think we can do without 'Assigned' as a status. Search forms could still list it with the real statuses and allow searching on it if they are trying to save screen real estate | 05:40 |
| stub | Also, it we add 'Accepted' as a status we need to ensure that it can only be set if there is an assignee. We need to think through the workflow implications of adding 'Accepted' (eg. if we implement it as a status, changing the assignee should reset the status to 'open'. This might get annoying if a bug is passed back and forth between two developers, and they just won't bother 'accepting' the bug. Hmm...) | 05:44 |
| BradB | stub: Accepted can be set without an assigned. | 05:45 |
| BradB | Accepted just means the bug was accepted, i.e. "ah yes, this is indeed a bug" | 05:45 |
| stub | Oh... I was thinking the assignee accepted the work | 05:45 |
| stub | :-) | 05:45 |
| BradB | having the assigned status in there leaves no room for confusion | 05:46 |
| stub | Bed time for me I think ;) | 05:46 |
| BradB | there may indeed be some workflow considerations for statuses though, but that doesn't change the need for them | 05:46 |
| stub | Assigned status sounds like 'in progress'. Note that the bug might be assigned to someone when it is 'NEW' to be evaluated, so an 'Assigned' status seems unclear. | 05:48 |
| BradB | it's sort of a six-of-one, half dozen of the other, i guess. | 05:49 |
| BradB | plone's collector uses in-progress, i think, whereas bugzilla uses assigned. | 05:50 |
| stub | Mmm.... I'm tired so I don't get to make any decisions atm ;) | 05:50 |
| stub | I'm sure Mark will have an opinion though ;) | 05:50 |
| BradB | sabdfl: btw, "Quick Searches" like at http://plone.org/collector is what i had in mind for making the assigned and created by reports go away. | 05:54 |
| sabdfl | ok | 05:54 |
| sabdfl | stub: before you crash | 05:55 |
| sabdfl | do you have an answer for me on the bugmesage refactoring? | 05:55 |
| BradB | sabdfl: can i go ahead and change assignment statuses to New, Accepted, Deferred, Assigned, Fixed, and Rejected? | 05:57 |
| sabdfl | no dude | 05:58 |
| === SteveA goes to work in a cafe. too cold at home. | ||
| SteveA | (after a starmerge that is) | 05:59 |
| BradB | sabdfl: the statuses as they are currently are preventing me from getting work done. i want to reject bugs, but i can't. i want to say i fixed a bug, but i can't. | 05:59 |
| stub | sabdfl: Looks fine except you need to reset the DEFAULT value on the Message table's primary key. See archives/patch-2-11-0.sql for an example, or we can work on the patch in the pending directory | 06:00 |
| BradB | sabdfl: and if you asked all 8-10 LP'ers what "Open" on a bug means, you'd almost surely get 8-10 different answers. :) | 06:00 |
| sabdfl | BradB: we spent a lot of time reducing the number of states on bugassignment status | 06:00 |
| sabdfl | malone has states on assignment and infestation | 06:01 |
| BradB | sabdfl: why spend a lot of time on wanting to do that? | 06:01 |
| sabdfl | we will also introduce a state on the bug itself | 06:01 |
| sabdfl | the risk is that we get into the same message that bugzilla is in | 06:01 |
| sabdfl | where there are too many different knobs | 06:01 |
| sabdfl | and people don't know how to use them | 06:01 |
| sabdfl | BradB: because i'm a simplicity fascist | 06:01 |
| sabdfl | so don't go undoing all that good work | 06:02 |
| BradB | sabdfl: so am i :) i'm a usability fascist. i can't help but think about me here, because i'm using malone to try and do my job. | 06:02 |
| daf | sabdfl: I find the fact that a bug doesn't have a status seriously confusing, and I suspect other people will too | 06:02 |
| sabdfl | daf: yes, that's going to be a usability thing we have to work out | 06:02 |
| daf | sabdfl: ok, you're aware of it then | 06:03 |
| sabdfl | what do you mean you don't know how to reject bugs? | 06:03 |
| Kinnison | Are the ftests currently disabled? | 06:03 |
| BradB | sabdfl: the way it's currently setup, an infestation is *required* to fix a bug. | 06:03 |
| sabdfl | no it isn't | 06:03 |
| BradB | sabdfl: yes, it is. because otherwise i have to say it's "Closed", which is not saying that it's "Fixed". | 06:03 |
| sabdfl | right | 06:04 |
| BradB | sabdfl: and our users are saying it's confusing. why are the designers right and the users wrong? | 06:04 |
| sabdfl | the designers accept it's not very usable | 06:04 |
| sabdfl | but the quick fix you are proposing might likely make the situation worse | 06:05 |
| stub | BradB: The 'Closed' vs. 'Fixed' might not be an issue, as there is a priority WONTFIX that can be used to flag bugs that will be open forever. | 06:05 |
| sabdfl | if you want to change the states you'll need to walk me through it carefully | 06:05 |
| sabdfl | right | 06:05 |
| sabdfl | wontfix says "yes this bug is open but i won't fix it" | 06:05 |
| BradB | sabdfl, stub: there needs to be one column that tells me the "health" of this bug. status is it. | 06:06 |
| sabdfl | BradB: i've been toying with the idea of a status on the bug itself | 06:07 |
| sabdfl | but think about it: whatever status is there has to apply to EVERY context where that bug is found | 06:07 |
| sabdfl | upstream, and in all distro's | 06:07 |
| BradB | not upstream, just distros | 06:08 |
| BradB | eeg, brain starting to hurt | 06:09 |
| BradB | i want simple, simple, simple. i don't want to be made to think when it comes to the mindless task of saying "i fixed this" or "nope, sorry dude, this isn't a bug". | 06:10 |
| daf | sabdfl: some bugs are just wrong, and it should be simple to deal with them | 06:10 |
| === BradB thinks | ||
| BradB | i'm just wondering if in fact infestations carry the more pivotal role, and package/product assignments are just things we do in the background, to ensure the bug gets in the relevant maintainer's face. | 06:13 |
| daf | I think the problem lies in the fact that Malone represets related problems in different areas as one bug where other bug systems would represent them as many | 06:14 |
| daf | that's a very clean model | 06:14 |
| daf | but it doesn't make for an easy interface | 06:14 |
| BradB | sabdfl: in response to your earlier comment about how a "Fixed" on an assignment would be problematic because it spans distro releases, well, yes, we want to be able to say that. | 06:17 |
| daf | people like to be able to say "I closed bug #123", even if it's only fixing the problem in one package | 06:18 |
| sabdfl | we have several options | 06:18 |
| BradB | sabdfl: it makes sense to me to say "Fixed" on apache 2.0.52, but also "Fixed" on apache. | 06:18 |
| daf | I can't see people putting "changed status of packageassignment to foo of bug #12345 to closed" in changelogs | 06:18 |
| sabdfl | one way is to come up with a neat way of saying "i closed #123 in ubuntu/firefox[/warty] " | 06:18 |
| sabdfl | the other is to treat each assignment as a distinct # | 06:19 |
| sabdfl | so closing #123 would mean closing an assignment | 06:19 |
| BradB | sabdfl: the first one is what i'm suggested with my status changes. the second suggestion would make my life more difficult (and everytime I say "my" and refer to "me" here WRT usability, i'm really referring to my opinion of what the majority of Malone users will think about it) | 06:20 |
| sabdfl | BradB: you don't need additional statuses for the first | 06:21 |
| BradB | sabdfl: you do, because you need to be able to say "i fixed #123" | 06:21 |
| BradB | sabdfl: or "nope, #123 is not a bug" | 06:21 |
| BradB | sabdfl: or "i'll fix #123, but not yet" | 06:21 |
| sabdfl | "i'l fix #123 but not yet" would be: leave assignment status OPEN set priority LOW | 06:22 |
| sabdfl | "nope #123 is not a bug" would depend, if it's not a bug HERE then close the assignment, if it's not a bug ANYWHERE then close the assignment and MAYBE put something else on the bug status itself | 06:23 |
| sabdfl | "i fixed 123" would be "set bugassignment for 123 to CLOSED" | 06:24 |
| BradB | sabdfl: your solution communicates neither 1. that it was fixed, nor 2. that it was rejected. | 06:24 |
| BradB | sabdfl: If I have a status "Fixed" an an assignment, there can be no misinterpreation of what that means. OTOH, what is the argument /against/ having "Fixed" that is somehow alleviated by only having "Closed"? | 06:25 |
| sabdfl | maybe we can have FIXED and REJECTED | 06:26 |
| sabdfl | so it goes NEW, OPEN, REJECTED and FIXED | 06:26 |
| BradB | can we change OPEN though? i think it communicates very little information. if it means "Accepted" why make the user try and think that one through to arrive at that conclusion, when we could have just called it "Accepted" in the first place? :) | 06:27 |
| BradB | to me, OPEN implies that no decision has been made on this one, e.g. even a decision on whether or not it's a bug. | 06:28 |
| sabdfl | right | 06:29 |
| sabdfl | NEW, ACCEPTED, REJECTED, FIXED | 06:29 |
| BradB | particularly since we have its opposite, REJECTED | 06:29 |
| BradB | ok, cool, that's a good start. | 06:29 |
| BradB | i'll make that change and we can see how users like it. sound good? | 06:29 |
| stub | Just pretty please make sure the numerical representation of 'FIXED' is the same as 'CLOSED', or if you need to change it make sure I do a database patch to update the existing assignments ;) | 06:30 |
| BradB | stub: i'll make it the same. at worst, it's a one-line update anyway. | 06:31 |
| stub | Yer. I just don't want to roll out onto dogfood and reject all our closed bugs ;) | 06:31 |
| BradB | an update may be required actually, since i want them numbered 1-4 in the order sabdfl mentioned above | 06:32 |
| BradB | and Closed is currently 3, i believe | 06:32 |
| BradB | either way, it'll be sorted out | 06:32 |
| stub | ok. Just stick a patch in database/schema/pending (or a rude note) so I don't forget ;) | 06:33 |
| BradB | yes, will do, thanks | 06:33 |
| sabdfl | BradB: i'd like to get the infestation foo working well, before we start to mess more with the model | 06:38 |
| sabdfl | in other words i'd like to see how slick we can make it by integrating properly into the workflow | 06:38 |
| sabdfl | so, for example, we get it so a package upload can tell malone which bugs it fixes, and have it automatically create the "fixed" infestation, and close the assignment | 06:38 |
| sabdfl | i'm happy with the NEW, ACCEPTED, REJECTED, FIXED change, but would like to minimise other state diagram changes | 06:39 |
| BradB | sabdfl: yes, i'm happy to go with that change now, since it allows is to do things we can't currently do and continue to solicit more user feedback. | 06:40 |
| sabdfl | ok | 06:40 |
| sabdfl | don't go 1,2,3,4 | 06:40 |
| BradB | Fixed will be 3, I think. | 06:41 |
| BradB | NAFR | 06:41 |
| sabdfl | i've migrrated other things to 10, 20, 30, 40... | 06:41 |
| BradB | ok | 06:41 |
| sabdfl | so we can more easily add intermediate values in a sensible sort of sort order | 06:41 |
| BradB | stub: ok, so i'll be giving you a migration script :) | 06:41 |
| dilys | New Malone bug #51: "Rosetta translations statistics", submitted by Daniel Debonzi | 06:50 |
| dilys | https://launchpad.ubuntu.com/malone/bugs/51 | 06:50 |
| sabdfl | stub: still around? | 07:01 |
| stub | yup | 07:01 |
| sabdfl | ok, i'm still trying to get a dump of the dogfood db | 07:01 |
| sabdfl | Kinnison has made a few attempts, but I can't import them into my local machine for some reason | 07:01 |
| sabdfl | i really need this today | 07:01 |
| stub | You can't import the dumps directly due to a limitation in PostgreSQL (probably a simple fix, but nobody has bothered. Might be a good bounty). It will fail because it dumps objects in the order they were created, which screws up when column constraints are added after the tables or views altered. | 07:03 |
| stub | To load the dump, you need to change the order that the objects are created by using pg_restore -l and pg_restore -L | 07:04 |
| stub | (pg_restore -l to get a list of stuff in the dump to a file, edit the file, use pg_restore -L to restore using your specified order) | 07:05 |
| stub | There are examples in 'man pg_restore' in the EXAMPLES section | 07:06 |
| stub | Alternatively, do your tests on mawson. Use 'createdb -E UNICODE --template=launchpad_dogfood_20041117 sabdfl_test' to duplicate the database. | 07:07 |
| sabdfl | i need to get the data into my own db so i can massively vchange it and run lp against it | 07:09 |
| sabdfl | stub: please make this easy for me. produce a blob somewhere that i / we can just pqsl -d lp_dev -f xxx | 07:09 |
| stub | Oh - quickest way of doing it in our case is to load trusted.sql into the database before restoring the backup. That should sort out the dependancies (in our case) | 07:11 |
| stub | I'm having net difficulties at the moment (nameservers seem screwed) | 07:12 |
| === BradB is now known as BradB|lunch | ||
| lulu | night all :o) | 07:24 |
| carlos | lulu: night | 07:25 |
| debonzi | lulu, night | 07:25 |
| lulu | night guys :o) | 07:25 |
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] | ||
| carlos | BradB|lunch: the set_trace suggestion does not works, it just breaks the test and I'm not able to debug it | 08:02 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Added support to change the fuzzy flag explicity by the translator. We have now all basic features to translate an application with Rosetta (finally) (patch-810) | 08:19 |
| === Kinnison waves | ||
| carlos | any css specialist around? | 08:27 |
| === BradB|lunch is now known as BradB | ||
| BradB | carlos: I don't get it. What happens when you put a set_trace() in the setUp method of your class exactly? | 08:37 |
| carlos | Error in test testPoExportAdapter (canonical.rosetta.ftests.test_poexport.POExportTestCase) | 08:38 |
| carlos | Traceback (most recent call last): | 08:38 |
| carlos | File "/home/carlos/Work/dists/launchpad/lib/canonical/rosetta/ftests/test_poexport.py", line 156, in setUp | 08:38 |
| carlos | pdb.set_trace() | 08:38 |
| carlos | File "/usr/lib/python2.3/pdb.py", line 992, in set_trace | 08:38 |
| carlos | Pdb().set_trace() | 08:38 |
| carlos | File "/usr/lib/python2.3/bdb.py", line 52, in trace_dispatch | 08:38 |
| carlos | return self.dispatch_return(frame, arg) | 08:38 |
| carlos | File "/usr/lib/python2.3/bdb.py", line 80, in dispatch_return | 08:38 |
| carlos | if self.quitting: raise BdbQuit | 08:38 |
| carlos | BdbQuit | 08:38 |
| carlos | I don't have any chance to debug it, I think it's because the stdin/stdout are not connected to my terminal | 08:39 |
| BradB | carlos: what exactly does your setUp look like? | 08:39 |
| carlos | import pdb | 08:39 |
| carlos | pdb.set_trace() | 08:40 |
| BradB | carlos: oh, hm, maybe it's because when i was doing that, I was running one test at a time or something | 08:40 |
| carlos | and then a call to super | 08:40 |
| carlos | BradB: yes, I suppose that's the difference | 08:40 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Moved rosetta/sql.zcml to the common infrastructure (patch-811) | 09:01 |
| dilys | Bug 1948 resolved: scripts to dump/restore user information from/to Launchpad DB | 09:25 |
| dilys | https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1948 | 09:25 |
| dilys | Bug 1947 resolved: Implement cookie-based authentication for launchpad | 09:28 |
| dilys | https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1947 | 09:28 |
| dilys | Bug 2076 resolved: Login status does not work in public pages | 09:29 |
| dilys | https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2076 | 09:29 |
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| carlos | tv time | 09:31 |
| carlos | later | 09:31 |
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad | ||
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: missed clausetables from malone/bugassignment (patch-812) | 09:41 |
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| BradB | cprov: any news on the pagetest diff fix? | 09:44 |
| BradB | I'm fixing tests that broke from my bug status changes, and with all the false diff output it's hell. | 09:45 |
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| cprov | BradB: sorry, but not yet, I can't see any smart way to handle the returned diff w/o lost information | 09:46 |
| === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad | ||
| cprov | BradB: just parse the data in test_on_merge should be the easiest way, but doesn't produce good results | 09:47 |
| BradB | cprov: test_on_merge has nothing to do with this. It's a bug in the page test thing. | 09:48 |
| cprov | BradB: diff has no option (or I didn't found an appropriated) to help me | 09:48 |
| BradB | cprov: it wouldn't | 09:48 |
| BradB | the key is to chop out stuff like: | 09:49 |
| BradB | -... | 09:49 |
| BradB | +foo | 09:49 |
| BradB | +bar | 09:49 |
| BradB | +baz | 09:49 |
| BradB | i.e. when the *only* expected output was an elision, that's a decoy | 09:49 |
| BradB | which is what i was saying yesterday | 09:49 |
| BradB | cprov: have you written the test for this first? that's probably the best way to get thinking about how to solve the problem. | 09:50 |
| cprov | BradB: the test page works in the correct way verifying the page, i.e., the problem is just the returned output, I think ... | 09:50 |
| BradB | cprov: exactly | 09:50 |
| cprov | BradB: of course I wrote | 09:50 |
| cprov | BradB: the diff output style is problem, may we have better "on-the-fly" info | 09:52 |
| BradB | cprov: i don't get it: what's hard about chopping out the diffs that look like: | 09:52 |
| BradB | -... | 09:52 |
| BradB | +blah | 09:52 |
| BradB | then? | 09:52 |
| cprov | BradB: since <p> ...</p> is different than <b> ... </b>, can you see my point ? | 09:53 |
| === SteveA [~steve@adsl-213-190-44-43.takas.lt] has joined #launchpad | ||
| BradB | cprov: yeah, hm | 10:00 |
| === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad | ||
| debonzi | SteveA, quick question for you :) | 10:01 |
| cprov | BradB: I can't simply "ignore lines w/ PATTERN(..., +blah, +baz", what is also something wierd to do w/ unified diff format | 10:01 |
| debonzi | SteveA, should I move the app component classes from lanchpad/soyuz to somewhere else? | 10:02 |
| debonzi | SteveA, if yes, where? | 10:02 |
| === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad | ||
| SteveA | can you give me an example of what you mean? | 10:03 |
| debonzi | SteveA, yes... I have for exaple DistroReleaseSourceApp that is used as the context inside the zpt | 10:04 |
| debonzi | I have one like this for each soyuz page | 10:05 |
| debonzi | I saw a lot of malone stuff was moved to launchpad/database for example but I don't think this is the place for app components | 10:06 |
| debonzi | Im just trying to follow the standard moving the right things to launchpad/database launchpad/browse launchpad/zcml | 10:07 |
| SteveA | debonzi: I'll take a look in a min | 10:08 |
| debonzi | SteveA, maybe they should be keeped in soyuz directory as it is now but I whould like to have your opnion.. thanks | 10:09 |
| SteveA | well... | 10:12 |
| SteveA | I'm looking at distroapp.py | 10:12 |
| debonzi | right | 10:12 |
| SteveA | there are some unused imports, incidentally | 10:12 |
| debonzi | SteveA, are there? Ill check them | 10:12 |
| SteveA | there is definitely database code in there, in the sense that it is doing ad-hoc selects | 10:13 |
| SteveA | and, that won't get caught by the security stuff | 10:13 |
| SteveA | so, we should refactor these so that they are methods on classes in canonical/launchpad/database | 10:13 |
| SteveA | and then the code in distroapp.py would call those | 10:13 |
| debonzi | SteveA, are you saying that I *can't* have select inside the app component classes ? | 10:14 |
| SteveA | basically, the code should be calling only methods on the interface of the objects it gets in its __init__ method | 10:14 |
| SteveA | or of utilities it gets | 10:14 |
| SteveA | right, you shouldn't have those. a select is database code, so it should be in the database area | 10:15 |
| SteveA | but, the code as a whole is really functioning as an adapter of (for example) a distribution | 10:15 |
| SteveA | I think it might require a bit more thinking and talking to work out what's best to do here | 10:15 |
| SteveA | can we have a meeting about it, say tomorrow, with maybe celso and kiko too? | 10:16 |
| SteveA | then we can all discuss it and decide what's best to do | 10:16 |
| debonzi | SteveA, would be nice as long as we have this kind of things in some other places too | 10:16 |
| debonzi | SteveA, for me its perfect | 10:16 |
| SteveA | what time? I have a rosetta meeting at 12:30 UTC | 10:17 |
| debonzi | after it is to late for you? | 10:17 |
| debonzi | s/to/too | 10:17 |
| SteveA | I am two hours ahead of UTC | 10:17 |
| SteveA | we could say 16:00 UTC, perhaps? | 10:17 |
| SteveA | or 16:30 | 10:18 |
| SteveA | how about 16:30 ? | 10:18 |
| debonzi | For me its ok | 10:18 |
| SteveA | cprov: how about you? | 10:18 |
| cprov | cprov: yes | 10:18 |
| SteveA | ok, great | 10:18 |
| SteveA | please mention to kiko | 10:18 |
| debonzi | SteveA, I will .. thanks a lot | 10:19 |
| SteveA | thanks for bringing this up debonzi | 10:19 |
| SteveA | and, perhaps you can remove the unused imports? | 10:19 |
| SteveA | there is actually a tool to help with this somewhere | 10:20 |
| debonzi | SteveA, yes.. Ill check all of them | 10:20 |
| SteveA | in the zope3 utilities I think | 10:20 |
| SteveA | sourcecode/zope/utilities/importchecker.py | 10:20 |
| debonzi | SteveA, cool :) | 10:20 |
| SteveA | it isn't perfect, but it is helpful | 10:20 |
| cprov | SteveA: any remarks related to zope.app.tests.test ? parsing unified diff format looks crap ...I'm kind of lost on it | 10:26 |
| SteveA | cprov: I'm currently getting the ftp server ready to check in, so I can't look right now | 10:27 |
| cprov | SteveA: ok, let me know when you have time ... tks anyway :) | 10:28 |
| BradB | cprov: what's the name of the z3 method that compares expected to actual? I'm wondering if you can somehow only diff the bits that it says aren't equal, rather than diffing the entire input against the entire output | 10:29 |
| cprov | BradB: I wonder too, it seems to be not z3 ... at least not in zope.app.tests.test, its a great idea | 10:32 |
| SteveA | lib/zope/testing/doctest.py | 10:34 |
| BradB | yeah, was just about to say... | 10:35 |
| cprov | SteveA: difflib ? ok, maybe we can have luck in that way | 10:38 |
| BradB | cprov: i think that the first thing that needs to be done would probably be to make sure there's a little method in the elision-aware machinery that knows how to return *only* the chunks that were truly different. at that point, the problem virtually solves itself. remember though, that elision is just a flag passed to this machinery, so that sometimes a "..." can literally mean a "...", which is why this fix needs to be fairly d | 10:41 |
| BradB | eep in the machinery. | 10:41 |
| === ddaa [~ddaa@deep-thought.xlii.org] has left #launchpad [] | ||
| SteveA | um | 10:45 |
| SteveA | can a '...' literally mean a '...' ? | 10:45 |
| BradB | i believe so | 10:45 |
| SteveA | I mean, sure, '...' will match '...' and also '......' | 10:45 |
| SteveA | and also '.' | 10:45 |
| BradB | "ellipsis": r""" | 10:46 |
| BradB | If the ellipsis flag is used, then '...' can be used to | 10:46 |
| BradB | elide substrings in the desired output: | 10:46 |
| BradB | >>> print range(1000) #doctest: +ELLIPSIS | 10:46 |
| BradB | [0, 1, 2, ..., 999] | 10:46 |
| SteveA | cprov: the first thing I'd do is prepare a text file of sample input, one of comparison input, and one of desired diff output | 10:46 |
| BradB | cprov: he said he's already written the tests | 10:46 |
| SteveA | then write the test that shows what you'd like to happen | 10:46 |
| SteveA | if so, great! | 10:47 |
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| cprov | SteveA: BradB: can it be a real/current (small one) launchpad test ? keeping the things near of our work ? | 10:54 |
| BradB | cprov: basically it comes down to OutputChecker.check_output sucking, I think. | 10:54 |
| BradB | cprov: it should probably just be a few simple five line examples, demonstrating in an easy-to-digest way the edge cases that are proven to behave correctly. | 10:55 |
| cprov | BradB: I think too | 10:55 |
| cprov | BradB: ok | 10:56 |
| cprov | BradB: I need to go ... if you have some other idea, please write an email to me | 10:58 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: added ftp server. added annotation-in-zodb support. (patch-813) | 11:14 |
| SteveA | >>> from canonical.launchpad.interfaces import IZODBAnnotation | 11:24 |
| SteveA | >>> IZODBAnnotation(some_bug)['soyuz.todolist'] = "Here is my todo list for some_bug" | 11:24 |
| SteveA | >>> del IZODBAnnotation(some_bug)['soyuz.todolist'] | 11:25 |
| SteveA | >>> 'soyuz.todolist' in IZODBAnnotation(some_bug) | 11:25 |
| SteveA | False | 11:25 |
| SteveA | >>> IZODBAnnotation(some_bug).get('soyuz.todolist') | 11:26 |
| SteveA | None | 11:26 |
| SteveA | >>> IZODBAnnotation(some_bug)['soyuz.todolist'] = "Here is my todo list for some_bug" | 11:26 |
| SteveA | >>> print IZODBAnnotation(some_bug)['soyuz.todolist'] | 11:26 |
| SteveA | "Here is my todo list for some_bug" | 11:26 |
| SteveA | 11:26 | |
| === SteveA notes that the soyuz team is not here | ||
| === SteveA goes to bed | ||
| BradB | hm, why do we want to store that in the ZDOB? | 11:35 |
| BradB | ZODB even | 11:35 |
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| === elmo [~james@george.kkhotels.co.uk] has joined #launchpad | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!