[00:00] <mwhudson> bigjools: the idea is to have the actual recipe part (the payload?) or both manifests and recipes stored the same way, in some SourcePackageRecipeData table
[00:00] <mwhudson> then SourcePackageRecipe (the editable thing) and SourcePackageRecipeBuild will both refer to this table
[00:00] <mwhudson> SourcePackageRecipe will have the stuff needed to locate the recipe
[00:01] <mwhudson> there will be a linking table linking SourcePackageRecipeData and Branch
[00:01] <bigjools> ok
[00:01] <mwhudson> SourcePackageRecipeBuild will mostly be like Build i guess
[00:01] <bigjools> I can pore over this on my flight home on Friday
[00:02] <mwhudson> and we'll add a (nullable) link from SourcePackageRelease to SourcePackageRecipeBuild
[00:02] <bigjools> I am not working tomorrow (Thursday here)
[00:02] <mwhudson> ok
[00:02] <mwhudson> i'll send my followup mail to your gmail address too
[00:03] <bigjools> I guess the FK makes more sense in a way if you treat it like "this package came from a recipe, here it is"
[00:03] <bigjools> ok I am going AFK for a bit but I will check back before I go out
[00:04] <mwhudson> ok
[00:04] <mwhudson> thanks for the hints
[00:05] <mwhudson> bigjools/wgrant: what creates Builds out of curiosity?
[00:05] <wgrant> mwhudson: An upload.
[00:05] <wgrant> Or queue-builder, but not normally.
[00:05] <mwhudson> wgrant: so they're created at the same time as sourcepackagerelease?
[00:06] <wgrant> mwhudson: Right.
[00:06] <mwhudson> ok
[00:14] <wgrant> sinzui: Is there a good reason that lp.registry.interfaces.sourcepackage.SourcePackageFileType doesn't live somewhere like lp.soyuz.interfaces.files?
[00:20] <mwhudson> i guess this build from recipe plan doesn't have an analogue of sourcepackageupload really
[00:20] <mwhudson> i wonder if that's a problem
[00:21] <wgrant> You mean a PackageUploadSource?
[00:21] <wgrant> Or something else?
[00:22] <mwhudson> sorry
[00:22] <mwhudson> sourcepackagerelease
[00:23] <wgrant> Ah.
[00:23] <wgrant> That would be a manifest, I guess, but there isn't one of those yet...
[00:23] <mwhudson> yes i guess so
[00:27] <thumper> damn
[00:27] <thumper> up arrow in the terminal to get 'make run' takes longer if the last was 'make clean run'
[00:27] <wgrant> Heh.
[00:28] <mwhudson> :-)
[00:28] <mwhudson> thumper: make schema run is worse i think
[00:28] <thumper> not any more
[00:28] <thumper> make schema runs faster for me than make clean biuld
[00:29] <thumper> hah
[00:29] <thumper> bent javascript to my will yet again!
[00:30] <thumper> ...
[00:30] <thumper> grr
[00:30] <thumper> not working
[00:30]  * thumper needs food badly
[00:33] <wgrant> mwhudson: Are jtv and yourself the only non-Soyuz BFB people?
[00:33] <mwhudson> thumper: javascript is such a tease like that
[00:33] <mwhudson> wgrant: i guess
[00:33] <mwhudson> wgrant: jml is pretty involved too, and some work from the bzr end of course
[01:02] <nhandler> Just out of curiosity, is there an easy way to manage launchpad branches? In the past, I've followed the guide on the wiki to get the source, made my changes, commited, and pushed. Then, once it was accepted, I reverted my changes and updated the branch. Is there a better workflow?
[01:03] <mwhudson> nhandler: you shouldn't need to revert the branch
[01:03] <wgrant> nhandler: You should probably have a separate branch for each piece of work.
[01:03] <mwhudson> nhandler: i have a slightly extreme set up, i have repo with no trees and a directory that contains lightweight checkouts from the repo
[01:03] <wgrant> Ah.
[01:04] <mwhudson> and make a new branch + checkout for each new bit of work
[01:05] <nhandler> wgrant or mwhudson: How would I go about doing that? Would I just pass an additional argument to bzr commit once I make my changes?
[01:05] <mwhudson> nhandler: no
[01:06] <mwhudson> i do bzr cb trunk feature-X; cd feature-X; hack hack hack; bzr ci; bzr push
[01:06] <mwhudson> cb is an alias for "cbranch --lightweight --hardlink"
[01:06]  * wgrant is boring and uses 'bzr branch devel some-feature'
[01:08] <nhandler> Ok thanks a lot
[01:09] <nhandler> And I'm not sure if it is just backed up, but I haven't gotten an email yet bac
[01:09] <wgrant> nhandler: it has only been 2.5 hours, hasn't it?
[01:09] <wgrant> The test suite takes more than 3.
[01:10] <nhandler> wgrant: I wasn't aware of that, thanks
[01:10] <wgrant> There's a looooot of sloooow tests.
[01:16] <mwhudson> bigjools: http://pastebin.ubuntu.com/328119/ <- updated patch, if a wad of sql makes sense to you :-)
[01:16] <lifeless> mwhudson: wgrant: bzr switch -b FTW
[01:16] <lifeless> or branch --switch too
[01:16]  * mwhudson definitely wants to write some code that uses this before landing the patch tho
[01:16] <mwhudson> lifeless: i like my working trees to be named after the branch
[01:16] <wgrant> lifeless: Handy.
[01:17] <wgrant> lifeless: Although I'd prefer it if it shelved my uncommitted changes, like switch-pipe.
[01:17] <lifeless> wgrant: patches reviewed.
[01:17] <mwhudson> i guess i could abuse branch --switch to something like that but the tree build time for launchpad is ok now tbh
[01:25] <thumper> I use lightweight checkouts too
[01:26] <thumper> although --hardlink isn't supported in 2a yet
[01:26] <thumper> lifeless: what does branch --switch do?
[01:27] <thumper> lifeless: can it rename the directory?
[01:28] <lifeless> thumper: no
[02:42] <sinzui> wgrant:  no reason. We have not spent much time breaking the larger classes into domains yet. Your welcome to reorganise them.
[03:21] <nhandler> I'm thinking about fixing LP Bug #400393. It looks pretty straightforward. I personally am in favor of mpt's suggestion, but I think either would work.
[03:21] <mup> Bug #400393: "Updating branch..." message reads oddly <trivial> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/400393>
[03:31]  * wgrant wonders why people want digests.
[03:32] <mwhudson> wgrant: because they want to make their email harder to read i guess
[03:33] <lifeless> because they don't want that mail at all
[03:34] <mwhudson> i guess
[03:44]  * mwhudson hates at the fact that the launchpad database only accepts file://localhost/ urls but bzrlib only accepts file:/// ones for the first time in a while
[03:48] <lifeless> mwhudson: you can fix lp if you like ;)
[03:48] <mwhudson> yeah, probably the right thing to do
[03:48] <mwhudson> where's that dba
[03:49] <mwhudson> lifeless: can i fix bzr too?
[03:49] <lifeless> mwhudson: yes.
[03:49] <lifeless> file:///localhost/ should be accepted already, I thought.
[03:50] <lifeless> bah, s////////
[03:50] <mwhudson> :)
[03:53] <mwhudson> anyway, nope, url_to_local_path still complains in trunk
[04:02] <mwhudson> man i suck at typing my gpg passphrase today
[04:02] <ajmitch> just don't type your passphrase in irc
[04:03] <mwhudson> well, judging by today's performance i wouldn't be able to
[04:32] <mwhudson> i think this traceback means i should stop work for the day: http://pastebin.ubuntu.com/328196/
[04:32] <wgrant> mwhudson: I would say so.
[04:33] <mwhudson> hm, probably python version fun actually
[04:34] <wgrant> I considered that, but it looks too obscure.
[04:34] <mwhudson> yes
[04:34] <mwhudson> bzrlib was built with 2.6
[04:34] <mwhudson> pretty obscure yes :)
[05:39] <mars> why is edge still running 9928?  Should it not have updated last night?
[05:41] <wgrant> I heard whispers of a couple of security fixes that I haven't seen landing on public branches, so perhaps updates are turned off for those.
[05:45] <mars> I don't see anything in the branch lists.  Could have been a while ago, in a sub-component, or I'm looking at the wrong list.
[06:07] <spm> mars: was a landing made by a lp-bzr dev in northern NZ; it would have broken at least one edge server, so we disabled
[09:05] <jml> mwhudson, I've replied to your "first cut" thread.
[09:12] <stub> Anyone know of any simple Python libraries to help write /etc/init.d type control scripts? I'm getting sick of hacking up makefiles or shell scripts.
[09:12] <wgrant> stub: Upstart!
[09:13] <stub> Hmm... user services is a planned feature
[09:14] <stub> This is all in tree dev stuff
[09:14] <wgrant> Ah. Sad.
[09:14] <wgrant> I don't know of anything Pythony to help generate the boilerplate.
[10:02] <jml> stub, you could make a quickly template, perhaps
[10:02] <stub> A whatly template?
[10:03] <jml> stub, 'quickly' is a python app made by didrocks and rickspencer3 that is all about making projects quickly.
[10:04] <jml> basically by doing the boilerplate generation for you
[10:04] <jml> maybe that's not what you want.
[10:11] <BjornT_> danilos: didn't your patch to make test_template_listing_admin_links pass land?
[12:15] <jtv> Does anyone know of a clever way to "mock up an import"?
[12:17] <jtv> I'm trying to write a test for test the class we use to run tests on EC2 instances, but afaict it imports python modules that are available in the EC2 image but not in LP itself.
[12:28] <jml> jtv, you can insert something into sys.modules, I think.
[12:28] <jml> jtv, it's just a dict.
[12:28] <jml> jtv, but you can probably do something nicer by splitting the code you are testing away from the code that's difficult to test.
[12:30] <jtv> jml: yes, I guess I'll do that
[12:30] <jtv> the latter
[12:30] <jml> jtv, good call :)
[12:31] <jtv> I wonder if it'd be terribly bad of me to isolate the invocation of the function I can't import, _plus its import_, in a method that I can override for the test.
[12:33] <jml> it depends.
[12:33] <jml> without context, it sounds a little dodgy
[12:36] <jtv> jml: wait, I'll paste
[12:37] <jtv> jml: https://pastebin.canonical.com/25062/
[12:37] <jtv> dodgy, yes, but perhaps not so compared to not testing this stuff at all and suffering regular breakage
[12:38] <jml> jtv, you want to test that method?
[12:38] <jtv> jml: no, I want to test the class I put it in without ImportErrors
[12:38] <jtv> And incidentally of course I also want to mock up the call to that function it wraps.
[12:39] <jtv> Without this my test can't even import the class it wants to test
[12:39] <jml> jtv, I'd suggest changing it so that the method you've added only gets called if a launchpad login is not provided as a parameter.
[12:39] <jml> jtv, also, I can tell you how to import that
[12:40] <jtv> jml: I'd really hate to change the API though, just to test a fix for the current widespread breakage
[12:40] <jml> jtv, from bzrlib.plugin import load_plugins; load_plugins()
[12:41] <jtv> jml: how will that affect the other stuff we do in ec2?
[12:41] <jml> jtv, I don't know.
[12:41] <jtv> hmm
[12:42] <jtv> and it's not tested (which is what I'm trying to make a small first step away from)
[12:42] <adiroiban1> how come that this URL load a answer component, while it's in the translations namespace ? https://translations.launchpad.dev/rosetta/+addquestion
[12:42] <jml> jtv, what do you mean it's not tested?
[12:42] <jtv> jml: the class I'm trying to write a test for isn't tested
[12:43] <jtv> I don't know how much more of this stuff is around the corner, so frankly I just want a quick fix for now
[12:43] <jml> jtv, devscripts.ec2test should be running load_plugins() on import.
[12:43] <jml> jtv, running load_plugins() is the quick fix.
[12:44]  * jtv tries
[12:44] <danilos> adiroiban1, it might be registered on more than just translations layer/facet
[12:45] <danilos> adiroiban1, you'd need to look into lp/answers/browser/configure.zcml to see what's the case there :)
[12:45] <adiroiban1> i tried to search the answer/browser/configure.zcml for "translations" .... but there was not such hint
[12:45] <danilos> adiroiban1, btw, I've seen your branch, I'll take a look later, but I don't understand why you've got that big wdml change in there? how did you get it?
[12:46] <jtv> jml: I guess I'd have to load_plugins() from the module that currently tries to import that function?
[12:46] <adiroiban1> danilos: regarding the branch. I fixed it :) ... don't know how I got that
[12:46] <jml> jtv, yes
[12:46] <jml> jtv, is this module in the devscripts.ec2test package?
[12:47] <jtv> yes
[12:47] <danilos> adiroiban1, ok, cool
[12:47] <adiroiban1> danilos: i think that file was modified by one of the debugging scripts.... but I have reverted and pushed a new revision... it should be nice and clean now
[12:47] <jml> jtv, then load_plugins should already have been called by the time you import it.
[12:47] <danilos> adiroiban1, well, it's not registered in the translations facet, it's just not limited to the answers one :)
[12:47] <jml> jtv, see devscripts/ec2test/__init__.py
[12:47] <jtv> jml: not much luck anyway:
[12:47] <jtv>         from bzrlib.plugin import load_plugins
[12:47] <jtv>         load_plugins()
[12:47] <jtv>         login = get_lp_login()
[12:48] <jtv> NameError: global name 'get_lp_login' is not defined
[12:48] <jml> jtv, it doesn't work like that.
[12:48] <jml> https://pastebin.canonical.com/25063/
[12:49] <jml> https://pastebin.canonical.com/25064/ should also work
[12:49]  * jml apologises for using the secret pastebin
[12:50] <jtv> jml: first one doesn't...
[12:50] <jtv>   File "/home/jtv/canonical/lp-branches/bug-488695/lib/lp/scripts/utilities/importfascist.py", line 163, in import_fascist
[12:50] <jtv>     module = original_import(name, globals, locals, fromlist)
[12:50] <jtv> ImportError: No module named launchpad.account
[12:52] <danilos> adiroiban1, right, and about the answers, this is what would make the difference: http://paste.ubuntu.com/328447/ (though, I am sure some links would break if you just did this, which is why nobody ever bothered to fix it up for all the pages)
[12:52] <jml> jtv, I'll try.
[12:53] <adiroiban1> danilos: still lost in url traversals ... and a quick search on the net was not enough for finding a good tutorial
[12:53] <jtv> jml: btw I hope the "thank you for helping with this" is implicit, but just in case: thanks for helping with this.  :-)
[12:53] <danilos> BjornT_, btw, the test passes on db-devel for me locally, I'll try to figure out what's going wrong
[12:54] <danilos> adiroiban1, I don't think there's one, we are doing a lot of custom things in LP as well (like one layer for each application/virtual host)
[12:55] <danilos> adiroiban1, if I were you, I wouldn't worry about it too much, because Zope is very flexible in how you do it, and we use all of those possible ways :)
[12:56] <adiroiban1> danilos: i was just looking at bug 193750 , and this is the only reason I bumped into url traversal .... otherwise I try to avoid it :)
[12:56] <mup> Bug #193750: remove references to +addticket <trivial> <ui> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/193750>
[12:57] <jtv> jml: I think I'll just circumvent this entire factory that's giving me trouble.
[12:57] <jml> jtv, ok
[12:57] <jtv> jml: I'll still have to silence the import error of course
[12:58] <jtv> how about I move the import into the factory, so circumventing the factory also circumvents the import error?
[12:59] <adiroiban1> danilos: but I learned something today about the usage of layer from configure.zcml
[13:00] <jml> jtv, fwiw, get_lp_login is called on the client side
[13:00] <jml> jtv, so if the 'ec2' command is working at all, it should be able to be imported
[13:01] <jtv> jml: any idea why I can't import it from the test?  Sorry for leaning so much on you here; I'm terrified of getting stuck on this silly detail!
[13:01] <jml> jtv, which means that something in the test environment is substantially different to something in the normal usage environment
[13:01] <jml> jtv, I don't know what that difference is
[13:02] <jml> jtv, and I would figure out that difference using normal debugging techniques.
[13:03] <jml> but I'm not going to do that, because now I am going to have lunch and start doing the things that I ought to have started four hours ago.
[13:03] <jtv> jml: I understand... I'm almost out of time myself.
[13:03] <jml> jtv, np
[13:03] <jml> jtv, well, good luck. sorry I couldn't help more.
[13:04] <jtv> hope to have good news tomorrow...
[13:10] <danilos> adiroiban1, :)
[13:10] <danilos> BjornT_, entire TranslationsWindmillLayer passes for me
[13:10] <adiroiban1> danilos: should I then look at bug 192775 ?
[13:11] <mup> Bug #192775: Notification after upload refers to "1 files" <trivial> <ui> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/192775>
[13:12] <danilos> adiroiban1, sure, though 193750 is easy as well (it's about replacing addticket with addquestion, not really a big deal :)
[13:13] <adiroiban1> danilos: i can replace that text, I was thinking it also requires adding a "sane" link
[13:13] <danilos> adiroiban1, btw, for Zope Page Templates, you might want to bookmark http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZPT.stx and http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AdvZPT.stx (from ZopeBook; it's for Zope 2.x, but these chapters are very much still relevant)
[13:13] <adiroiban1> to answers.lp.net ... and not to translations.lp.net/rosetta/+addquestion
[13:15] <danilos> adiroiban1, you can construct such a link in the view using canonical_url with rootsite='answers', but I wouldn't worry about it for now
[13:15] <bac> jtv:  are you working on the ec2 shutdown problem?
[13:15] <jtv> bac: yes
[13:16] <bac> jtv:  how's it going?  i was looking at it a bit too
[13:16] <jtv> bac: the fix is easy, adding a test is hard
[13:16] <bac> jtv: :(
[13:18] <adiroiban1> danilos:  ok. I have already changed that text in my local branch (replace all +addticket with +addquestion)... I will add that branch as a merge proposal
[13:19] <danilos> adiroiban1, cool, do make sure to run the full test suite, or at least all the translations tests (bin/test -vvt lp.translations)
[13:20] <adiroiban1> danilos: ok
[13:20] <danilos> adiroiban1, also, it's useful to note in the MP how one can easily test/see what you are changing, i.e. "go to translations.launchpad.dev/evolution/+blahblah to see how the links now point to a different location"
[13:21] <adiroiban1> danilos: yes... I read the MP cover letter wiki pages and I will try to use that format.
[13:24] <danilos> adiroiban1, cool, thanks :)
[13:26] <adiroiban1> danilos: in lp parlance, "in the view" mean in the .pt files ?
[13:27] <danilos> adiroiban1, no, it means in the browser/*.py classes :)
[13:27] <danilos> adiroiban1, all those classes have names like POTemplateView or POTemplateAdminView or...
[13:27] <adiroiban1> danilos: ok... then templates are just the look :)
[13:27] <danilos> adiroiban1, yeah
[13:30] <danilos> adiroiban1, in traditional sense, zope view is a bit of a controller and a bit of a view, and zope page template is the view
[13:32] <adiroiban1> adiroiban1: ok. I can understand it... also "class" from configure.zcml can gives tips about view class
[13:33] <danilos> adiroiban1, that's right, it's all tied together in ZCML
[13:34]  * jml going off IRC for a bit. Back later.
[13:44] <danilos> BjornT_, I've seen many (16 out of 33) tests fail with something like http://paste.ubuntu.com/328473/ in the browser with full make jscheck, so I don't know what's wrong; all translations tests pass locally
[13:46] <BjornT_> danilos: that's odd. i've seen one jscheck run where a lot of tests failed, probably due to that same failure. i also can't get the translations tests to fail locally, i'm trying to run the full suite now, to see whether that makes any difference
[13:58] <flacoste> morning launchpadders
[13:58] <mars> morning flacoste
[14:10] <BjornT_> danilos: the tests pass when running the full suite as well. i'm not sure what is going on here...
[14:18] <mars> BjornT_, we may want to enhance the build output so that the LP webserver's log is also available.  Tracebacks will be printed in there.
[14:24] <BjornT_> mars: yeah. it would also be nice, if you could easily boot up a buildbot slave image, and run the tests interactively
[14:47] <matsubara> Chex, rockstar, danilos, sinzui, allenap: LP production meeting in 13 min @ #launchpad-meeting
[14:49] <matsubara> noodles775, hi, is bigjools on holiday today?
[14:49] <noodles775> matsubara: Well, I was aware that he wouldn't be here for the second half of the day, but it was a surprise to me that he's not here now too.
[14:50] <noodles775> He was heading home today.
[14:51] <matsubara> noodles775, right. we'll have the LP production meeting in 10 min. would you be able to cover for him?
[14:51] <noodles775> matsubara: sure.
[14:51] <matsubara> noodles775, thank you
[14:51] <adiroiban1> danilos: should I add you as the review of MP for bug 193750 or should I found someone else ;)
[14:51] <mup> Bug #193750: remove references to +addticket <trivial> <ui> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/193750>
[14:51] <adiroiban1> ?
[14:51] <danilos> adiroiban1, you can probably get a faster review if you go to #launchpad-reviews
[14:52] <danilos> adiroiban1, look at the topic to see who's online
[14:52] <danilos> adiroiban1, and leave the default reviewer (it's entire LP team), so anyone can claim the review
[14:52] <adiroiban1> ok. i'll do
[14:52] <danilos> adiroiban1, I'd be happy to do it, but just exposing you to more of the processes :)
[14:53] <adiroiban1> danilos: yep. As I'm still learning, I'm happy to go by the book
[14:54] <danilos> adiroiban1, thanks :)
[14:56] <adiroiban1> danilos: should I also ask for someone else to review MP for bug 487970
[14:56] <adiroiban1> ?
[14:56] <mup> Bug #487970: distroseries/+templates page should display last update date for templates <trivial> <Launchpad Translations:Confirmed for adiroiban> <https://launchpad.net/bugs/487970>
[14:56] <danilos> adiroiban1, no, that's fine, I'd be happy to take a look at that
[14:56] <adiroiban1> danilos: ok
[15:22] <nhandler> I'm thinking about fixing LP Bug #400393. It looks pretty straightforward. I personally am in favor of mpt's suggestion, but I think either would work. I'm not sure how much discussion is really involved for it
[15:22] <mup> Bug #400393: "Updating branch..." message reads oddly <trivial> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/400393>
[15:26] <mars> nhandler, does grep-find turn up the string "Launchpad is processing new changes" in the templates or the tests?
[15:27] <mars> if so, then it should be an easy fix :)
[15:31] <nhandler> mars: Yeah, a grep comes up with: code/templates/branch-index.pt:          Launchpad is processing new changes to this branch and will be
[15:34] <mars> nhandler, excellent, and quite easy to fix then.  You just need to pick the new text.
[15:34] <nhandler> mars: Unless there are any objections, I think I'll go with mpt's suggestion.
[15:36] <nhandler> And I'm not sure if this is a known issue or an issue on my part, but I tried to do a 'rocketfuel-branch' yesterday, and got a few messages similar to "This Python has API version 1013, module gpgme._gpgme has version 1012."
[15:36] <mars> well, I personally find the voice that mpt uses in his text to be a bit too advanced.  I'm partial to Tieflegger's suggestion - closer to the "Don't make me think" mantra.
[15:37] <mars> nhandler, you need to run 'make clean'.  That is Python2.4 compiled code getting in the way of the Python2.5 runtime.
[15:37] <mpt> My words didn't have enough syllables in them? :-)
[15:38] <nhandler> mars: In that case, I might use a combination of the two. I like the more personal feel of "We'll have the changes here for you shortly"
[15:38]  * jml likes mpt's suggestion
[15:38] <nhandler> mars: Ok, I thought doing a rocketfuel-setup would have cleaned that stuff
[15:38] <mars> mpt, well, it reminded me a bit of reading Dickens - you have to hold more than seven words in your head to understand the sentence in context.  High writing, but not right for the lows of the internet
[15:39] <jml> mars, are we reading the same thing?
[15:39] <nhandler> How about "Launchpad is processing new changes to this branch. We'll have them here for you shortly." ?
[15:40] <mars> that's the one I liked
[15:40] <mpt> mars, that one isn't in the bug report
[15:41] <mars> jml, mpt used a comma, which makes the voice more sophisticated, and in my opinion, a bit more difficult to read.
[15:41] <mpt> mars, no I didn't.
[15:41] <jml> mars, No he didn't. This is the suggestion: "This branch has been changed in the past few minutes. We’ll have the changes here for you shortly."
[15:41] <mars> mpt, wasn't that jml's suggestion?  It's in a comment.
[15:41] <nhandler> Here are the 2 suggestions: https://bugs.edge.launchpad.net/launchpad-code/+bug/400393/comments/1
[15:41] <mup> Bug #400393: "Updating branch..." message reads oddly <trivial> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/400393>
[15:42] <mars> jml, I was reading "Launchpad is processing new changes to this branch, which will be available in a few minutes."
[15:42] <mpt> mars, that's Colin Watson
[15:42] <jml> mars, that would be cjwatson's suggestion
[15:43] <mars> argh, sorry mpt
[15:43] <mars> I heard "mtp's bug", and missed the actual reporter :(
[15:44] <mars> so, I /do/ like mpt's suggestion.  nhandler, I think you should just go with whatever is right.  And I think mpt is right :)
[15:47] <nhandler> mars: Alright, that is fine by me ;)
[15:50]  * mars goes to file a bug titled "A bug's reporter should stand out more on the bug report"
[15:52] <mpt> mars, that's already reported :-)
[15:52] <mpt> Well, actually, there's an open bug report on highlighting comments from the reporter, which wouldn't have helped here
[15:53] <mpt> There's also a wontfix (iirc) report that the reporter should be more closely tied to the description, which was wontfixed on the grounds that the description can be edited by other people
[15:53] <mpt> (though it wasn't in this case)
[15:53] <mars> I wonder, is it in any significant number of cases?
[15:54] <mars> I lack the SQL skill to whip up a query for that
[15:55] <cody-somerville> yes
[15:55] <cody-somerville> descriptions are edited frequently
[15:55] <cody-somerville> Its part of the SRU process in fact
[15:55] <cody-somerville> (for Ubuntu that is)
[15:55] <nhandler> It is also a common part of the Ubuntu bug triage process
[15:56] <cody-somerville> indeed
[15:57] <mars> I guess knowing the reporter is only a problem if the bug is opinionated.  Ubuntu bugs are not, they are subjective shared tickets?
[15:57] <mars> by opinionated, I mean it somehow makes a suggestion on a subjective topic
[15:58] <mars> Ubuntu bugs are objective
[15:58] <cody-somerville> I only care about who the reporter is when I have strong urges to hurt them.
[15:58] <mars> which is also a subjective opinion :)
[15:59] <cody-somerville> (or when I want to get in touch with the person more directly because they aren't responding to comments to the bug)
[16:01] <mars> I think the original reporter does matter.  It matters more as you introduce indicators as to a person's standing in the community.
[16:01] <mars> So for ubuntu, it does not matter right now
[16:01] <cody-somerville> noodles775, I think it does matter
[16:01] <mars> but it may matter later if we add badges
[16:01] <cody-somerville> err
[16:01] <cody-somerville> mars, I think your point has merit
[16:02] <cody-somerville> I'm sure I would have filed a bug sooner or later
[16:02] <cody-somerville> as I've been annoyed several times at the few ms delay to find the reporter name
[16:02] <mars> I'm thinking of what stackoverflow does, actually
[16:03] <mars> they have badges to show when a developer poses a question.  It helps you to understand the context, and allows you to make some assumptions.
[17:58] <jelmer> what sort of hardware do the code imports run on, 32-bit or 64-bit?
[17:58] <elmo> jelmer: a mixture
[18:06] <abentley> mars: do you have a sec?
[18:07] <mars> abentley, I have a few minutes
[18:07] <abentley> mars: How do I make a test pause until the contents of an element have been updated?
[18:07] <adiroiban1> when doing pagetest is there a way to get a link by id ? It looks I can only get on by text or url
[18:07] <abentley> mars: A windmill test.
[18:07] <abentley> mars: The element is a textbox.
[18:08] <mars> abentley, you could try waits.forElement on something in the box that you want to see
[18:08] <mars> oh
[18:09] <mars> abentley, for a textbox you may have to put in a hard waits.sleep() call
[18:09] <abentley> mars: I have: client.waits.forElement(xpath='//[contains(., "> content")]')
[18:09] <mars> but not too long, as it should update quickly
[18:10] <mars> abentley, interesting, and that doesn't work?  Try it with the sleep() and see if the XPATH works after a long enough wait
[18:16] <abentley> client.waits.sleep(5) gives TypeError: __call__() takes exactly 1 argument (2 given)
[18:16] <mars> ?
[18:17] <mars> that is odd
[18:17] <abentley> mars: Does it require named parameters?
[18:17] <mars> abentley, check the docs, maybe the parameters are less than obvious
[18:18] <abentley> the docs say waits.sleep takes a milliseconds parameter.
[18:18] <mars> do any other tests call that function?
[18:19] <abentley> mars: I tried passing it in as a named argument, and that seemed to work.
[18:19] <mars> odd
[18:20] <mars> abentley, salgado, I'm off for lunch, back in a while
[19:13] <jml> thumper, you around?
[19:14] <nhandler> To test out a bzr-related change, do I need to add my ssh key to Sample Person in order to push a branch ?
[19:14] <mwhudson> jml: evening
[19:15] <jml> mwhudson, hello
[19:15] <jml> nhandler, I tend to use ./utilities/make-lp-user $USER
[19:15] <jml> nhandler, which adds an ssh key automatically if it finds one
[19:16] <nhandler> jml: Will that let me push to any user's branch in the dev environment?
[19:16] <jml> mwhudson, I'm glad I made you laugh :)
[19:16] <jml> nhandler, no, just the user that it creates.
[19:16] <jml> nhandler, but, umm,
[19:17] <jml> nhandler, './utilities/make-lp-user $USER bzr-experts' will probably let you push to any branch in the dev env
[19:30] <nhandler> jml: I just looked at my ~/.ssh/config, it looks like rocketfuel setup a ~/.ssh/launchpad_id_dsa key and configured it for bazaar.launchpad.dev. It looks like it uses the user, 'mark'
[19:30] <jml> nhandler, get rid of that. use ./utilities/make-lp-user
[19:30] <nhandler> lol, ok
[19:39] <jml> mwhudson, do you know if thumper is around today?
[19:39] <mwhudson> jml: should be
[19:39] <mwhudson> jml: it's only 8:40 though, he's probably herding kids
[19:39] <jml> ahh right
[19:42] <mwhudson> jtv: thanks for spotting the problem with ec2 test
[19:42] <mwhudson> has anyone fixed it yet?
[19:47] <mwhudson> my survey says no
[19:49] <nhandler> jml: I've run the make-lp-user script, modified the entry rocketfuel had made in ~/.ssh/config to use the ssh key linked to the new launchpad.dev account, but I get a 'Received disconnect from <IP_ADDRESS>: 2: Too many authentication failures for nhandler'. Is there an equivalent of bzr launchpad-login that I need to do?
[19:49] <jml> nhandler, uhh, maybe
[19:50] <jml> nhandler, what does 'ssh bazaar.launchpad.dev' tell you?
[19:50] <nhandler> jml: Same message as above
[19:51] <jml> nhandler, did you use your unix user name as the argument to make-lp-user
[19:52] <nhandler> jml: I used $USER. I confirmed on the web interface that an nhandler user was created (nhandler@example.com:test) and it was linked with one of my ssh keys (which I have listed for this host in ~/.ssh/config)
[19:52]  * nhandler loves how he spends more time testing his fixes than creating the patches ;)
[19:55] <mwhudson> someone review this: https://code.edge.launchpad.net/~mwhudson/launchpad/ec2-test-oops/+merge/15294
[20:00] <jml> nhandler, you don't need to do a bzr launchpad-login thing if ssh bazaar.launchpad.dev is failing
[20:00] <jml> nhandler, umm
[20:00] <jml> nhandler, try that command with -v or -v -v and pastebin it maybe?
[20:03] <nhandler> jml: http://paste.ubuntu.com/328759/
[20:04] <thumper> morning
[20:05] <jml> mwhudson, done
[20:05] <jml> nhandler, looking
[20:06] <jml> thumper, hi
[20:06] <mwhudson> jml: thanks
[20:06] <thumper> jml: morning
[20:07] <jml> nhandler, do you still have ~/.ssh/launchpad_id_rsa?
[20:07] <jml> http://paste.ubuntu.com/328765/
[20:07] <jml> (or dsa or whatever it is)
[20:08] <jml> nhandler, add that clause to your config file and tell me what happens
[20:08] <jml> thumper, would you have a moment to talk?
[20:08] <thumper> jml: I have a quick moment before the stand up
[20:08] <jml> thumper, when is the standup?
[20:08] <thumper> in 7 min
[20:08] <jml> hm
[20:08] <jml> thumper, after the standup then?
[20:09] <thumper> jml: suer
[20:09] <thumper> sure
[20:09] <jml> thumper, ok. thanks.
[20:13] <mwhudson> morning
[20:15] <thumper> abentley, mwhudson: skype?
[20:15] <mwhudson> thumper: 1 sec
[20:16] <abentley> thumper: 1 sec, skype's being slow.
[20:16] <nhandler> jml: Didn't change anything. Rocketfuel setup that key for the user 'mark', should I use that user?
[20:17] <jml> nhandler, delete the user line
[20:17] <nhandler> jml: Still gives the same message
[20:17] <jml> no it doesn't
[20:17]  * jml is a little tired.
[20:18] <jml> nhandler, I bet if you replace the clause with the one I pasted, make sure that you have ~/.ssh/launchpad_id_dsa then it will work
[20:19] <jml> nhandler, in the SSH output you pasted, it's trying multiple SSH keys, which it wouldn't be doing if it were using a key specified in the config file
[20:19] <nhandler> jml: I missed your paste. Now it is saying: ssh: connect to host launchpad.dev port 5022: Connection refused
[20:19] <jml> nhandler, oh, that's much better.
[20:19] <jml> nhandler, bazaar.launchpad.dev, not launchpad.dev
[20:20] <nhandler> jml: I entered 'ssh bazaar.launchpad.dev' to get that error
[20:21] <jml> nhandler, maybe delete the Hostname entry?
[20:21] <mwhudson> thumper: ok ready
[20:21] <nhandler> jml: That gives: ssh: connect to host bazaar.launchpad.dev port 5022: Connection refused
[20:21] <jml> nhandler, is the server running?
[20:22] <nhandler> jml: Yes
[20:22] <jml> nhandler, you'll need 'make run_all' not just 'make run'
[20:22] <mwhudson> nhandler: did you run 'make run' or 'make run_all' ?
[20:26] <nhandler> jml and mwhudson: I had previously done 'make run'. I just did 'make run_all', and I get: ssh: connect to host bazaar.launchpad.dev port 5022: Connection refused
[20:27] <mwhudson> thumper: try again?
[20:27] <mwhudson> abentley: or you?
[20:27] <jml> nhandler, can you please pastebin the output of 'make run_all' as ran and also 'sudo netstat -ltpn'
[20:30] <nhandler> jml: Here is make run_all: http://paste.ubuntu.com/328777/
[20:31] <jml> nhandler, thanks.
[20:31] <nhandler> jml: Here is netstat: http://paste.ubuntu.com/328779/
[20:32] <jml> nhandler, and the IP address of bazaar.launchpad.dev is...?
[20:33] <jml> nhandler, what does 'ssh -p 5022 <IP_ADDRESS>' say?
[20:33] <nhandler> jml: That ssh command gives me a "No shells on this server" :)
[20:34] <jml> nhandler, ok. so the server is actually working.
[20:34] <jml> good.
[20:34] <lifeless> does anyone know all the products that launchpad uses?
[20:35] <jml> lifeless, I think kfogel listed them in a recent email. you can also find them on https://launchpad.net/launchpad-project -- unless you have a narrower definition of 'uses' than that.
[20:35] <jml> nhandler, so the problem is in your local config, somehow.
[20:35] <lifeless> thats precisely what I wanted.
[20:36] <lifeless> though ajaxbrowswer doesn't seem that lp related :P
[20:36] <nhandler> jml: Strange, this is a fresh setup, so I would have thought rocketfuel would have taken care of everything.
[20:36] <lifeless> jml: actually, why is https://edge.launchpad.net/ajaxbrowser in lp-project?
[20:37] <jml> nhandler, funny that :)
[20:37] <jml> lifeless, no clue
[20:37]  * nhandler loves how the patch (which involves changing 2 lines) took about 2 minutes, and the testing for it is taking hours ;)
[20:37] <lifeless> flacoste: do you know (why is https://edge.launchpad.net/ajaxbrowser in lp-project?) ?
[20:38] <jml> thumper, skype audio bugs, one sec.
[20:38] <lifeless> nhandler: you should reply to jml's mail ;)
[20:38] <nhandler> lifeless: I've already started drafting a reply ;)
[20:38] <ajmitch> nhandler: something along the lines of "the testing burns!"
[20:38] <flacoste> lifeless: i have no idea :-)
[20:39] <ajmitch> maybe someone randomly decided to add their project to lp-project, if that were possible
[20:39] <flacoste> lifeless: i think this is because anyone can add any project to any project group
[20:39]  * ajmitch wouldn't think there'd be much PHP code in launchpad-project
[20:42] <ajmitch> jml: are you working on bug 146389 which you started at UDS? :)
[20:42] <mup> Bug #146389: api for blueprint tracker <api> <feature> <Launchpad Blueprints:Triaged by jml> <https://launchpad.net/bugs/146389>
[20:43] <lifeless> flacoste: I'd assume so too; I'll get spm to remove it later.
[20:45] <flacoste> thx
[20:45] <lifeless> flacoste: how many devs does the lp community have - ~ 30 ?
[20:47] <flacoste> lifeless: you mean apart from the Launchpad team ? https://dev.launchpad.net/Contributions list that we have 12 contributors and two of that list are other Canonical employees
[20:47] <lifeless> flacoste: no, I mean 'folk that work on it'
[20:47] <lifeless> flacoste: total set of active people, not including canonical folk like me that very rarely cut code or do bug triage etc on lp itself.
[20:48] <lifeless> flacoste: just want a ballpark.
[20:48] <flacoste> lifeless: yeah, about 30
[20:55] <jml> ajmitch, no, I'm not
[20:56] <ajmitch> jml: ok, I just saw that people are screen-scraping blueprints for work items, and your demo branch from UDS looked easy enough to start from
[21:03] <mars> flacoste, quick question: was one of the future plans for zc.buildout to pull the Makefile targets into their own recipes?
[21:05] <flacoste> mars: it can
[21:05] <flacoste> depends if you prefer make run over bin/run
[21:07] <mars> ok.  I was wondering if the JavaScript and CSS build steps should be pulled into their own Makefile, or possibly a python script or zc.buildout recipe.  I guess there is no system-wide plan for that?
[21:07] <mars> no plan for other components to be separated in a similar way
[21:08] <lifeless> Make is pretty good :)
[21:09] <mars> the question is build-system agnostic
[21:09] <mars> And I see that the database does have its own Makefile
[21:10] <flacoste> mars: looking at the lazr-js Makefile...
[21:10] <flacoste> i think the build: target could become a recipe
[21:10] <mars> flacoste, I was looking at our own Makefile, actually
[21:10] <flacoste> the eggs and download-cache target should be integrated into our own bootstrap.py
[21:10] <mars> that too
[21:11] <flacoste> and then there is nothing in the Makefile that pulls its weight
[21:11] <flacoste> now, looking at the Launchpad one
[21:11] <flacoste> ...
[21:11] <mars> simple for now, but it is getting a bit more cryptic with the combo loader
[21:12] <flacoste> i think making a lazr-js build recipe would be a good thing
[21:12] <flacoste> that can be parameterized for other projects
[21:16] <mars> flacoste, ok, looks like no one has created a custom recipe so far?  I don't see anything in doc/buildout.txt.  I'll keep it in mind for the future then.
[21:16] <flacoste> mars: it was part of Bjorn's plans, but he moved on
[21:20] <lifeless> jml: bombs away
[21:21] <lifeless> flacoste: you might like my mail (just sent) to lp-dev :)
[21:22] <wgrant> lifeless: I don't see that happening without tag subscriptions.
[21:23] <wgrant> Although those are pretty easy.
[21:23] <mwhudson_> right
[21:23] <mars> I want those now, so I can track the 'javascript' tag
[21:23] <mwhudson_> yes
[21:24] <jml> wgrant, mars, maybe someone will do that during the experiment
[21:25] <lifeless> wgrant: I don't see why that should block the experiment.
[21:25]  * wgrant sees a screaming horde of developers jump onto lifeless.
[21:26] <wgrant> But maybe not.
[21:26] <mars> fans!
[21:26] <lifeless> wgrant: bzr has 20 times the bug density lp devs deal with, and its quite ok.
[21:26] <thumper> beuno: ping
[21:27] <mars> lifeless, you know what, when you put it that there are only 19 bugs per developer, then eliminating the entire backlog all of a sudden seems possible
[21:28] <lifeless> mars: its interesting to me that bzr has 18 per
[21:28] <lifeless> I start to wonder if its some sort of common ratio
[21:28] <mars> interesting
[21:28] <jml> which numbers are we using?
[21:29] <lifeless> I don't think the low number means 'we can close them all', because its an instantaneous view, not the rate of change.
[21:29] <lifeless> jml: 'open bugs' on the right hand side in 'launchpad-project' and 'bzr'
[21:29] <jml> ~5800 / 30 = ~190
[21:29] <lifeless> jml: oh,my math broke did it ? :) yes , factor of 10 on both figures.
[21:29] <mars> my dreams are shattered
[21:30] <jml> mars, start dreaming about being able to fix bugs 10 times faster maybe?
[21:30] <ajmitch> though 19 bugs for each developer would be rather nice
[21:30] <mars> jml, that is going into my email to you :)
[21:30] <jml> heh heh
[21:30] <lifeless> I shifted right to divide and forgot to shift left again :)
[21:31] <ajmitch> bzr diff really does suffer with a cold cache :)
[21:32] <lifeless> it should be legal to shoot people who operate whippersnippers
[21:32] <lifeless> ajmitch: ext3 suffers :P
[21:33] <ajmitch> doesn't help that I'm on a laptop with a bit of a slow drive
[21:34] <wgrant> And when I throw eCryptFS and encrypted swap into the mix, it is even slower.
[21:34] <lifeless> ajmitch: you could strace it next time.
[21:34] <ajmitch> it was down to 1 second when I re-ran bzr diff
[21:34] <lifeless> ajmitch: yes
[21:35] <lifeless> 15+ seconds will be starting bzr itself from cold cache
[21:35] <beuno> thumper, pong
[21:35] <thumper> beuno: can you take a look at the commit message branch?
[21:36] <thumper> beuno: I also wanted to talk to you about the comment layout change as I'm not happy with it
[21:36] <thumper> beuno: but ...
[21:36] <beuno> thumper, did you tweak it after my comment?
[21:36] <thumper> beuno: I need coffee and my ride to the coffee shop is heading off
[21:36] <thumper> beuno: which comment?
[21:36] <thumper> damn
[21:36] <thumper> too many unread emails
[21:37] <beuno> :)
[21:37] <beuno> we'll talk later
[21:37] <thumper> beuno: do you mean move it above the review block?
[21:37] <thumper> beuno: after the heading buts, but before the review table?
[21:37] <thumper> s/buts/bits/
[21:38] <beuno> thumper, yes
[21:38] <thumper> beuno: +1 from me
[21:38] <thumper> beuno: lets talk later
[21:38] <beuno> thumper, super, you already have my approval, but a screenshot before landing would be nice  :)
[21:38] <beuno> sure
[21:38] <beuno> I'mm be around on and off
[21:43] <mars> odd.  +icing is broken in all of my branches, and now in trunk, too.  I can't load files from it any more.
[21:44]  * ajmitch wonders how long the test suite will take on this laptop
[21:45] <mars> "The connection was interrupted" when trying to visit https://launchpad.dev on a new system setup.
[21:45] <mars> it doesn't even make it to the Zope server (which is running)
[21:46] <wgrant> mars: Need to restart Apache.
[21:46] <wgrant> mars: One of the modules doesn't like being loaded during a reload.
[21:47] <wgrant> So immediately after rocketfuel-setup, some requests will fail like that.
[21:47] <ajmitch> wgrant: which one is broken like that?
[21:47] <wgrant> ajmitch: Haven't got that far
[21:49] <lifeless> ajmitch: test suite ... laptop. hahahahahhaa
[21:49] <wgrant> lifeless: Hey, it's not too bad on mine.
[21:49] <ajmitch> lifeless: some of us don't have access to ec2 instances :)
[21:49] <wgrant> Once it un-swaps.
[21:49] <lifeless> ajmitch: sure you do
[21:49] <mars> wgrant, here's the error log.  Something is segfaulting: http://paste.ubuntu.com/328835/
[21:50] <wgrant> mars: Right, there is an Apache bug somewhere.
[21:50] <wgrant> I must debug that one day.
[21:50] <ajmitch> lifeless: meaning that I don't want to pay too much just to run some tests :)
[21:50] <ajmitch> at least my laptop has 4GB of RAM, or I could shove stuff onto my desktop with 8GB
[21:51] <mwhudson> i must say, i've come to respect apache a noticeable amount less over the last year
[21:51] <maxb> hmm?
[21:52] <lifeless> familiarity
[21:53] <mwhudson> oh just a few little things
[21:53] <mars> restart fixed it, but that is a bit of an obscure bug.  New lp developers will *love* that one.
[21:53] <mwhudson> mostly mod_rewrite, come to think of it
[21:53] <mars> should we restart apache as part of rocketfuel-setup ?
[21:53] <ajmitch> change rocketfuel-setup to do an apache restart then
[21:57] <mars> ajmitch, care to review the patch? http://pastebin.ubuntu.com/328843/
[21:58] <ajmitch> I'm not a reviewer, sorry, though it looks sensible
[21:59] <wgrant> mars: Would it be better to alter Makefile where it's already reloaded?
[21:59] <ajmitch> it should probably be done later on, once all the apache config has been done
[22:00] <mars> it is, isn't it?
[22:00] <mars> wgrant, and I don't see it being reloaded anywhere else?
[22:00] <ajmitch> actually the reloading of apache is done in the main lp Makefile
[22:01] <wgrant> Right, in the reload-apache target.
[22:01] <ajmitch> 'sudo make install' calls the reload-apache target
[22:04] <mars> we have a 'make install' target?
[22:04] <ajmitch> yep :)
[22:04] <mars> and people use it?
[22:04] <ajmitch> install: reload-apache
[22:04] <ajmitch> rocketfuel-setup uses it
[22:04] <wgrant> I've never used it, except in rf-setup
[22:06] <mars> so if rocketfuel-setup already does the right thing, then I guess there is nothing to do, without knowing what triggered the bug.
[22:08] <wgrant> It currently reloads. That is the right thing, but it doesn't work. If we change it to a restart, it will work.
[22:08] <mars> ah
[22:09] <ajmitch> if the problem only happens on the initial rf-setup, then it may be best fixed there (after the make install), otherwise change Makefile
[22:10] <wgrant> Probably.
[22:13] <ajmitch> running tests on the laptop is nice until the tests sit around & do nothing, specifically testPPAUploadResultingInNoBuilds waiting forever
[22:15] <mars> the only callsite for the install target that I can find is in rocketfuel-setup.  Changing the Makefile looks easiest to me.
[22:17] <mwhudson> i run make install occasionally when testing changes to branch-rewrite.py
[22:17] <mwhudson> if it did restart, that'd be fine
[22:18] <ajmitch> most people wouldn't be relying on having apache hold connections open at that point
[22:19] <lifeless> bug 488762 is a good example of the confusion I think we're having at the moment
[22:19] <mup> Bug #488762: SnapShot OOPS editing team with 13000 members <oops> <Launchpad Foundations:Triaged> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/488762>
[22:19] <lifeless> within the same overall team (lp), its simultaneously low and high priority.
[22:20] <lifeless> [note that this appears to be deliberate, it was triaged on both 'projects' simultaneously by the same dev
[22:20] <wgrant> The current LP use of importance is fucked.
[22:30] <mars> mwhudson, you were a build engineer; do you have a moment to review this patch? http://pastebin.ubuntu.com/328861/
[22:30] <lifeless> wgrant: care to expand?
[22:31] <wgrant> lifeless: Importance is treated as binary by some of the LP projects.
[22:31] <lifeless> mars: why the change?
[22:31] <lifeless> wgrant: important/not important?
[22:32] <wgrant> lifeless: Important enough to schedule, and everything else.
[22:32] <lifeless> wgrant: thats a good thing IMO
[22:32] <mars> lifeless, see the scrollback for the discussion about apache segfaulting randomly after rocketfuel-setup, and how that will be real fun for new developers.
[22:32] <lifeless> wgrant: as long as everything else gets broadly sorted into wishlist/defects
[22:32] <lifeless> mars: \o/ then JFDI
[22:32] <lifeless> +1
[22:32] <lifeless> rs=lifeless
[22:32] <mars> :D
[22:33] <lifeless> mars: but be sure to say /why/ in your commit message to trunk, not just what.
[22:33] <mars> lifeless, will do
[22:34] <mars> wgrant, are you saying that the fact that some projects us a binary approach while others do not is the problem?
[22:34] <wgrant> mars: I'm suggesting that the binary approach does not make sense.
[22:34] <mars> mwhudson, unping, thanks
[22:34] <wgrant> There are things that should not be scheduled now, but are more important than other things.
[22:34] <lifeless> wgrant: what would you propose? (And are you familiar with LEAN) ?
[22:35] <mars> lifeless, I don't know if lean has anything to do with it.  I think the YUI project follows the same principle.
[22:36] <mars> 3.1, 3.NEXT, Wishlist
[22:36] <lifeless> mars: a bunch of arguments Lean proponents make tie to together to support doing it
[22:36] <wgrant> lifeless: Vaguely.
[22:36] <lifeless> mars: so it can provide a good shorthand for discussing it.
[22:36] <mars> ah
[22:37] <lifeless> wgrant: ok, so, from the bottom then :). Some bugs may never get worked on right?
[22:37] <wgrant> lifeless: Right.
[22:38] <lifeless> wgrant: And others will go stale because their root cause goes away, or other things improve to stop the bug mattering
[22:39] <lifeless> wgrant: One part of the argument then, is that /all/ effort - triage, analysis, discussion, filtering - done to such bugs is of no benefit to the project or the users
[22:39] <lifeless> wgrant: But we don't know when a bug is in that set of bugs without putting some effort into it.
[22:40] <wgrant> Hmm.
[22:40] <lifeless> wgrant: now, open source projects allow people to scratch their own itches.
[22:41] <lifeless> wgrant: and in a commercial project an unimportant bug may become important if a lot of users want it.
[22:41] <lifeless> wgrant: so just saying 'we will close the bug if it appears low priority' isn't all that useful.
[22:41] <lifeless> wgrant: but setting the relative important of two bugs which are both below the fold, isn't very useful.
[22:42] <lifeless> wgrant: specifically, its not useful at all, as neither may get worked on /at all/ until either a) someone scratches their own itch (so the importance to the project does not matter at all).
[22:43] <lifeless> or b) something changes to make one of them more important (so the relative importance to that other bug is invalidated anyway)
[22:43] <wgrant> Hmmmhmm.
[22:43] <lifeless> testtools is running an experiment at the moment
[22:43]  * mwhudson looks at https://code.edge.launchpad.net/~vcs-imports/b2evolution/trunk
[22:44] <mwhudson> is this an import branch or not?
[22:44] <wgrant> Odd.
[22:44] <mwhudson> it appears not to have an associated CodeImport
[22:44] <lifeless> mwhudson: yes
[22:44] <lifeless> http://bazaar.launchpad.net/~vcs-imports/b2evolution/trunk/revision/5950?start_revid=5950
[22:45] <mwhudson> lifeless: indeed
[22:46] <lifeless> wgrant: now, another angle is the GTD angle, where you decide once and don't change your mind. Which I think has to be transcribed for dynamic systems
[22:46] <lifeless> to 'only touch it when it changes'
[22:46] <lifeless> or better 'only touch it when touching it will change what you /do/'
[22:47] <lifeless> ok, so dug up the testtools experiment mail. We have three importances in that project: wishlist, medium, critical.
[22:48] <lifeless> Items are either 'must do before we can release'. 'Something isn't working as advertisd'. 'Something that would be nice to do'.
[22:48] <lifeless> wgrant: ^
[22:48] <wgrant> OK.
[22:49] <mwhudson> hnngh
[22:49] <mwhudson> is it bzr-builddeb that has the pristine tar stuff in it?
[22:49] <lifeless> It doesn't have 6K bugs :) but its an interesting experiment.
[22:49] <lifeless> mwhudson: yes.
[22:49] <mwhudson> lifeless: thanks
[22:49] <mwhudson> that naming thing is really going to be a pain
[22:50] <wgrant> Naming thing?
[22:51] <mwhudson> wgrant: bzr-builder vs bzr-builddeb
[22:51] <wgrant> Ah.
[22:52] <lifeless> perhaps bzr-recipe instead
[22:55] <mars> wgrant, are you familiar with how the registry team uses bug importance?
[22:56] <wgrant> mars: I am.
[22:56] <thumper> damn, missed gary again
[22:56] <mars> thumper, he wasn't here today
[22:56] <thumper> oh, yeah, thanksgiving
[22:56] <thumper> d'uh
[22:57] <thumper> mars: so why are you?
[22:57] <mars> wgrant, ok, do you find their strategy sensible?
[22:57] <mars> thumper, because I'm not an American?
[22:57] <mars> ;)
[22:57] <thumper> mars: are you north of the border then
[22:57] <thumper> ?
[22:57] <thumper> mars: I'm not sure why I thought you were...
[22:57] <wgrant> mars: No, but I need to think through lifeless' explanations/
[23:05] <lifeless> wgrant: there's more :) I'd /love/ to see the infinite granularity stuff abentley proposed years back.
[23:05] <lifeless> wgrant: but I wouldn't want to care about the relative importance of stuff below the fold.
[23:06] <mars> lifeless, infinite importance granularity... you mean, an ordered list?
[23:06] <lifeless> mars: yes. Imagine if you will that there was a partial sort on bugs, and the UI would let you influence that sort as much as you want.
[23:07] <lifeless> so you could create a complete sort if you wanted, or just group bugs into a few bags the way we do today
[23:07] <mars> lifeless, yep, thought of that, it's right out of SCRUM.  Foundations uses a Google spreadsheet as a proxy.
[23:08] <mars> well, we did use it.  We dropped the experiment because it did not fit our team's style.
[23:09] <lifeless> could you expand on that?
[23:10] <mars> lifeless, we had a team-wide list of bugs, ordered by priority, top of the list first.  You worked down the list through the cycle.
[23:10] <mars> the idea is that anyone on the team could pop the top bug off the list, but for Foundations that doesn't work too well: too many domain experts
[23:11] <lifeless> mars: do you mean 'people wanted to work on thing that had not been assessed as the most important' ?
[23:11] <lifeless> mars: and did you do a complete sort, or a partial sort ?
[23:12] <mars> lifeless, more like it was terribly inefficient for some team members to work on the highest priority item.  Like me working on openid, or stub working on javascript.
[23:14] <mars> lifeless, we did a complete sort on the list for the number of items that we could reasonably finish in one cycle.  Items in the following cycles were roughly sorted, usually at the team leads sprint.
[23:14] <lifeless> mars: so, I think there are three necessary things for a sorted approach to work.
[23:16] <lifeless> Firstly, I think you need plenty of slack. Must do items should be no more than 50% of estimated capacity, preferrably less.
[23:16] <mars> true.  Lean says 80% capacity.
[23:16] <mars> so does server load planning :)
[23:17] <lifeless> Secondly, the team must support people doing things outside of the must-to items and ignoring the sort when they do this. Itch scratching/personal assessment.
[23:17] <mars> queue theory, apparently
[23:17] <lifeless> mars: very much so.(My dad's Master's was on queue theory ;))
[23:17] <mars> lifeless, yep.  We added those items to the top of the list, coloured them red.  During the cycle retrospective, you take that into account.
[23:18] <lifeless> Thirdly, everyone must be willing to work outside their comfort zone when the must-do list is in trouble.
[23:18] <mars> extra items only cause the cycle's lowest priority work to get pushed a bit.  You just have to keep an eye to make sure that everything doesn't turn into an unscheduled item :)
[23:18] <mars> lifeless, also true
[23:18] <mars> lifeless, we did that, too
[23:19] <lifeless> mars: lastly, but I don't think its necessary, just preferred, is to make it a partial sort.
[23:19] <lifeless> all of the must-do items should be the same priority
[23:20] <mars> ah, that is a bit different.  I think the idea from SCRUM is that some items logically come first, so there is some order in there to take advantage of.
[23:20] <lifeless> mars: and yet from what you said, thats the thing that didn't work for you.
[23:21] <mars> lifeless, in SCRUM, everyone is a generalist, and you do pair programming.  Our team only did out-of-domain work and paired up on occasion.
[23:22] <lifeless> mars: sure
[23:22] <mars> so breaking up the work into an ordered list didn't work.  In reality, everyone had their own personal list.
[23:23] <mars> So we abandoned the team list experiment
[23:23] <mars> And we rely on each developer to know what they are doing.  The team lead helps with knowledge sharing and workloads by moving people between domains.
[23:24] <mars> when it makes sense
[23:24] <lifeless> so, it seems to me that that increases coupling and latency.
[23:24] <mars> coupling and latency between what, exactly?
[23:25] <lifeless> the overall system
[23:25] <lifeless> e.g. if there are mounting numbers of critical js bugs, you need to start to feel overload before you say to the teamlead, hey I'm overloaded
[23:26] <lifeless> then they have to ask everyone 'how loaded are you'
[23:26] <lifeless> and manually rebalance.
[23:26] <mars> lifeless, yep!
[23:26] <mars> lifeless, the counter-argument is, who will save me?  I'm the only domain expert.
[23:27] <lifeless> mars: if folk overcome the fear/efficiency concerns and help out because there are critical bugs in your area, they may end up asking for mentoring - but there will be more folk hopping in and helping out.
[23:28] <lifeless> the impression I got from the poppendiecks about this was that its a difficult change to make, but actually works very well in practice.
[23:28] <mars> lifeless, yes, if the bug pool is open, and if they have slack.
[23:28] <lifeless> mars: see necessary conditions above ;)
[23:29] <mars> lifeless, one of the biggest concerns I have with our project is that very few people feel that they have slack time.    All of it.
[23:29] <lifeless> mars: I would support mass moving them all to wishlist.
[23:29] <lifeless> mars: but I don't support deletion.
[23:29] <mars> hehe
[23:30] <mars> lifeless, have you read Implementing Lean: Concept to Cash?
[23:30] <lifeless> mars: people scratch itches; bugs are a valuable resource as well, as data for defects.
[23:30] <lifeless> mars: I believe poolie is about to lend it to me; Are you talking about the honest queues aspect?
[23:30] <poolie> no that's something else
[23:30] <poolie> the only one i have is Lean Software Development, i think
[23:30] <lifeless> ok
[23:30] <lifeless> mars: no.
[23:30] <poolie> pretty sure
[23:31] <poolie> you know adam smith said most of this ~180 years ago :)
[23:31] <lifeless> \o/
[23:31] <mars> lifeless, ok.  They have an example in there about how a team reworked their 5-year bug backlog to zero, then kept zero bugs from there on out.  I think that would be amazing.
[23:31] <mars> well, kept zero bugs per cycle
[23:31] <lifeless> mars: do you mean 'no new defects' ?
[23:32] <poolie> how?
[23:32] <mars> they found new bugs, but dealt with them right away
[23:32] <lifeless> mars: so, see the testtools experiment I mentioned before - 'things that might be nice', 'defects' and 'things we must do before the next release'.
[23:33] <mars> I'll have to look at it again, but they just re-prioritized.  Some of them were real issues, a lot were bugs that the customers thought "Yeah, it would be nice to fix, but you don't have to"
[23:33] <poolie> mars: did they mostly fix the backlogged bugs (and lift their speed greatly?) or reject them or ...?
[23:33] <lifeless> in those terms, if I understand you right, the defect set would be empty, and new reports would either be 'things that might be nice' or 'things we must do before the next release'.
[23:34] <mars> The "nice to fix" bugs were cleared from their radar (shelved, or something similar)
[23:34] <mars> poolie, they rejected them
[23:34] <poolie> (our comments overlapped)
[23:34] <lifeless> mars: So, I don't like doing that, if its a good idea, I think its worth keeping it - but outside the queue.
[23:35] <lifeless> mars: people can accrue data on them. I don't think it invalidates the principle to do that.
[23:35] <mars> ah, found it!  Page 171
[23:36] <mars> lifeless, well, they didn't say how they kept them out of the queue.  But the queue was reduced to zero.
[23:36] <mars> lifeless, your "All wishlist" idea is the same thing
[23:36] <mars> that would work
[23:37] <mars> ah, yes, so they did a pareto analysis on the bugs, found most of them were stale
[23:37] <mars> the truely high priority bugs were worked on within 90 days
[23:37] <mars> everything else just went on the queue
[23:37] <mars> so, dump everything that is older than 90 days :)
[23:38] <mars> from lean: if you calculate the project's bug lead-time, you will see this
[23:38] <mars> the high priority stuff gets worked on
[23:38] <mwhudson> not all bugs (in launchpad) are defects though
[23:38] <mars> it happens naturally
[23:38] <mwhudson> but that's a bit sideways
[23:39] <mwhudson> in many many ways one of the things that makes launchpad terrible (and also is it's USP) is that it does so goddamn much
[23:40] <poolie> so
[23:40] <poolie> i think it depends on what benefit you hope to obtain whether it's better to have zero bugs, or zero non-wishlist bugs
[23:41] <poolie> is it a matter of clutter, or being honest about when they will get fixed
[23:41] <poolie> and is it ever useful to have wishlist bugs?
[23:41] <poolie> you could alternatively just sometimes make small improvements
[23:41] <poolie> perhaps people will do them independently of whether there is a bug for them or not
[23:42] <mars> I don't think there is an easy answer for that
[23:42] <poolie> so speaking to spiv this morning
[23:42] <mars> but hey, that's why we are at the cutting edge of software development processes here :)
[23:42] <poolie> he pointed out that we have >100 High bugs
[23:43] <poolie> it's hard to know where to start in them
[23:43] <poolie> some of them could be downgraded
[23:43] <jml> man I hope not.
[23:43] <poolie> hello jml
[23:43] <mwhudson> it's not what i actually think, but it's tempting to say "avoiding fruitless discussions" on irc could be a goal
[23:43] <poolie> :)
[23:43] <jml> poolie, hi
[23:43] <poolie> in favor of fruity discussions
[23:44] <mwhudson> for a while for launchpad-code specifically it felt like we had policies that meant various bugs were automatically categorized as high, but not that they were fixedx
[23:44] <mwhudson> (we're a bit better at this now, but still have more than a page of high bugs)
[23:50] <mars> mwhudson, killing the backlog is a fruitless discussion?  I think you underestimate the power that team leads have over their goals :)
[23:51] <poolie> i think priorities only make sense if they determine what tasks people should do next
[23:51] <poolie> the now/next/sometime idea
[23:52] <poolie> "oopses are high" is meaningless unless you also say something like "do high bugs before new features or lower priority bugs"
[23:52] <mwhudson> mars: any discussion is fruitless if it doesn't lead to anything
[23:52] <mwhudson> mars: but as i said, it's not what i actually think
[23:52] <mars> or you give the team enough slack so someone can kill the OOPS as soon as it pops up
[23:54] <mars> mwhudson, well, I like the discussion.  I now know poolie and lifeless are thinking in the same space, are also experimenting, and my ideas weren't called ludicrous.
[23:55] <mwhudson> mars: i was just being silly, ok?
[23:55] <awilkins> This would be a stupid time to ask if there's any integration of wikis going on then?
[23:55] <mars> mwhudson, ah, no problem :)
[23:55]  * awilkins runs for the hills
[23:55] <jml> awilkins, it's like Captain Planet says
[23:55] <jml> awilkins, the power is yours
[23:56] <awilkins> But what if I just have the power of... Wind  (mmmm. burritos)
[23:57] <poolie> i think the bug tracker should be set up so that on any day you can choose a good thing to work on next at the minimum amortized cost
[23:58] <poolie> if you have a zillion open bugs but they never get in the way of seeing the important ones, it doesn't matter
[23:58] <poolie> and vice versa
[23:58] <lifeless> awilkins: then you will get a windy wiki
[23:59] <lifeless> poolie: did you see mars note about their team trying-and-not-liking-this (his team is a bunch of domain experts e.g. dba, js specialist, etc)
[23:59] <poolie> this==single bug queue?