[00:14] jam: 110G and growing, 13K to go [00:20] Is anyone familiar with bzr.webdav? [00:26] hoser: not very, but if you have a question go ahead and ask [00:28] Hmm.. well.. at the moment I'm using svn for a lot of projects, and would like to switch to bzr. I've been looking at the webdav plugin but if I'm right, it's basically for the client side, and there's nothing but pure dav on the server side. With svn there are apache modules mod_dav_svn and mod_authz_svn. I'm just wondering if similar things exist somewhere [00:29] so that on the server you can implement read/write controls, allow different usernames to access different projects, etc === jkakar_ is now known as jkakar [00:36] we have a wsgi server [00:37] and you can do some policy stuff there' for auth we depend on apache [00:37] note that with a distributed vcs like bzr policy and access concerns are rather different [00:37] rather than one repository with N different permissions and groups [00:37] its easier to adminster N repositories, each for one user-or-group [00:38] yes, but I imagine most projects still have a central authoritative branch [00:38] sure [00:39] which is all I'm concerned about [00:39] the N repositories can be on the same server - apache has all tjhe facilies needed to do that with either wsgi or webdav [00:39] [wsgi is a lot faster at push and pull than webdav] [00:40] So you recommend looking into wsgi, then [00:40] yu [00:40] yup [00:40] its in our docs too [00:42] OK, will do. The key things that are currently motivating switching vcs are: renaming as a known operation, easy branch and merge, offline commits. So if I can sort out the server side I'll be very happy [00:43] cool [00:43] Thanks for your help [00:43] have a read of the docs and if they are unclear or you need inspiration / support just give us a yell [01:02] lifeless: want to review https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chk-root/+merge/11033 ? [01:03] sure [01:10] spiv: you could look at my adjacent streams patch if you like [01:10] Ok. [01:10] spiv: its not up for review as such, just look at the tip commit [01:17] lifeless: that looks reasonable. [01:18] spiv: ok, I might land that now, to avoid noise in the other patch [01:18] ok? [01:19] lifeless: Hmm. One comment: it's not clear from the method names/docstrings what the interface to that class is. [01:20] i.e. that you should call .record_stream rather than .iter_something... [01:21] spiv: I could make them private, but its a private class [01:21] A brief comment in the class docstring, or renaming the other methods to have leading _, or something along those lines would be good. It will make understanding the class easier to make it clear what the entry point is. [01:21] it kind of wants to be several classes [01:22] one that does the lookahead handling and grouping [01:22] and one that turns stuff into NetworkRecordStreams [01:22] Right, because of the relatively complex state it holds. [01:22] and handwave [01:22] otoh this is clearer I think than the previous code [01:22] for all that it does more [01:23] Well, with the other code the "now what is the first method that calls the rest" was easy to answer because of the nesting of the functions :) [01:23] I'll tinker a little. I don't feel much need to polish though: this was the only known defect in this area, and we knew that when we wrote it. [01:24] Just put "Expected usage: decoder = _ByteStreamDecoder(...); stream = decoder.record_stream()" in the class docstring if you like, that'd be enough to satisfy me. [01:24] sure === thumper is now known as thumper-afk [01:46] grabbing foodstuffs [02:13] spiv: why do you change pack_repo to know about chk_bytes? [02:16] lifeless: because it was convenient ;) [02:16] lifeless: I was thinking of pushing that into groupcompress_repo, though. [02:16] Now that I've made a separate method that GCPackCollection could override. [02:17] I suggested that [02:17] but there is another implication [02:17] we either are missing the check for inventories on packs [02:17] or there is duplication amongst things withthis broad goal [02:17] I ask that you look for which of those in your future work [02:17] I *think* the former, at least partly. [02:18] Because of the existing 'get missing parent inventories' checks that happen in streaming fetch (but perhaps not all fetch code paths?) [02:18] throw a stream with only a revision in it at a repo; see what happens :) [02:35] 10K to go [02:51] You guys change your repo format a lot, right? [02:51] some people think so [02:51] What's the end-user workflow for updating the current repo's format? [02:52] we're about to make our first change to the default since nov 2007 [02:52] twb: 'bzr upgrade' [02:52] OK, thanks. [02:52] there is a guide with docs [02:52] but that should be the heart of it :) [02:53] (I work on Darcs, and we're adding in-place upgrading of the repo format. I want to avoid unnecessary differences with other VCS' CLIs.) [02:53] cool [02:53] what have you improved in the repo format? [02:54] Several years ago we hashed the files in the "pristine" directory, which is an unmodified copy of the working tree. We also changed the semantics of patch application, e.g. two identical changes no longer conflict. [02:55] Historically upgrades have been done by making a copy of the repo, but people want to be able to make the change in-place. [02:55] yeah [02:55] its convenient, particularly for developers on C/C++ projects [02:55] Why? Because they have huge codebases? [02:55] because their build products are expensive [02:55] (I mean: why C/C++ especially) [02:56] You mean their compilation process is really slow? [02:56] yes [02:56] Yeah, I can see that. [02:56] right, they want to be able to recycle .o files etc if at all possible. [02:56] distcc :-) [02:57] 9.8K revisions to go. [02:57] hg fast-export. Slowness. cry. [02:57] mind you, I have a 117G fast import to test out next [02:57] At least it works :-/ [02:57] darcs doesn't? [02:58] darcs fast-import of a git repo was busted on a mkdir -p-type operation, last time I checked. [02:58] [darcs fast export I mean] [02:58] IIRC darcs fast-export gets more love, because most people want to leave darcs, not join it :-) [02:58] Because you start out with a small project that Darcs works well for, and you end up with a big project that Darcs is too slow for. [02:58] yeah we had that problem [02:59] took about 18 months to properly solve it [02:59] But also I use hg at work and it is super annoying. [02:59] still don't have as lovable patch workflow as darcs does [03:11] I have a bzr-svn created branch of GTK. It took about 2 days to make. Blogged about it back then, maintained it publicly. It even caused Jc2k to take an interest and set up bzr mirrors etc. [03:11] Meanwhile, GNOME (abetted by the very same Jc2k, traitor) switched to Git. Idiots. But I am now wondering: how to I talk to it? [03:12] Can I somehow leverage the existing bzr-svn created revisions? Or do I use some bzr-git plugin (which launchpad claims to use, not sure if I believe it). [03:12] Should I use git natively to clone & transfer their repo down, and then use something local disk to convert to bzr? [03:15] you can use bzr-git [03:15] same author as bzr-svn :) [03:15] and yes, lp uses bzr-git [03:15] no, you can't use the existing bzr-svn import of gtk, because there isn't a guaranteed correspondence with what they imported to git [03:17] spm, lifeless, how about we try the conversion/switchover again now? [03:18] (or after lunch) [03:18] poolie: I can kick off the check now, but am also debugging an LS issue -so somewhat distracted; but should be cool. [03:19] I'd rather not have you distracted :) [03:19] I think we should do it [03:19] when do you think you'll be ours, body n soul? [03:20] lifeless: hrmmm. say 2-3 weeks? we can schedule something in then? :-P [03:20] * lifeless wedges 3pm into spm's schedule [03:20] (earlier would be better..) [03:21] seriously tho - I'll rebuild a new bzr from trunk. kick off the make check - and go from there? after lunch basically. [03:21] spm: make sure you have rev 4666 or newer [03:21] lifeless: ok, so I guess I'll throw away the bzr-svn branches. That's mostly what I wanted to know. [03:21] AfC: yup [03:21] lifeless: actually 3pm is a horrible time - I can send Dee off alone; but that's usually when I leg stretch by fetching the boy back from school [03:21] bzr-git is bundled now, right [03:22] er, is anything bundled now? [03:23] the windows installer bundles a bunch [03:23] we haven't progressed on bundling elsewhere [03:24] I thought we were going to batteries included everything useful. Hm. [03:31] ETIME [03:33] etime? [03:33] afc, igc is working on bundling some more stuff on windows [03:33] we're not going to block 2.0 on bundling more things [03:34] poolie: ah [03:34] we may do that after 2.0 actually freezes though= [03:34] that will make it easier to change the packaging [03:34] poolie: well, I'm glad to hear Canonical employees are spending time on making Linux better. [03:35] spm, lifeless, how about just after you get back from trawling the playgrounds? :) [03:35] poolie: rob trawls playgrounds!??!!? [03:35] no, only you [03:36] damn. so much for an unsubtle attempt at sliding out of that one ;-) [03:36] ... I knew we were going for a friendly VCS and all, but I didn't know we were aiming at _friendly_... [03:36] but seriously [03:36] ping us then? [03:37] poolie: will do === thumper-afk is now known as thumper [03:46] lifeless: bzr revno 4667 from dev is built/live and working [03:46] jml: poolie: Want to lunch tomorrow; talk LP bug handling & the like? [03:46] poolie: I has book for you [03:46] poolie: if you're ok with it; I'll stop bzr pqm now; and start a make check on the tree with the 4667 revno I just built [03:46] (and a new backup -> assumed) [03:46] spm: doit [03:47] 'kk [03:49] ...../bzr check in progress === abentley1 is now known as abentley [03:49] * spm afk for lunch [03:56] lifeless: this line doesn't look right to me: [03:56] + for record in self.iter_pack_records: [03:56] since I can't find 'iter_pack_records' and if I did find it, I would expect it to be a callable iter_pack_records(): [03:57] jam: its assigned to self [03:58] its a generator we keep using [03:58] look at seed_state() [03:58] jam: I got your call; thanks! where is your current branch? [03:59] lp:///~jameinel/bzr/2.1b1-pack-on-the-fly [04:01] spm, that's great [04:01] lifeless: that's ok [04:01] i mean lunch tomorrow is ok [04:01] great [04:01] lifeless: yeah, I called poolie because you didn't answer your phone :) [04:02] jam: was in the other room - sorry [04:02] and at max ring volume its stupidly quiet [04:02] not a big deal, it got through to you [04:02] 125087/133780 [04:02] nearly there [04:02] 119G [04:03] Jelmer's dulwich page http://samba.org/~jelmer/dulwich/ claims a GPG signature for 0.3.3 but the .asc there is not being groked by by `gpg`. Nor by `file`. [04:03] It is certainly not ASCII, whatever it is [04:04] file dulwich-0.3.2.tar.gz.asc [04:04] dulwich-0.3.2.tar.gz.asc: PGP signature [04:04] um [04:05] oh, weird. Epiphany has saved a gzip of it. Is that a transfer-compression miss-thing [04:05] yes [04:05] also note that his link is to 3.2 [04:06] gpg dulwich-0.3.3.tar.gz.asc [04:06] gpg: Signature made Fri 24 Jul 2009 04:29:25 EST using RSA key ID D729A457 [04:06] wget -S http://samba.org/~jelmer/dulwich/dulwich-0.3.3.tar.gz.asc [04:06] ah, that's also not helping [04:06] Content-Type: text/plain [04:06] jelmer: ping? You've got a copy & paste bug [04:06] Meanwhile, /me uses trusty wget [04:07] I'd need a network trace to say. Could be either server misconfig or epiphany damage. [04:07] ok, good signature now, thanks [04:08] lifeless: I think it's probably Epiphany trying to be too clever [04:08] possibly [04:08] lifeless: jelmer's c&p bug didn't help either. Nothing like multiple simultaneous unrelated problems. [04:08] equally possibvly is the server claiming content encoding [04:09] server claimed "Vary: Accept-Encoding" ... I wonder if that faked out Epiphany's "Download..." [04:09] something for another time. Thanks Robert [04:10] yeah, it means that it will give wget and epiphany different answers :) [04:10] I bet there was a content encoding on the response you got, and the interaction fails [04:13] * AfC grumbles ... Galeon did such things correctly. I need to go bitch at someone, I think [04:13] debug first [04:13] :) [04:13] get the right culprit [04:15] You kidding? Random drive-by bitching is much more fun. Especially when innocent bystanders get caught in the cross-fire. [04:15] Innocent? They're on the internet. [04:16] I lost my innocence long before the internet. [04:17] Oh, I hate my life [04:17] bzr: ERROR: exceptions.TypeError: open_workingtree() got an unexpected keyword argument 'recommend_upgrade' [04:18] after 2 hours of work trying to get bzr-git to work. [04:18] hm, probably a mismatched version of the plugin [04:19] poolie: yeah, I'd branched trunk. I'm gonna try branching from the newest sounding release tag [04:19] i don't *think* we changed that recently though [04:20] I just packaged released dulwich, so I guess I'll use released bzr-git to go with it [04:21] Bah. No, that didn't help [04:21] So, I'm trying [04:21] $ bzr info git://git.gnome.org/gtk+ [04:22] prepatory to trying [04:22] spiv, tell me about bug 406687? [04:22] Launchpad bug 406687 in bzr "insert_stream doesn't check references are satisfied" [Critical,In progress] https://launchpad.net/bugs/406687 [04:22] $ bzr info ssh://afcowie@git.gnome.org/git/gtk+/ [04:22] git+ssh:// maybe? [04:22] [though I guess that's optional, I'm not pushing at the moment, just like to have r+w since I do] [04:23] poolie: probably - but git:// needs to work first [04:23] Does anyone know if bzr-svn should support local access (file:///...) to Subversion 1.6 repositories? I get a 'not a branch' exception suggesting no. [04:23] poolie: c.f. http://www.gtk.org/download.html [04:23] I thought bzr-git only got along with local access. [04:23] Or maybe I'm thinking of bzr-hg. [04:23] afc, and what happens? just that typeerror? [04:23] yes [04:23] fullermd: i think there is at least some remote support now [04:23] poolie: ^ [04:23] poolie: the partial fix (ensure revisions have corresponding inventories present, and that those inventories + any parent inventories have chk root entries present) is with PQM (although I think PQM is paused for the 2a migration?). [04:24] ah it may be [04:24] [off topic, but: [04:24] $ bzr info ssh://afcowie@git.gnome.org/git/gtk+/ [04:24] gives [04:24] and the next step is to check that the whole inventory closure is there? [04:24] poolie: the more comprehensive fix is underway, I think I have working code for checking all necessary chk records are present, but I want to write some tests now to prove that :) [04:24] bzr: ERROR: Unsupported protocol for url "ssh://afcowie@git.gnome.org/git/gtk+/": bzr supports bzr+ssh to operate over ssh, use "bzr+ssh://afcowie@git.gnome.org/git/gtk+/". [04:24] which would be WRONG :)] [04:25] how about opening a new bug for that larger fix? [04:25] afc, right, i guess you really mean 'dwim over ssh' [04:25] poolie: well I filed this bug for the larger fix [04:25] poolie: and then having found all relevant chk pages, then extract the relevant text versions from that and check they are present too. [04:25] but keep in mind Linus's avowed hatred of git+ssh:// so most of the time people will be using ssh:// [04:25] poolie: yeah [04:25] though that's actually a bit hard to implement [04:25] poolie: we never did get to talking about this yesterday. [04:25] poolie: I think bzr should dwim too [04:25] :) [04:25] poolie: ie s/bzr+ssh/ssh/ [04:26] but anyway [04:26] As lifeless says the existing bug is for the larger fix, although that is a bit inconvenient because it limits how much tracking we can do in LP. [04:26] yeah, [04:26] $ bzr info git+ssh://afcowie@git.gnome.org/git/gtk+/ [04:26] Although filing a smaller bug now and immediately marking it fix committed feels like cheating :) [04:26] gives the bzr: ERROR: exceptions.TypeError: open_workingtree() got an unexpected keyword argument 'recommend_upgrade' crash [04:26] poolie: I contend that we should fix the larger issue now, without necessarily delaying 2.0 [04:26] that's fine [04:26] poolie: because its defensive [04:27] i'm just asking or suggesting that there be one bug per incremental step [04:27] opinions may vary on whether this is clarity or overhead :) [04:27] AfC: its bzr-git that you'd need to tweak/change not dulwich :) [04:27] Yeah, at least when one of those steps is targetted to a milestone and others aren't... [04:27] poolie: I think that when it helps us its clarity. [04:27] lifeless: good to know. I had to package & install to system to use it, me not being a sophisticated pythonista [04:28] exactly [04:28] lifeless: but meanwhile bzr-git is crashing, so I give up. [04:28] Data point: git clone gtk+ took 25m17s [04:28] AfC: at least file a bug on bzr-git. I bet you're pulling from some place jelmer has forgotten about [04:28] afc, please put the traceback in a bzr-igt bug [04:28] AfC: what url did you get bzr-git from [04:29] spiv, so what did the news or merge for the branch you have sent say? [04:29] lifeless: um... info says http://bazaar.launchpad.net/~bzr/bzr-git/trunk/ and history says ... lp:bzr-git [04:29] 'partially fix ....'? [04:29] lifeless, poolie: ok, will do later today. [04:29] poolie: right [04:29] +* Prevent some kinds of incomplete data from being committed to a 2a [04:29] + repository, such as revisions without inventories or inventories without [04:29] + chk_bytes root records. Partially fixes #406687. [04:29] + (Andrew Bennetts) [04:29] i guess the operational change i'm suggesting is to never say (in news, merges, proposals) "partially fix blah" [04:30] split it and then totally fix the split off bit [04:30] if you see what i mean [04:30] Yeah. [04:30] poolie: so, this may mean larger landings [04:30] * SamB_XP wonders why you people are all green [04:30] or more landings that do things without references to bugs. [04:31] SamB_XP: It's not easy. [04:31] *groan* [04:31] I'm not sure if that will *always* fit well, but maybe I'm wrong. I'm happy to try that out. [04:31] I don't know what you mean [04:31] AfC: and what revno do you have? [04:31] (I'm sure it will often work well, though) [04:32] as (i think) Orwell said, 'break any of these rules rather than doing something barbarous' [04:32] I would like to understand the concern about what spiv did though [04:32] lifeless: trunk 603. 0.4.1 whatever the tag said [04:32] Right. I think "make separate bugs rather than write 'partially fixes'" is a good default policy. [04:33] What should I do about the landing that's in-flight? Just let it be, I suppose. [04:33] AfC: what does bzr help plugins show [04:33] spiv: pqm is disabeld [04:33] we're upgrading to 2a [04:33] hoooray! [04:33] lifeless: right, which means the flight-time is going to be quite long :) [04:34] Gotta be a way to plug that into the VCS/airlines thing :p [04:34] AfC: it should list a directory that bzr-dif is being loaded from [04:34] bzr-git, I mean [04:35] I kindof think we should have one bug filed per thing a user reports [04:35] lifeless: am i right in thinking you agreed with robert on what to do with recombining groups, bug 402652? [04:35] Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Fix committed] https://launchpad.net/bugs/402652 [04:35] lifeless: you meant `bzr plugins -v` I assume. It says 0.4.1, from the .bazaar/plugins symlink, which points to my 0.4.1 branch [04:35] and not use the bug tracker as a proxy for merges; merges are merges. [04:35] lifeless: poolie: the check came back with "found error:Internal check failed: revno does not match len(mainline) 1649 != 1674" istr vila suggested just running reconcile would fix same? [04:35] i think that's right [04:35] poolie: lifeless usually agrees with himself ;) [04:36] * AfC thinks we should discuss bzr-git another time. I think you guys are doing something more important and I don't want to distract you [04:36] about the check [04:36] spm: run bzr reconcile in that dir; it will say it fixes the branch, then hit ctrl-c [04:36] lifeless: oki [04:36] AfC: yeah bug filing time [04:37] lifeless: about whether issues are change requests or user issues or what; um, it's a very open question but i think in this case the balance is wrong [04:37] specifically, I don't see any tension between saying you're working towards a bug and landing some code [04:37] i'm not saying strictly 1:1 bug with changes [04:37] me either [04:37] however, he's done more than that here [04:37] if its because you want to untarget the bug; I'd just untarget the bug. *My* intent when I filed it was that the larger fix is what we'd do for 2.0 [04:37] it's not [04:38] ok [04:38] poolie: I'm going to file a new bug for the smaller fix; link to it from the existing bug, and replace the 'partially fixes ' in that NEWS entry with the new bug. [04:38] i do think it's possible in principle that we could decide only part of the change was needed [04:38] and in that case having them separate would help [04:38] cool [04:39] In an ideal world, splitting (and joining) bugs would be an easy operation (and create no confusion). [04:41] so, I think the confusion is that 'work' and 'requests' are different here. AFAICT its only the desire to be able to talk about the work later, to either show we did it, or to show someone that suffered it and wants to know if there is a fux, that drives the idea of assigning a new label [04:42] lifeless: so, re bug 402652? [04:42] Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Fix committed] https://launchpad.net/bugs/402652 [04:42] poolie: we're working on it [04:42] lifeless: or show *what* you fixed [04:42] lifeless: i basically agree; maybe i'm putting more value on those things than you do [04:42] SamB_XP: the merge log does that [04:50] lifeless: interesting. never said it was fixing. just did it's thing. "Reconciling branch file:///home/pqm/archives/thelove/bzr/0.8/ ;;revision_history ok.;; Reconciling repository file:///home/pqm/archives/thelove/bzr/ ;; Reconciliation complete" [04:50] spm: well, goodo [04:50] next [04:50] check again? [04:51] yes [04:51] we cycle until check is clean [04:51] wfm as a plan [04:51] but let us know when its not to think about how to handle [04:51] there are some things we might say 'meh' to [04:51] check and reconcile are not ideal yet. [04:52] 'k will do [04:52] ie play it safe; anything unusual pls to be asking loudly kthx [04:53] 7.5K to go [05:12] lifeless, lunch tomorrow sounds good. [05:30] lifeless: poolie: check still going. the previous check fail has passed this time (post reconcile) so looking good [05:31] I have a speific code that I think was introuced in some revision? Anything better than bzr log -p | grep -n 'code' to find the revision? [05:31] bzr search some things from the code [05:34] I'd find a rev that has it and use annotate, if the former is easy. [05:35] lifeless: how to make it search? [05:36] RenatoSilva: via the bzr-search plugin, however it sounds like you don't have that, so log -p | grep is fine too [05:38] ok [05:43] lifeless: poolie: that check has finished. no issues. https://pastebin.canonical.com/21777/ I'm about to be afkingfor the school run, so can continue when I get back? [05:44] ok [05:47] bah 4 hours to go on this export. sheese [05:49] And you're already a bunch of hours ahead of most of the world. [05:49] fullermd: 121G of fast-export stream so far [05:49] fullermd: from 1 .7G hg repo [05:50] Better your IO subsystem than mine. [05:52] your poor laptop [05:52] So, is this thing you're doing with spm now theoretically the Big Switch, or just testing in anticipation of? [05:53] I really want to read and summarize the test speed thread [05:53] sadly, I have other things to do [05:53] bob2: this is on my i7 [05:54] bob2: my laptop ould have run out of disk. [05:54] fullermd: Biggus Switchus [05:54] jml: heh. Trials n Tribunals. [05:54] yeah [05:54] there is a time to talk, and a time to do. [06:01] jam: your branch has tests. [06:01] jam: I'm not sure whats missing, looking at it [06:15] lifeless: well, the fact that the test passes with "if len(factories) == 1" rather than "if manager.check_is_utilized()" is one of them [06:15] so we don't have a test that insert_record_stream uses the right functionality [06:15] anyway, /me => bed [06:17] * vila waves at jam ! [06:19] Bed? The sun isn't even up yet! [06:21] I am SO pleased to read that poolie's "heart rate" is going up, and that he's getting "excited". [06:32] poolie: lifeless: shall we continue? [06:40] AfC: ? [06:40] spm: yes [06:41] lifeless: cool. so next step: I assume is the bzr upgrade --2a ? [06:42] lifeless: From: Martin Pool Message-ID: Subject: Re: metronome mail for Bazaar 2.0 and 1.18 [06:56] spm, hi [06:57] afc, i can't tell if that was sarcasm or not [06:57] poolie: heyo, so dunno how much of the above you saw? but we're all ready to roll. [06:57] poolie: it was humour, yes. [06:57] iow you're not pleased? [06:58] spm, i think i saw all of it, and the next step would be to do the upgrade [06:58] so let's do it! [06:58] poolie: I thought it was funny. What comes next after "increasing excitement"? By the time you guys release, you're going to be talking about "orgasms", I'm sure. [06:58] ok [06:58] it was meant to be a bit funny [06:59] then good! [06:59] poolie: 'kk. I'll give you all 10 seconds to cross fingers, arms legs, then I hit enter. starting.... now. [06:59] a dryer way to say it is that when there's more release-related activity we should say more about it [06:59] poolie: dry, yes. Interesting, no [07:00] hahahahahaha. bzr: ERROR: File exists: u'/home/pqm/archives/thelove/bzr/backup.bzr/': [Errno 17] File exists: '/home/pqm/archives/thelove/bzr/backup.bzr/' [07:00] You know the Bazaar hackers are working too hard when humorous replies to funny emails fall flat. [07:00] drier* [07:00] :) [07:00] You guys really need to teach bzr not to repeat itself. [07:00]