[00:00] I think we could do it internally incrementally if we want to; I can answer the points you've put up, but debate-in-detail is often unfruitful for this sort of discussion [00:00] lifeless: I know about your strong feelings. The time to voice them was when I put CompositeTree up for review. [00:01] abentley: I did [00:01] lifeless: Either veto my patch, or stop casting aspersions on it. [00:02] abentley: I'll shut up then; I've been hoping to change your mind, not to insult your patch [00:02] vetoing would block you and unilaterally impose my opinion [00:02] I don't want to do that [00:03] lifeless: that could actually be productive, because at least we would resolve this. [00:03] lifeless: Right now, your objections are functioning as FUD. [00:03] argh. ok. [00:04] ok, I'll veto and we can discuss [00:06] thumper: I no longer have any idea how long Nested Trees will take to land. [00:07] :( [00:07] what's the issue? [00:08] thumper: see above. lifeless is vetoing CompositeTree. [00:09] poolie: ping [00:16] jonnydee2: hi [00:16] jonnydee2: is bzr-config-cli still alive? [00:19] which format should I be dogfooding? [00:19] bzr: ERROR: ambiguous option: --development (--development-rich-root, --development-subtree, --development6-rich-root?) [00:20] jml: the one with '6' in [00:20] jml: --development-rich-root, [00:20] jml: note its a rich-root upgrade, so safe for bzr-svn imports and little else at this point [00:21] well, this is a new branch [00:21] designed to carry one emacs lisp file [00:22] go for it [00:22] if it's not safe for that, there should probably be brighter, flashier, redder lights around the help text [00:22] its supported release by release, be sure to upgrade each release of bzr. [00:22] *nod* [00:29] thumper: hi [00:30] poolie: can we have a quick call? [00:30] sure give me 5m? then just call if you want [00:31] if its re nested trees, mail is composed [00:32] ok, sent [00:35] lifeless: aws-status says I have 6 instances running [00:35] lifeless: amazon says I have one. [00:35] (I thought I had zero) [00:36] jml: it refreshes every 60 seconds [00:36] jml: could this be a 60-second out window? [00:36] lifeless: the instances shut down yesterday. [00:36] all but one :P [00:36] lifeless: it's more likely a network reliability issue. [00:36] did you run it from a console? [00:36] yeah, I just saw the stacktrace [00:37] pasting now [00:37] http://paste.ubuntu.com/164555/ [00:37] ok, please turn that into a bug [00:37] I'll fix after work [00:54] beuno: I think you're exaggerating more than a little [01:14] spiv: ping [01:15] spiv: ping [01:17] jam: ping [01:17] spiv: I'd like to get together middayish, my place if possible, to plan out the rest of the week. [01:28] abentley: ping [01:28] lifeless: pong [01:28] abentley: I have a question about root renames [01:28] I'm testing the issue with upgrade to rich roots you found [01:28] would you expect tree.rename_one('', 'child') to work ? [01:29] lifeless: No. [01:29] ok [01:29] I'll do an unversion, add, add dance then [01:29] (I'm using branchbuilder) [01:30] lifeless: You could apply an inventory delta, one that added a new root. [01:31] I don't think branchbuilder takes inv deltas [01:32] anyhow, unversion, add, add has worked - lovely test failures [01:32] lifeless: Okay. [01:34] this fix should be done today [01:34] I had one other question, which is - have I missed any cases [01:34] I have: [01:35] No parents rev -> No parents [01:35] 1 parent rev -> 1 parent [01:35] 1 ghost parent -> No parents [01:35] 2 parents both heads -> 2 parents [01:35] 2 parents one head -> 1 parent [01:35] 1 parent different fileid, ours missing -> no parents [01:35] 1 parent different fileid, ours moved -> 1 parent [01:36] 2 parents, 1 different fileid, our second missing -> 1 parent [01:36] 2 parents, 1 different fileid, our second moved -> 2 parent [01:38] fin [01:39] abentley: ^ === arjenAU2_ is now known as arjenAU [01:40] lifeless: This is re: syntheizing a root history? [01:40] yes [01:40] the InterDifferingSerializer wasn't doing the same thing as the reconcile code looks for [01:40] fetch may be doing something subtley different again [01:41] I want to squash it solidly and permanently [01:49] so if you can think of other dimensions I should be testing across, or other values in the current space I should be checking, that would be grand [01:52] lifeless, you should try and hang out during european working hours with developers [01:52] working with bzr for the past month or two has been an enourmous pain in the ass [01:53] I branch about a dozen branches a day [01:53] maybe in one of them I can use the smart server [01:54] the rest, sftp [01:54] so basically it now takes about 7 times more to get something to review [01:54] beuno: yes, I really appreciate that. Note the difference between unreleased and released! [01:54] lifeless, 1.13? 1.14? [01:54] 1.13 doesn't suffer bugs pulling [01:55] I need to grab some food, back in 15 [01:55] no, it creates broken branches [01:57] if all of Canonical is going to be dogfooding bzr, we need more responsivness [02:02] and that includes in a big part, better communication [02:04] beuno, you're so radical! :) [02:07] :) [02:07] hi emmajane [02:07] * emmajane smiles and waves [02:08] * beuno is grumpy [02:08] * emmajane grins. [02:08] I'm *shocked* [02:09] beuno: so does 1.12 [02:09] You may find humour in this: http://twitter.com/mmurray/status/1698763594 [02:09] beuno: and 1.11 [02:09] beuno: etc [02:09] beuno: once lp gets the hotfix, 1.13 pushing to bzr+ssh won't create broken branches [02:10] mwhudson: which reminds me, ^ [02:10] beuno, apparently I'm getting a little soft in my old age. :) [02:10] lifeless, right, and no good communication with all the teams as to how to avoid this has been made [02:10] beuno: what has been unclear; the bugs in question have good summaries, they've been the primary focus to fix, but they are not simple things to fix [02:10] lifeless, as well as not deploying the script to fix this [02:11] is 1.13.2 in jaunty-updates? [02:11] as well as not cherrypicking a version that warns people when creating the broken branches [02:11] beuno: ?!?!?! [02:11] beuno: such a version would equally well not create broken branches [02:11] beuno: and we have - 1.13.2 is such a version [02:12] lifeless, and the people who don't have 1.13.2? [02:12] they continue to create broken branches [02:12] beuno: will, like the people who have 1.12 upload branches with insufficient data; the code team are looking at how to fixup those branches post-push at the moment [02:13] beuno: there are 6 separate releases *all of which* will create the ACF situation [02:13] lifeless, I understand [02:13] now [02:13] you have to understand [02:13] that the end result [02:13] is that it's a pain in the ass to work on a daily basis [02:14] why didn' you downgrade to 1.13, the current release at the time? [02:14] we *could* have told everyone STOP USING 1.13 NOW [02:14] lifeless: the code treatment is likely to be "upgrade" [02:14] because I wanted to actually help fix the problem [02:14] and, as it proved [02:14] beuno: once we know the bug, suffering doesn't help fix it - once a fix is prepared testing the fix is good and helpful [02:14] being on bzr.dev helped bubble up the NoRevisionPresent problem [02:15] we have a policy of using bzr nightlies in most teams [02:15] to help development [02:15] replying "you should be using releases" is really not good for anyone [02:15] beuno: right, which is good. But when there is an issue in trunk you have to be willing to revert to stable, which has been QA'd. Bugs take time to fix. [02:16] lifeless, no, telling people how to avoid making it worst, and making sure a stop-gap measure is in place ASAP is the way to go [02:16] beuno: I'm not saying 'change your policy to be 'use stable'', I'm saying 'when a nightly breaks, report a bug and switch to stable until its fixed' [02:16] you have a script that fixes broken branches [02:16] beuno: yes, which is on the bug [02:16] lifeless, right, which is basically as if it didn't exist for most people not following bzr development [02:16] that script should be deployed already [02:16] beuno: you're really confusing me, you're jumping all over the place with different, largely unrelated things [02:17] and/or in a plugin [02:17] lifeless, maybe. I'm just saying, almost 2 months of brokeness, no matter what the reasons are, is very bad [02:18] beuno: see above, the code team are looking at running the script, harass thumper :) [02:18] lifeless: we may run the script of the existing ones, and reject old clients, but we are not going to run the script post push on everything [02:18] beuno: we try to keep trunk as solid as possible, but sometimes this will happen. Running trunk *has risks*. We certainly appreciate people doing that and giving feedback, but don't be masoschists when there is a problem. [02:19] lifeless, you guys need to coordinate [02:19] not me [02:19] beuno: when edge breaks, people use production [02:19] make sure the code team runs it [02:19] beuno: we *are coordinating*, but you're the one going critical here [02:19] because users don't care on who's plate it is [02:20] lifeless, yes. Almost 2 months, and still broken. Sounds pretty critical to me. [02:20] beuno: when a user chooses to run crack of the day, they need to be making an informed choice [02:20] beuno: go get some sleep or something. [02:20] beuno: we didn't have the fix script 2 months ago [02:21] lifeless, I'm just saying something in the process needs to be improved [02:21] beuno: what precisely? We landed the code on the 17 march, in the 1.14 cycle [02:21] 1.14 released with the bug fixed. [02:22] lp is running 1.14 and putting together stuff to fix up existing branches [02:22] lifeless, step zero is to communicate better [02:22] when something like this happens [02:22] beuno: I asked about that before and got told about nightlies instead [02:23] go in, and tell everyone what to do [02:23] otherwise, you have half the people in 1.13, creating broken branches [02:23] beuno: they should stay on 1.13 during that period [02:23] and the otgher half suffering with 1.14 [02:23] beuno: because 1.13 1.12 1.11 1.10 1.9 1.8 1.7 1.6 all create broken branches [02:23] lifeless, don't tell me [02:24] we put it in the bug [02:24] tell the 70-ish developers cursing every time they have to review someone's branch [02:24] lifeless, it turns out, not everyone reads all bugs in Launchpad [02:24] beuno: they don't lookup the symptoms when they encounter a problem ? [02:25] lifeless, no, they ask around until someone unblocks their work [02:25] people get fed random recipies [02:25] which make problems worst [02:25] please be a little more concrete. Are you saying blog? mail bzr-announce? mail bzr-dev ? (which we did, I think) [02:25] https://bugs.edge.launchpad.net/bzr/+bug/354036 [02:25] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] [02:25] that bug was *reported* april 3rd [02:25] one month [02:26] lifeless, I think this merits a blog post with the details + email to warthogs [02:26] I get your frustration, but you're not actually helping much right now. Better communication - *how*. What forum is there for 'users of unreleased code' that will get 'everyone' which seems to be your gold standard for better communication [02:27] lifeless: hitting them upside the head with a ... hmm ... copy of the Linux Kernel, on paper? [02:27] lifeless, for Canonical folks, warthogs [02:27] SamB: that would certain get their attention, if they remember the incident through the retrograde amnesia that will ensue [02:28] lifeless: could use just a small fraction of it, then [02:28] lifeless, and a blog post on planet [02:28] beuno: It seems to me like we have a bunch of people running trunk that aren't tracking the project; this is like running Ubuntu's devel version without being on Ubuntu-devel - its not that good an idea. [02:29] *things happen* during development. [02:29] lifeless, it isn't when it's a company policy [02:29] beuno: policy doesn't change risk [02:29] beuno: are you on ubuntu-devel? I certainly am [02:29] lifeless, I'm everywhere [02:30] but that's not the point :) [02:30] * SamB only runs bzr.dev because jelmer is always telling him to pull it ;-P [02:30] beuno: I think it rather is [02:30] lifeless, you don't really expect all developers to track bzr's development? [02:30] we can certainly mail warthogs about the current status of this, now and in future. [02:30] I understand how hard this is [02:31] beuno: I don't expect people to track *trunk* and not be at least following something [perhap bzr-announce?] to ensure they can be communicated with [02:31] we have a group for launchpad beta users [02:31] beuno: who made a policy like that? [02:31] I assume everyone in the company is in that group [02:31] SamB: Canonical has a general dogfood policy - where we create something, we use it ourselves [02:31] lifeless, sure, we may have to adjust things [02:31] lifeless: oh, is he in canonical? [02:31] SamB: (use it in beta and release at minimum), to improve quality [02:31] SamB: we hired beuno, yes [02:31] ah. [02:32] must have missed that [02:32] beuno: you need to communicate better :P [02:32] maybe you should have a company-wide email list or something [02:32] * beuno grins [02:32] SamB, we have like 60 mailing lists [02:32] SamB: we do, but this issue is equally applicable to folk outside the company tracking trunk [02:32] lifeless: yeah. === gorozco is now known as p4tux [02:32] maybe you need to do more cross-posting >-) [02:32] maybe! [02:33] okay, so what's this list I should be on but aren't? [02:33] beuno: So I think two things; one is the policy should be more clear about what to do when there is an issue - ensure there is a bug, downgrade to release, get on with your work. [02:33] SamB: bazaar@lists.canonical.com is the current list that issues with trunk are discussed on [02:33] lifeless, if bzr breaks something so critical, I expect the team to actively engage it's major users, no matter who they are [02:33] lifeless, yes, a big part of it is policy [02:34] hmm. [02:34] which we need to coordinate better [02:34] I'm sorry to jump out of this one, but I *really* need food [02:34] lifeless: that's way too high-traffic for me to actually follow [02:34] beuno: secondly, perhaps we should have another list/lp team/whatever where people that are tracking trunk to contribute, but not interested in discussing bzr at all, should subscribe to [02:35] * emmajane offers beuno some birthday cake. [02:35] SamB: yes, and even if it was just regular users I think it would be too [02:35] SamB: bzr is actually fairly popular :P [02:36] lifeless: spiv is away sick today [02:36] SamB, did you know you can ignore a lot of the messages? There are subscription options that make the list a lot more manageable. [02:36] poolie: ah [02:37] SamB, I also sort by thread and *ahem* delete a lot of the stuff that's over my head. [02:38] SamB, Filters help too. I only look in my "bazaar" folder when I've got extra energy. [02:39] lifeless: since andrew is away and since beuno reports it's hurting people a lot, would it make sense for you to work on bug 360791 ? do you have enough of the state? [02:39] Launchpad bug 360791 in bzr/1.14 "get_stream on stacked branch causes "Error received from smart server: ('NoSuchRevision',)"" [Critical,In progress] https://launchpad.net/bugs/360791 [02:40] poolie: I can acquire that state; do you know if spiv has stuff in-flight that I should get off him? [02:40] poolie: I want to finish the current patch first, as its nearly done. [02:40] he was still working on it yesterday [02:40] he's apparently still somewhat alive so you could perhaps call him briefly [02:41] poolie: and is also quite critical, given it blocks people upgrading accurately to rich roots - its critical path for bbc transition [02:41] right, i know [02:42] I propose that I finish the current patch to avoid thrashing; and ring him when I'm done to ensure I have his in-progress work. [02:42] lifeless: I don't know what "moved" means. [02:42] abentley: old tree: '' is ROOT_ID, 'child' is 'my-root'. new tree: '' is 'my-root' [02:43] abentley: so 'my-root' has moved from 'child' to ''. [02:44] emmajane: I do subscribe to the list, but I never really look at it unless either someone tells me to or ... well, I can't think of another reason ;-) [02:44] SamB, do you have the list filters on so that you don't get the code-y things? [02:44] SamB, MERGE and something else can be filtered out IIRC [02:44] lifeless: I can't think of any more cases. [02:44] hmm, yeah, merge would be easy to filter out [02:44] abentley: cool, thanks. [02:45] SamB, check the mailman page. There are some built-in options for the list. [02:45] but shouldn't there be a list for really important issues to be announced on? [02:45] we have bazaar-announce [02:45] SamB, it's version control. Everything is important. :) [02:46] but I would expect packagers and release-only users to perhaps be unhappy about issues with unreleased code going there [02:46] I'm thinking bugs where your data gets messed up but you don't know until way later [02:46] lifeless: it also doesn't sound dangery enough [02:46] bazaar-warn, maybe? [02:46] I'd really rather not call a list that ;) [02:47] bazaar-omgwtfbbq? [02:47] bazaar-bleed? [02:47] emmajane: :) [02:47] bazaar-yourerunningtrunkyoushouldknowbetter? [02:48] bazaar-oh-great [02:48] bazaar-SRLSY? [02:48] * emmajane goes back to her bazaar-scotch. :) [02:50] * SamB wonders what the easiest way to run a program in a Linux kernel under a debugger is ... [02:50] (that is, the kernel is under the debugger ...) [02:51] hmmm, I have load 11 [02:51] but no disk and the system is snappy... anyone else seeing this on jaunty? [02:52] what is this load thing? [02:52] is it possibly a highly-bogus figure? [02:52] SamB: load := number of processes in the runable state [02:53] that sounds pretty bogus to me [02:53] (once it starts to average more than 1) [02:53] All metrics are bogus :p [02:53] yeah, but that sounds more bogus than bogomips! [02:54] As a measure of contention for CPU, load average is often a decent rule of thumb check. [02:54] Mind, by the time it hits 3000 or so, it starts getting too expensive to calculate to be worthwhile... [02:55] it doesn't account for niceness or anything though [02:55] AfC: linux also includes procs waiting on IO [02:55] lifeless: I didn't know that. Huh. Thanks! [02:56] Nor for network or disk IO, or memory pressure, or any number of other things. But then, defining something that broad that distills to a single number is somewhat more difficult. [02:56] http://en.wikipedia.org/wiki/Load_(computing) [02:56] * SamB wishes top showed IO utilization ... [02:56] SamB: iotop [02:56] * fullermd looks at his top which DOES have an IO showing mode... [02:57] (of course, assigning IO to a particular process isn't a faultless process either) [02:57] fullermd: I meant in each row [02:57] or did you also? [02:57] Yah. [02:57] PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND [02:57] what top is that? [02:57] or, er, how do you get that? [02:57] bsd :) [02:57] oh [02:57] pooh [02:58] anyway, I know it's not faultless, but it's nice to know *A* process that needs the IO done ;-) [03:03] * igc food [03:03] SamB: try iotop out === timchen1` is now known as nasloc__ [03:06] Why would I be getting a mismatched rich-root support error when attempting to reconfigure --standalone? [03:11] bug something or other [03:11] reconfigure doesn't preserve format [03:20] jelmer_: so you fixed a memory usage issue you say? [03:21] oh nm [04:14] https://code.edge.launchpad.net/~jelmer/openoffice/hosted now has over 250k revisions :) [04:15] nice [04:16] and codebrowse continues to somewhat work [04:42] It somewhat works? That's somewhat good to know. :P === BlackKnight is now known as UdontKnow [05:06] * mwhudson reads planet bazaar, becomes hungry === dereine[OFF] is now known as dereine === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine === dereine is now known as dereine[OFF] [07:12] hi all [07:15] Argh, no wonder nobody reviewed my payches.... mail don't go out since last saturday :-( [07:25] hello vila [07:26] igc, what's the reasoning behind copying HACKING.txt around when building the docs? [07:35] poolie: the doc gets built & copied as a full tree, e.g. http://doc.bazaar-vcs.org/latest/developers/index.html [07:36] i guess what i meant is [07:36] the rest source lives in doc/developers/HACKING [07:37] but the html output is sent to doc/en/developer-guide/HACKING.html [07:37] i guess this is just for historical reasons [07:37] poolie: I'm happy for the rest source to move [07:37] done [07:37] thanks [07:37] poolie: it location is historical [07:38] i thought so [07:38] poolie: once upon a time before we had the nice catalogs we do now, I guess the source location was more important [07:39] poolie: now I'd expect most developers to find the html easily enough [07:39] i've just moved the source to be in the same location as the html to avoid minor confusion [07:39] i think i once started editing the wrong copy of the text file [07:40] poolie: cool. Thanks. [07:40] it's all fine now though, thanks [08:25] hi vila [08:26] lifeless: hi [09:41] * igc dinner [09:44] Hi all [09:45] Is there a way to get bzr to "forget" the submit or parent branch? [09:45] (Apart from editing the .bzr/branch.conf, that is) [09:53] Lo-lan-do: remember a new one [09:59] night all [10:00] Hm. Yes, that would work, of course. [10:00] Except it needs some non-transparent operation to happen, doesn't it? [10:01] Such as merging (for the submit branch) or... I don't even know how to remember a new parent branch. [10:26] hi, trying to branch from an LP-hosted branch using bzr from the nightlies PPA, i get "Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")". any ideas? [10:27] intellectronica: use nosmart+ before the url or an sftp url [10:27] intellectronica: there is a bug in older bzr's that causes branches to individually generate that message [10:28] oh right, so if i re-upload the branch with a new bzr it will be ok? [10:40] intellectronica: or you can run te fix script [10:41] https://bugs.edge.launchpad.net/bugs/354036 [10:41] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] [10:41] there are a couple of bugs related to streaming at the moment; in general ifyou can't get a brnach use nosmart:+ or a http or sftp url. [11:22] i have been trying to use bzrlib to list the files under a working directory, can someone help me in this reguard === jelmer_ is now known as Guest54966 [12:00] jelmer: Did bzr-gtk get upgraded to rich-root? [12:00] awilkins: yep [12:00] aha. [12:01] jelmer: 1.9 or 1.14? [12:02] Hmmph, info says "unnamed". V.unhelpful. [12:02] awilkins: either should work [12:02] awilkins: I upgraded to 1.9-rich-root [12:02] I'll stick to 1.9, my users are still on 1.13 [12:03] lifeless: ping [12:03] awilkins: I think 1.14 only matters for the working tree format anyway [12:08] I only really use bzr-gtk for gconflicts now [12:09] And a local patch of it, at that [12:11] awilkins: no viz? [12:11] I use qlog for that [12:11] How's viz now? [12:11] ah [12:11] viz is still the same [12:11] what's better about qlog? [12:11] Let me try viz again for a mo and I'll think about it [12:12] Ok (silly) : qlog looks more native on win32 and has font smoothing, etc [12:13] ah, of course. I'd forgotten you were on win32 [12:13] (practical) qlog has a "files that changed" pane from which you can trigger a file diff [12:13] It also has expansion of merge points [12:14] Over half the width is consumed with the DAG on viz, on qlog you only get this if you expand a few nodes [12:15] double click a revision to see the changes [12:15] qlog could do with a heck of a lot more context options (which viz seems to have in menus) [12:16] Both of them need to be able to be configured to use external diff utils [12:17] When considering this sort of thing I think TortoiseSVN is a great place to start [12:17] You can't go too far wrong just ripping off their feature sheet [12:20] Maybe I should post some thoughts on the list when I have time ; I've used TSVN a hell of a lot, I admin our in-house SVN repositories. [12:21] There are things like the filter box - needs a path filter option (even if it would be slow although I'm not sure how slow it is on the newer branch formats now) [12:25] jelmer: pong; just fixing raid controller software, so you'll only get a little bit of attention [12:28] lifeless: does PQM ignore duplicate submissions? [12:29] jelmer: GPG dups yes, others no, but if no changes are found it bounces the second [12:29] lifeless: ok, then it'll bounce - thanks [12:39] moin [12:41] hey ronny [12:41] sup [12:42] older bzr versions still arent easy_install-able [12:43] hello, I wrote a simple plugin that allows for filtering by changeset author [12:43] ronny: I think LarstiQ was looking into that [12:43] LarstiQ: ^ [12:43] I did it in a pretty hacky way because I could not find any better APIs to do it [12:43] I removed log._make_search_filter from available log adapters [12:44] and then added my own _make_author_filter function that understands author: prefix of the search argument [12:44] I was wondering if there is a better way to do it [12:44] igc: you might want to talk to igc when he's around, I think he did a lot of work on log recently [12:44] basically I'd like to have "bzr log | grep author" that is smarter [12:45] can anyone please point me to some API's/people that could show the way? [12:45] zyga: I think jelmer's last message was for you :-) [12:45] zyga: one way is to just register a new log formatter that only shows revisions by a particular author [12:46]