[00:04]  * thumper afk for a bit
[08:23] <poolie> hi all
[08:24] <poolie> how do i run a single launchpad test?  i thought there was a test.py script
[08:26] <mwhudson> poolie: ./bin/test is that script now
[08:27] <poolie> that doesn't seem to exist
[08:29] <poolie> ah it's now a generated file
[08:29] <poolie> or maybe it has been for a long time
[08:31] <poolie> mwhudson, when I try to run make i get a complaint about missing download-cache
[08:31] <poolie> and when i run link-external-sourcecode, that complains the egg directory is missing
[08:31] <poolie> how do i fix that?
[08:32] <mwhudson> poolie: have you read ./utilities/rocketfuel-setup?
[08:32] <mwhudson> or even run it, if you're adventurous
[08:33] <poolie> i thought i had but perhaps not
[08:33] <poolie> i might try rocketfuel-update
[08:34] <mwhudson> well, if you don't have download-cache either you never set up this tree fully or it's a very long time since you last used it
[08:35] <poolie> ah ok
[08:35] <poolie> i have it in another branch
[08:35] <poolie> i guess if i'd used rocketfuel-branch or something it would have been copied?
[08:35] <mwhudson> oh you should be able to use link-external-sourcecode then
[08:36] <poolie> another question if i may
[08:36] <poolie> bzr-svn doesn't seem to be in launchpad-dependencies
[08:36] <mwhudson> maybe you need to give it an argument like ./utilities/link-external-sourcecode ../trunk
[08:36] <poolie> shouldn't it be?
[08:36] <poolie> oh ok
[08:36] <mwhudson> poolie: no, we use a branch of bzr-svn in sourcecode
[08:36] <mwhudson> we tend to use a newer version than anything packaged (or released, for that matter)
[08:36] <poolie> ok
[08:38] <poolie> ok, and now i have that directory, but i get 'no such file or directory' on an egg when i run make and it runs bootstrap.py
[08:38] <poolie> is there something else i need to run first?
[08:39] <mwhudson> not that i can think of
[08:39] <mwhudson> poolie: pastebin the error?
[08:39] <poolie> http://pastebin.ubuntu.com/438700/
[08:40] <mwhudson> poolie: maybe bzr update download-cache?
[08:41] <poolie> ah, i didn't know that was a branch
[08:41] <mwhudson> yeah it is, for all that that isn't a very good idea
[08:55] <poolie> mwhudson, that seems to be running now, thanks
[09:02] <poolie> mwhudson, and is bzr-builder supposed to come from a branch too? i get an import error about that
[09:03] <mwhudson> poolie: ./utilities/update-sourcecode
[09:03] <poolie> k
[09:18] <poolie> jeez you wouldn't want to be in a hurry
[09:19] <poolie> spm, mwhudson, is this outage known
[09:50] <poolie> yay, my test fails
[09:50] <poolie> ok good night
[09:52] <lifeless> night
[11:03] <deryck> Morning, all.
[12:47] <wgrant> deryck: Why not have a root +filebug which just has a unified project/distro search widget and redirects to the right +filebug?
[12:47] <wgrant> That will redirect to the right Ubuntu wiki page, removes the widget complexity, and removes the bad Ubuntu default.
[12:47] <wgrant> And makes everyone happy.
[12:49] <deryck> wgrant, I suppose that's a better version of what was there before.  But is that really *that* much quicker than just searching for the project?
[12:52] <wgrant> deryck: You can't search for projects.
[12:53] <wgrant> At least without using the generic search widget on the top of another page.
[12:53] <wgrant> Yes, it would be awesome if everybody just landed on the project page.
[12:53] <wgrant> That's clearly how the current UI was designed.
[12:53] <wgrant> But it's not how things happen.
[12:53] <wgrant> And this sort of page would be generically useful, across several applications.
[12:54] <wgrant> (and the unified project/distro search widget itself even more widely applicable)
[12:56] <deryck> wgrant, then let's open a new bug about that suggestion.  The original bug was about one-click search.
[12:58] <wgrant> deryck: I do not see the difference. The workflow here is 1) Go to bugs.launchpad.net. 2) Click "Report a bug". 3) Enter search terms. 4) Click on match. This jumps into the workflow that is currently reached with 1) Go to launchpad.net/fooproject. 2) Click "Report a bug".
[12:59] <deryck> wgrant, ok, I thought you were saying something different.  I would not be in favor of that.  That isn't too far off what was there before.  People still have to know what project to file against, and if they don't, they will file against Ubuntu.
[13:00] <wgrant> deryck: Why would they file against Ubuntu?
[13:00] <wgrant> They did so before because it was the default.
[13:00] <wgrant> If you ignored the form, you got Ubuntu.
[13:01] <wgrant> With my design (based rather strongly on the design of the AJAX pickers), there is no default.
[13:01] <wgrant> And if somebody does enter Ubuntu, they will simply be redirected to the usual wiki page.
[13:04] <deryck> wgrant, ah, I see what you mean now.  I don't think technically we could do a text search like what's on the current dupe search across all bugs and not timeout 100% of the time.  But I'm fine to entertain the idea of the feature.
[13:04] <wgrant> deryck: The plan was not to do a dupe search at that stage.
[13:05] <wgrant> Users would select the project or distro, sending them to the normal +filebug for that target.
[13:05] <deryck> wgrant, so why is this any better than just searching from bugs.launchpad.net now?  because it has the semblance of a guided filebug workflow?
[13:05] <wgrant> deryck: You can't search from bugs.launchpad.net.
[13:05] <wgrant> And yes, a guided workflow is approximately an awful lot easier.
[13:06] <wgrant> If you don't provide guided workflows, you end up like Launchpad.
[13:06] <deryck> wgrant, you can't search?  there is a big "Search bug reports" form at the top of bugs.lp.net, no?
[13:07] <wgrant> deryck: The desired functionality is to search for *projects*, not bugs.
[13:07] <deryck> wgrant, are you personally planning to work on this?
[13:08] <wgrant> deryck: No.
[13:08] <wgrant> I'm just saying that Won't Fixing every bug about it is silly.
[13:08] <wgrant> Because it's a valid concern.
[13:08] <wgrant> And I've seen it confuse lots of users.
[13:09] <wgrant> And once the widely useful widget exists, this view is trivial.
[13:09] <deryck> wgrant, ok, first, you're being a bit too dramatic.  I haven't Won't Fix'ed *every* bug, I've marked one bug this way.
[13:09] <wgrant> deryck: There have been one or two before.
[13:10] <deryck> wgrant, that I have marked won't fix?
[13:12] <wgrant> Bug #162271 comes to mind.
[13:12] <mup> Bug #162271: search results page doesn't offer link to report a bug <ui> <Launchpad Bugs:Won't Fix> <https://launchpad.net/bugs/162271>
[13:13] <wgrant> And it comes up on IRC every so often.
[13:14] <deryck> wgrant, fine.  Update the bug with your suggestions and I'll mark it low.  You win.
[13:15] <wgrant> Since you seem to feel strongly that I am wrong, I shall not.
[13:17] <deryck> wgrant, I don't feel that your suggestion is bad.  I feel that this bug is not worth fixing.  I marked the bug as such, and you're challenging my call on that bug.  I can only mark the bug in front of me.  Had you opened a different bug making your suggestion, I doubt very seriously I would have marked it won't fix....
[13:17] <wgrant> Hmmmmm.
[13:18] <deryck> wgrant, and I'm saying now if you update the bug with your suggestions, I'll change my mind on the bug.
[13:18] <wgrant> "Not worth fixing": by that rationale, shouldn't most Low bugs need Won't Fxing?
[13:18] <wgrant> I understand Won't Fix as a policy decision that a change is inappropriate.
[13:18] <wgrant> That is how it tends to be used normally.
[13:18] <wgrant> Although not its original intention.
[13:19] <deryck> wgrant, so my language is not accurate.  I mean "should not be fixed."  by "worth," I only meant the fix suggested (i.e. renable reporting from the top-level) is not worth the pain it causes.
[13:20] <deryck> wgrant, I marked it won't fix because if someone submitted a patch to re-enable reporting from the top-level page, we would not accept it.
[13:21] <deryck> wgrant, and your alternate suggestion is fine, but it's a feature request, not a bug.  And trying to salvage the bug into a feature request is fair enough, and maybe that's why I used the phrase "not worth it" thinking about the whole spectrum of this bug to feature discussion.
[13:21] <wgrant> But not all solutions to that bug revive the Ubuntu issue. That was indeed a big issue, but it is easy to leave resolved.
[13:25] <deryck> wgrant, so why not propose an alternate solution in the bug report, rather than taking me to task from my call on this bug?
[13:27] <wgrant> deryck: I'd not intended to take you to task; I started by merely asking why other potential solutions were not considered. It seemed at the time to be a better idea to check before polluting a nice clean bug on which you had made a policy decision.
[13:32] <deryck> wgrant, if changing the status of a bug turns it from clean to dirty then we might as well quit reporting bugs.
[13:32] <deryck> or triaging them
[13:32] <deryck> or working on launchpad altogether
[13:34] <wgrant> deryck: I knew it was probably to end with the idea being crushed and the bug flipped back to Won't Fix. I imagined that a couple of lines of discussion here would remove the need for such useless operations. As can be seen, I was quite wrong.
[13:53]  * jml out to lunch
[17:45] <adiroiban> leonardr: hi. Do you know how could I debug the lazr.restful when the error  is  ComponentLookupError ? http://paste.ubuntu.com/438961/
[17:50] <leonardr> adiroiban: it looks like the web service is trying to serialize a field where the field object doesn't exist?
[17:50] <leonardr> as if you had put foo = exported(None) in your interface instead of eg. foo = exported(Text)
[17:50] <leonardr> does that make any sense?
[17:51] <leonardr> if i were you i'd catch the exception in _unmarshallField and see what field it is
[17:51] <adiroiban> leonardr: thanks. but is there a way for finding how which field can not be serialized?
[17:51] <leonardr> adiroiban -^
[17:51] <adiroiban> leonardr: thanks. so there is no other way of finding out which field is raising this error?
[17:52] <leonardr> adiroiban: ordinarily you would get a clue from the first part of the component lookup--that would be the field object
[17:52] <leonardr> but here the field object is None
[17:55] <adiroiban> thanks!
[18:13] <adiroiban> leonardr: it looks like the error was caused by an exported(List) field http://paste.ubuntu.com/438968/
[18:13] <adiroiban> Do you think it would make sense to have this patch http://paste.ubuntu.com/438969/ ?
[18:22] <leonardr> adiroiban: when publishing a list through the web service, you need to use Collection, not List
[18:22] <leonardr> let me find you an example
[18:22] <leonardr>     bugtasks = exported(
[18:22] <leonardr>         CollectionField(
[18:22] <leonardr>             title=_('BugTasks on this bug, sorted upstream, then '
[18:22] <leonardr>                     'ubuntu, then other distroseriess.'),
[18:22] <leonardr>             value_type=Reference(schema=IBugTask),
[18:22] <leonardr>             readonly=True),
[18:22] <leonardr>         exported_as='bug_tasks')
[18:22] <leonardr> from lib/lp/bugs/interfaces/bug.py
[18:22] <leonardr> lazr.restful.fields.CollectionField
[18:23] <leonardr> the semantics of a List field are undefined in the web service
[18:23] <leonardr> same thing for Object -- if you want to relate one object to another you need to use Reference
[18:24] <adiroiban> yes. and replace IChoice with IReferenceChoice ... but I was puzzled by that „None” field name
[18:25] <leonardr> i think lazr.restful may have been looking up a deserializer for the .schema
[18:25] <leonardr> since oyu didn't have a .schema that was None
[18:25] <adiroiban> and I was asking if you think that lazr.restfull could be improved and give a better error message
[18:25] <leonardr> sure it can
[18:25] <leonardr> ah, sorry
[18:25] <leonardr> i was looking at the wrong paste
[21:55] <mtaylor> thumper: hey, up yet?
[21:55] <thumper> mtaylor: hey
[21:55] <thumper> mtaylor: up but need some food
[21:56] <thumper> mtaylor: a somewhat frustrating morning
[21:56] <mtaylor> thumper: no prob... I'm here all day :)
[21:56] <mtaylor> oh, that's no good
[21:56] <mtaylor> you should eat! eating makes it better
[21:56]  * thumper nods
[21:56] <mtaylor> (so does coffee for me, but not everyone is as obsessed as I am)
[21:56]  * thumper goes to make some bacon and egg muffins with espresso
[21:57] <mtaylor> mmm
[22:17] <thumper> mtaylor: you've got me one handed for a few minutes while I eat
[22:17] <thumper> whazzup?
[22:18] <lifeless> nom nom nomification
[22:23] <mtaylor> thumper: so, an unnamed organization I know of is going to be hosting some open source development on launchpad
[22:23] <mtaylor> thumper: and amongst the things entailed in that process are going to be a CLA
[22:23] <thumper> mtaylor: ok
[22:23] <thumper> CLA?
[22:24] <mtaylor> contributor license agreement
[22:24] <mtaylor> which is one of those "need to sign this form before you can contribute" sorts of thing
[22:25]  * thumper nods
[22:25] <mtaylor> I was trying to figure out if/how that process could be integrated into launchpad
[22:25] <thumper> well, it is something we've been talking about in the past
[22:25] <mtaylor> which made me think of the (currently one-off hardcoded) ubuntu code of conduct
[22:25] <thumper> but I'm not entirely up with the play
[22:25] <thumper> ask sinzui
[22:25] <lifeless> o
[22:25] <lifeless> so
[22:25] <lifeless> lp has the CoC for Ubuntu
[22:26] <sinzui> mtaylor, CoC is a flatfile with a table mapping the version signed
[22:26] <lifeless> I *think* that a generalisation of that, to make multiple cocs available might be a reasonable thing
[22:26] <mtaylor> lifeless: that was the real question - I'm happy to write the code for that, if it's something that people might be interested in
[22:26] <lifeless> but I *don't know* if the concept of scaling to 1-per-project would be expected ;)
[22:27] <lifeless> sinzui: ^
[22:27] <lifeless> or even N per project, because Ubuntu related projects have several cocs to choose from
[22:27] <sinzui> mtaylor, The model classes assume that all CoC are Ubuntu. I considered adding a naming convention test to permit multiple CoCs for canonical projects.
[22:28] <lifeless> (oroginal, rev 2, leadership)
[22:28] <sinzui> mtaylor, I think we need a real DB class to manage file content and versions if we let any project have a CoC
[22:28] <mtaylor> sinzui: yes. I believe adding them as flat-files with mapping would be the wrong way
[22:28] <lifeless> sinzui: is there any reason, in principle, not to accept a patch that does that to your standard ?
[22:29] <lifeless> rephrasing:- Would a patch that generalises this and makes it editable via the web UI for all open source projects be accepted [if of appropriate quality]
[22:29] <sinzui> lifeless, mtaylor we would love patches to improve CoC to support more than Ubuntu
[22:29] <lifeless> mtaylor: there you go
[22:30] <mtaylor> sinzui: awesome! I will write up some thoughts on how I might go about that and see what you think
[22:30] <sinzui> thanks
[22:43] <mtaylor> sinzui: how soon would I need to have code reviewed and accepted for it to land in a running launchpad by early july?
[22:46] <sinzui> mtaylor, I think 2010-06-18
[22:46] <mtaylor> sinzui: thanks